Linux2.6.18 SD卡驱动的修正

来源：赛迪网    作者：korn

platform: s3c2440 + linux 2.6.18

在linux2.6.18 中,sd卡的驱动有不少的bug.例如,没有写保护的功能.

在驱动的模块中预留了写保护的函数,但是没有实现,代码也只有几行,只要加上去编译一下就OK了.

static struct mmc_host_ops s3c2410sdi_ops = {
.request = s3c2410sdi_request,
.set_ios = s3c2410sdi_set_ios,
.get_ro = s3c2440_get_ro, //sd card ReadOnly Flag.

};

实现函数如下:

static int s3c2440_get_ro(struct mmc_host *mmc)
{
struct s3c2410sdi_host *host = mmc_priv(mmc);

unsigned long flags;
int present;

spin_lock_irqsave(&host->complete_lock, flags);

present = read_gpio_bit(S3C2410_GPB0); 
present &= 0x01;
spin_unlock_irqrestore(&host->complete_lock, flags);

return present;
}

还有一些就是热插拔的和中断检测口,只要设置一下就可以用了.

比较麻烦的是对SD卡写操作,只要写稍微大点的文件到SD卡就会出错,打印出如下信息:

[IRQ] csta=00000a19 dsta=00000002 fsta=00002200 dcnt=00008000

[IRQ] csta=00000a19 dsta=00000002 fsta=00002200 dcnt=00007000

[IRQ] csta=00000a19 dsta=00000002 fsta=00002200 dcnt=00007000

[IRQ] csta=00000a19 dsta=00000002 fsta=00002200 dcnt=00007000

对比正常传送打印出来的信息,很明显程序是在这里挂掉了.

后来跟踪代码发现,当写一个 4096(512*8)的数据时,只写了第一个512byte就不往下写了,所以dcnt一直为 7000,出现这个现象的原因是因为程序对 host->pio_words 这个变量赋的值为128,通过 host->pio_words-- 递减到0时就不进入

while(sdi_fsta & S3C2410_SDIFSTA_TFDET && host->pio_words)这个循环了,

所以 host->pio_words=sdi_bsize>>2; 这一行应改为

host->pio_words = mrq->data->blocks * (sdi_bsize>>2);

这样对SD卡的写操作就解决了.但写的速度不是很快.

还有一个问题,比如 cp 一个文件到SD卡上,是不是首先先将这个文件写到SDRAM上,然后umount的时候再将SDRAM中的内容真正写SD卡上??我umount的时候会过多一会才出现终端的提示符,根据写入文件的大小确定 umount的时间?

后来查了一下资料,Linux文件系统更新是一个复杂的过程，当用户程序对文件系统进行修改以后，例如进行了写操作，文件数据把修改记录在内核缓冲中，在数据没有写到磁盘的时候，依然能够执行用户进程，所有数据的改变都在inode的内容中得到反映。磁盘的数据更新实际上是异步进行的，很有可能在写操作已经完成很长时间以后才真正对磁盘的数据进行更新。sync命令强制把磁盘缓冲的所有数据写入磁盘，如果在没有把磁盘缓冲区的信息写入磁盘之前终止系统，则磁盘的文件系统就会处在一个不稳定的状态。而在正常模式下即使没有对分区进行umount的操作，在重启之前系统会调用sync命令强制把磁盘缓冲的所有数据写入磁盘,而在急救模式下必须对所挂的分区进行umount的操作,系统才会调用sync命令强制把磁盘缓冲的所有数据写入磁盘，请在急救模式下的朋友注意这个问题。其实“reboot -n(Don’t sync before reboot or halt)”在重启之前不用sync命令强制把磁盘缓冲的所有数据写入磁盘,就很能说明问题。

所以要 cp 完之后要执行 sync 命令将缓冲区的内容写到磁盘中,然后再umount 就不会出现延时了.

s3c2440 SD卡(for LINUX)驱动代码下载地址: