sd卡驱动分析 linux,linuxSD卡驱动分析.doc.doc

linuxSD卡驱动分析.doc.doc

SD卡驱动分析1

块请求处理(linux/driver/mmc/card)2

1.probe2

2.do_request13

3.小结24

core层处理(linux/driver/mmc/core)25

1.core层初始化25

2.mmc_claim_host28

3.mmc_release_host30

4.mmc_wait_for_req32

5.mmc_wait_for_cmd35

SD控制器之初始化(linux/driver/mmc/host)36

core层续集之mmc_add_host48

SD控制器之真正的硬件操作82

1.s3cmci_get_ro83

2.s3cmci_set_ios84

3.s3cmci_request之命令处理86

4.s3cmci_request之数据传输96

小结112

SD卡驱动分析

SD卡驱动分三层结构分别对应driver/mmc目录下的card、host、core三个文件夹。其层次关系如下所示：

分析过程分目录进行，为了与块设备层驱动接轨，这里我们以自顶向下的分析方法来处理SD卡的设备驱动。与块层联系最紧密的就是card目录，首先来看看与块设备接口的部分内容。

块请求处理(linux/driver/mmc/card)

probe

按照惯例我们还是先来看下内核地图，Kconfig和Makefile

从kconfig所给的信息来看我们最最关心的还是第7行和第17行，config MMC_BLOCK、config MMC_BLOCK_BOUNCE。其中config MMC_BLOCK是整个MMC层工作的核心，对应于Makefile我们关注如下两行：

obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o

mmc_block-objs:= block.o queue.o

单凭直觉我们不难发现block.c是我们整个card目录的入口，打开文件不难发现在文件末尾处module_init(mmc_blk_init);将整个card目录入口描绘的淋漓尽致。还是来看看mmc_blk_init的相关内容。

[card/block.c]

673static int __init mmc_blk_init(void)

674{

675int res;

676

677res = register_blkdev(MMC_BLOCK_MAJOR, "mmc");

678if (res)

679goto out;

680

681res = mmc_register_driver(&mmc_driver);

682if (res)

683goto out2;

684

685return 0;

686 out2:

687unregister_blkdev(MMC_BLOCK_MAJOR, "mmc");

688 out:

689return res;

690}

667行开门见山，注册块设备驱动。相信看过LDD3的哥们都知道这个函数并无大用，他的作用也远没有他名字来的那般响亮。最多也就动态分配一个主设备号，然后在proc/device中留下点不为人知的记号，真正充NB的还是后面我们看到的add_disk。

681行看似新鲜，不过看名字也就是往mmc core里注册点啥。他这一注册不打紧，关键是乱了我们的阵脚，说好了现在只说card目录的要是看了他就惹上core了，不看吧也就没法往下走了。干脆看一点点算了

[core/bus.c]

164int mmc_register_driver(struct mmc_driver *drv)

165{

166drv->drv.bus = &mmc_bus_type;

167return driver_register(&drv->drv);

168}

166行和167行知道一点点设备模型的哥们，估计在这里就要兴奋了。估计也就能猜到这个core大致都干了些啥勾当。不说别的166行的mmc_bus_type这条总线总得有人维护吧，自古以来这个又脏又累的活儿就是core干的，这里当然也不例外，不过这是后话。167行注册了个device_driver，那当然也有个device了，至于他在哪我们留点神秘感以后再说。只知道有了driver_register自然会发生点啥，至少bus probe是肯定会调用的，下面就来看看这条总线究竟长啥样…

[core/bus.c]

139static struct bus_type mmc_bus_type = {

140.na