SD卡驱动分析.doc

SD卡驱动分析 1 块请求处理（linux/driver/mmc/card） 2 1. probe 2 2. do_request 13 3. 小结 24 core层处理（linux/driver/mmc/core） 25 1. core层初始化 25 2. mmc_claim_host 28 3. mmc_release_host 30 4. mmc_wait_for_req 32 5. mmc_wait_for_cmd 35 SD控制器之初始化（linux/driver/mmc/host） 36 core层续集之mmc_add_host 48 SD控制器之真正的硬件操作 82 1. s3cmci_get_ro 83 2. s3cmci_set_ios 84 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] 673 static int __init mmc_blk_init(void) 674 { 675 int res; 676 677 res = register_blkdev(MMC_BLOCK_MAJOR, mmc); 678 if (res) 679 goto out; 680 681 res = mmc_register_driver(mmc_driver); 682 if (res) 683 goto out2; 684 685 return 0; 686 out2: 687 unregister_blkdev(MMC_BLOCK_MAJOR, mmc); 688 out: 689 return res; 690 } 667行开门见山，注册块设备驱动。相信看过LDD3的哥们都知道这个函数并无大用，他的作用也远没有他名字来的那般响亮。最多也就动态分配一个主设备号，然后在proc/device中留下点不为人知的记号，真正充NB的还是后面我们看到的add_disk。 681行看似新鲜，不过看名字也就是往mmc core里注册点啥。他这一注册不打紧，关键是乱了我们的阵脚，说好了现在只说card目录的要是看了他就惹上core了，不看吧也就没法往下走了。干脆看一点点算了 [core/bus.c] 164 int mmc_register_driver(struct mmc_driver *drv) 165 { 166 drv-drv.bus = mmc_bus_type; 167 return driver_register(drv-drv); 168 } 166行和167行知道一点点设备模型的哥们，估计在这里就要兴奋了。估计也就能猜到这个core大致都干了些啥勾当。不说别的166行的mmc_bus_type这条总线总得有人维护吧，自古以来这个又脏又累的活儿就是core干的，这里当然也不例外，不过这是后话。167行注册了个device_driver，那当然也有个device了，至于他在哪我们留点神秘感以后再说。只知道有了driver_register自然会发生点啥，至少bus probe是肯定会调用的，下面就来看看这条总线究竟长啥样… [core/bus.c] 139 static struct bus_type mmc_bus_type = { 140 .name = mmc