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