1. 从一次SD卡识别异常说起为什么值得啃mmc驱动框架前阵子帮一个做嵌入式产品的朋友排查问题他们的一块工业板子跑LinuxeMMC在常温下工作得好好的一到低温环境就概率性识别失败内核日志里刷了一串mmc0: error -110 whilst initialising MMC card。他一开始怀疑是硬件焊接问题换了三块板子都一样后来把怀疑对象转到驱动层但打开drivers/mmc/目录一看core、host、card三大块代码铺开加上一堆协议术语直接懵了。这个场景其实很典型。Linux mmc驱动框架是内核里相对独立、但层次又比较清晰的一个子系统它负责管理MMC、SD、SDIO这一整类存储和外设接口。你手机里的TF卡、很多嵌入式板子上的eMMC、还有那些插在SDIO口上的WiFi模块走的都是这套框架。搞嵌入式Linux的人早晚要跟它打交道——可能是调一块新板子的host控制器可能是排查卡识别不稳定的问题也可能是给某个SDIO外设写驱动。但很多人第一次接触它的时候会被几个概念绕晕host和card是什么关系core层到底干了什么为什么有的代码在core里有的在host里mmc_host、mmc_card、mmc_request这几个结构体之间怎么串起来的这篇文章就打算把这一层一层剥开从基本概念入手把框架的设计思路、核心数据结构、分层逻辑讲清楚。目标读者是有点Linux驱动基础、但还没系统梳理过mmc子系统的朋友看完之后你至少能做到拿到一份host驱动代码知道每一部分在框架里处于什么位置出问题时知道该往哪个方向查。我不会一上来就贴大段源码而是先把为什么这么设计讲明白再落到具体结构和流程上。毕竟框架这种东西理解了设计动机代码只是它的表达形式。2. mmc子系统的整体分层与设计思路2.1 三层结构host、core、card各管什么Linux mmc子系统在代码组织上分成三个目录这个划分本身就说明了它的分层思想drivers/mmc/host/放的是具体host控制器的驱动比如某款SoC的SDHCI控制器驱动、某款芯片的dw_mmc驱动。这一层直接跟硬件寄存器打交道。drivers/mmc/core/框架核心层负责协议流程、卡枚举、请求调度、总线管理等通用逻辑。它不关心具体硬件怎么操作只调用host层提供的接口。drivers/mmc/card/块设备层和SDIO功能层的适配把mmc设备抽象成块设备给文件系统用或者SDIO功能设备给外设驱动用。这个分层的核心动机是解耦。全世界有几十上百种SD/MMC host控制器它们的寄存器布局、DMA方式、时钟控制各不相同但上面跑的协议流程、卡初始化步骤、数据传输格式是统一的。如果每个host驱动都自己实现一遍卡枚举那代码会重复到无法维护。所以框架把变的host硬件操作和不变的协议流程分开host驱动只需要实现一组标准回调core层拿着这组回调去跑通用流程。打个比方core层像是一个标准化的考官它手里有一套固定的考试流程发什么命令、等什么响应、怎么校验而host驱动是翻译官负责把考官的话翻译成具体硬件能听懂的语言。考官不关心翻译官用什么方言只要翻译准确就行。2.2 为什么要有core这一层抽象有人可能会问直接让host驱动调协议栈不行吗为什么要多一层core这里有几个实打实的理由。第一是代码复用。SD卡初始化要发CMD0、CMD8、ACMD41、CMD2、CMD3这一长串命令中间还要处理电压协商、容量判断、总线宽度切换。这套流程对所有host都一样放在core里写一遍所有host驱动白嫖。第二是统一设备模型。Linux设备模型要求设备有统一的表示方式core层把每个卡抽象成mmc_card挂到mmc_host下面再通过mmc_bus总线类型跟驱动匹配。这样用户空间能看到/sys/class/mmc_host/下的设备树块设备层能通过标准接口拿到卡的信息。第三是请求调度与并发控制。多个请求可能同时到达core层负责排队、合并、按优先级调度还要处理错误重试。这些逻辑跟硬件无关放core里最合适。第四是协议版本兼容。MMC协议从4.x一路演进到5.xSD协议也有1.0到7.0的差异core层统一处理这些差异host驱动不用为每个协议版本写分支。提示理解这三层的关键是记住core定义接口host实现接口card消费接口。看代码时先定位自己在哪一层再顺着接口往上或往下找。2.3 与块设备层、SDIO层的衔接关系mmc子系统往上对接两个方向。一个是块设备层当一张SD卡或eMMC被识别为存储设备时core层会通过mmc_blk把它注册成一个块设备比如/dev/mmcblk0文件系统就能在上面建分区、挂载。另一个是SDIO功能层当识别到的是SDIO外设比如WiFi、蓝牙模块时core层会把它注册成SDIO功能设备对应的function驱动通过sdio_register_driver来匹配。这两个方向共用底下的host和core只是上层适配不同。这种设计让同一套host驱动既能带存储卡又能带SDIO外设非常灵活。实际产品里经常看到一颗SoC的SD控制器一个口接eMMC做系统盘另一个口接SDIO WiFi底层host驱动是同一份代码。3. 核心概念逐个拆解host、card、bus与request3.1 mmc_host一个控制器对应一个hoststruct mmc_host是core层对一个host控制器的抽象。注意是控制器不是卡一个host可以插一张卡也可以在某些设计上通过总线扩展挂多张卡虽然实际很少这么用。这个结构体里塞了几十上百个字段但可以归成几类硬件能力描述ocr_avail支持的电压范围、caps能力标志比如是否支持4位/8位总线、是否支持高速模式、max_seg_size、max_blk_count等。这些是host驱动在probe时填好的告诉core我能干什么。当前状态ios当前IO设置时钟频率、总线宽度、时序模式、ocr当前工作电压、bus_mode等。操作回调host-ops指向一个mmc_host_ops结构里面是request、set_ios、get_ro、get_cd等函数指针。这是host驱动必须实现的核心接口。请求队列struct mmc_request *mrq指向当前正在处理的请求配合mmc_claim_host/mmc_release_host做互斥。设备模型相关class_dev、parent等用于sysfs呈现。host驱动probe的时候典型流程是申请mmc_alloc_host拿到一个host结构填好ops和能力字段然后mmc_add_host把它注册进框架。注册之后core层就会开始跑卡检测流程。这里有个容易踩的点mmc_alloc_host的第二个参数是sizeof_priv用来给host驱动分配私有数据空间。很多驱动会把自己的私有结构体塞在这里通过mmc_priv(host)拿到。这个设计避免了额外的内存分配但要注意私有数据是跟在host结构后面的别越界。3.2 mmc_card一张被识别出来的卡struct mmc_card代表一张已经完成枚举的卡。它是在卡识别流程成功后由core层创建的里面记录了这张卡的身份和能力type卡类型是MMC、SD、SDIO还是组合卡。cid、csd、ext_csd、scr这些是从卡里读出来的寄存器数据CID是卡的身份信息厂商、序列号CSD是卡的具体参数容量、速度SCR是SD卡配置寄存器。rca相对卡地址枚举时分配的后续通信用它来寻址。ocr工作电压。host指向它所属的host。state卡当前状态。一张卡从插入到被识别要经历一系列命令交互core层把这些交互的结果填进mmc_card。识别完成后如果是存储卡会创建块设备如果是SDIO会创建功能设备。3.3 mmc_bus连接host和card的总线抽象struct mmc_bus_ops定义了总线操作比如runtime_suspend、runtime_resume、power_off等。core层为不同类型的卡注册不同的bus比如mmc_bus、sd_bus、sdio_bus。当一张卡被识别为SD卡时它会被挂到sd_bus上然后匹配对应的驱动。这个bus机制是Linux设备模型的标配好处是电源管理、热插拔这些通用逻辑可以统一处理。比如系统进入suspend时会遍历总线上所有设备调用它们的suspend回调。3.4 mmc_request与mmc_command、mmc_data的关系一次完整的mmc传输在框架里用struct mmc_request表示。它包含cmd指向一个mmc_command描述要发的命令命令码、参数、期望的响应类型。data指向一个mmc_data描述要传的数据数据块数、块大小、DMA方向、scatterlist。done完成回调host驱动处理完请求后调用它通知core。stop可选的停止命令用于多块传输的收尾。mmc_command里最关键的是opcode命令码、arg参数、flags响应类型标志比如MMC_RSP_R1表示期望R1响应、resp[]存放响应数据。mmc_data里则是blksz、blocks、sgscatterlist、flags方向、是否DMA等。这三者的关系是一个request包含一个command可能包含一个data。command负责发指令data负责搬数据。比如读一个块就是发CMD17读单块命令然后跟着数据传输。注意mmc_request是异步的。core层把request交给host驱动后host驱动去操作硬件完成后调mmc_request_done通知core。这中间core可能去处理别的host所以host驱动必须保证自己的状态是自洽的。4. 命令、响应与数据传输的基本机制4.1 命令格式与响应类型MMC/SD协议的命令是48位定长除了CMD0和CMD8等少数包含起始位、传输位、命令索引、参数、CRC、结束位。命令索引就是常说的CMD0、CMD1、CMD17这些。参数是32位含义随命令不同而不同。响应分几种类型这是理解协议的关键响应类型长度典型命令含义R148位CMD3、CMD7普通响应含卡状态R1b48位忙CMD12、CMD28R1加忙信号R2136位CMD2、CMD9长响应含CID/CSDR348位ACMD41含OCR无CRCR648位CMD3含RCAR748位CMD8含电压和校验host驱动在mmc_command的flags里标明期望哪种响应core层根据响应类型解析resp[]数组。比如R2响应是136位会占resp[0]到resp[3]四个32位字。4.2 数据传输PIO、DMA与ADMA数据传输是host驱动最复杂的部分。常见方式有三种PIOCPU逐字节读写FIFO。简单但慢适合小数据量或调试。SDMAhost控制器自带的DMA用一个连续的物理缓冲区。受限于缓冲区必须连续。ADMA高级DMA支持scatterlist能处理分散的内存页。现代host基本都用这个。core层通过mmc_data的sg字段传scatterlist给host驱动host驱动根据自己支持的方式决定怎么搬。如果host只支持SDMAcore层会提前把数据整理到连续缓冲区通过mmc-ops-pre_req/post_req或者core内部的bounce buffer。这里有个性能相关的点max_seg_size和max_blk_count决定了单次请求能传多少数据。core层在提交请求前会检查是否超过host能力超了就拆分。所以host驱动如实报告自己的能力很重要报小了性能上不去报大了可能出错。4.3 时钟与总线宽度的动态切换SD/MMC协议支持在初始化阶段用低速时钟通常400kHz识别完成后再切到高速。总线宽度也从1位逐步切到4位或8位。这些切换通过mmc_host_ops-set_ios回调实现。struct mmc_ios里包含clock时钟频率、bus_width总线宽度、timing时序模式比如MMC_TIMING_HS、MMC_TIMING_HS200、power_mode电源模式等。core层在流程的合适时机调用mmc_set_ioshost驱动根据这些参数去配置寄存器。提示调试卡识别问题时经常需要看set_ios被调用的时机和参数。如果时钟切换太快或者总线宽度切换时机不对卡可能就失联了。低温下识别失败很多时候是时序裕量不够可以尝试降低初始时钟或延后高速切换。5. 卡识别流程从插入到可用的完整链路5.1 卡检测CD引脚与轮询卡检测有两种方式。一种是CDCard Detect引脚host控制器有专门的引脚检测卡槽里有没有卡状态变化触发中断。另一种是轮询core层定期发命令探测。前者实时性好后者省引脚。在设备树里CD引脚通常配成GPIOhost驱动通过mmc_gpio_get_cd或者注册mmc_host_ops-get_cd回调来报告卡状态。core层在mmc_rescan里检查这个状态决定是否启动识别流程。mmc_rescan是个work会被定时调度默认延迟HZ也会被CD中断触发。它先检查卡是否还在不在就清理在的话就尝试识别。识别失败会重试重试间隔逐渐拉长。5.2 上电与初始化CMD0、CMD8、ACMD41识别流程大致如下以SD卡为例上电core层通过mmc_set_ios设置电压和初始时钟400kHz。CMD0复位卡到idle状态。CMD8探测卡是否支持2.0以上协议同时协商电压。如果卡不响应说明是老卡。ACMD41发送SD_APP_OP_COND带OCR参数反复发送直到卡返回忙结束表示初始化完成。这一步会确定卡的电压范围和是否是高容量卡SDHC/SDXC。CMD2获取CID这是卡的唯一身份。CMD3让卡发布RCA进入standby状态。CMD9读CSD拿到容量、速度等参数。CMD7选中卡进入transfer状态。ACMD51读SCR确认总线宽度能力。CMD6切换总线宽度和速度模式。MMC卡的流程类似但命令细节不同比如用CMD1代替ACMD41用CMD8做别的用途。5.3 识别成功后的设备注册识别完成后core层创建mmc_card根据卡类型挂到对应的bus上。如果是存储卡mmc_blk会创建块设备/dev/mmcblkX出现同时sysfs下能看到容量、CID等信息。如果是SDIO会枚举function匹配sdio_driver。这里有个细节SDIO卡的枚举比存储卡复杂因为SDIO有CIACommon I/O Area和多个function需要读CISCard Information Structure来了解每个function的能力。这部分在core/sdio.c里实现。注意识别流程中任何一步失败core层都会记录错误并可能重试。看日志时mmc0: error -110通常表示命令超时-84表示CRC错误。超时可能是时钟问题或硬件连接问题CRC错误可能是信号完整性问题。6. 常见问题与排查思路实录6.1 卡识别失败从日志到定位识别失败是最常见的问题。排查顺序建议这样看日志dmesg | grep mmc找到第一个报错的地方。是CMD0就失败还是CMD8还是ACMD41超时不同阶段失败指向不同原因。查供电用示波器看卡槽的VCC和VCCQ是否正常上电时序是否符合协议要求。有些卡对上电斜率有要求。查时钟初始时钟是不是400kHz有没有在识别完成前就切到高速时钟信号质量如何查信号CMD和DAT线的上拉电阻是否合适走线是否等长有没有串扰查设备树CD引脚配置对不对电压范围配得对不对vmmc-supply和vqmmc-supply有没有正确关联低温识别失败往往是时序裕量问题。可以尝试降低初始时钟频率、延后高速模式切换、增加命令重试次数。有些host驱动支持调整采样点tuning在高速模式下尤其重要。6.2 数据传输错误与超时数据传输阶段的错误常见的有错误现象可能原因排查方向CRC错误信号完整性、时钟相位调整采样点、检查走线超时时钟太快、卡忙降频、检查卡状态DMA错误scatterlist不合法、地址对齐检查sg配置、对齐要求数据错位总线宽度配置错误确认set_ios参数host驱动里通常有错误恢复逻辑比如重置控制器、重新初始化。如果错误频繁说明硬件或配置有问题不能只靠软件重试掩盖。6.3 性能不达预期瓶颈在哪如果卡能识别、能读写但速度上不去可以从几个方面查总线宽度是不是还停在1位模式4位和8位能差好几倍。时钟频率有没有切到高速模式HS200、HS400这些模式需要host和卡都支持。DMA方式是不是还在用PIO换成ADMA能大幅提升。请求合并core层有没有把多个小请求合并成大请求max_blk_count设得合不合理文件系统块设备层的调度器、文件系统的块大小也会影响。实测下来同样的硬件把总线宽度从1位切到4位、时钟从400kHz切到50MHz顺序读写速度能有几十倍的差距。所以性能调优先看这两项。7. 几个容易混淆的概念澄清7.1 host与controller的区别严格说mmc_host是框架对控制器的抽象但一个物理控制器可能对应多个mmc_host比如某些SoC的SD控制器支持多卡槽。日常交流里大家混着说但看代码时要清楚mmc_host是软件对象不是硬件本身。7.2 card与device的区别mmc_card是mmc子系统内部的抽象而device是Linux设备模型的通用抽象。一张存储卡最终会对应一个块设备device但mmc_card和那个device不是一回事。mmc_card在core层块设备在card/block.c里创建。7.3 命令与请求的区别命令command是协议层的概念指一次CMD线上的交互。请求request是框架层的概念指core层提交给host驱动的一次完整任务可能包含命令和数据。一个请求至少有一个命令可能还有数据。8. 写在最后框架学习的个人体会我刚开始看mmc子系统的时候最大的障碍是分不清哪些代码是框架哪些是驱动。后来摸索出一个方法先看include/linux/mmc/host.h和core/core.c把mmc_host_ops里每个回调的语义搞清楚然后找一个简单的host驱动比如sdhci或者某个平台的dw_mmc对照着看它怎么实现这些回调。这样框架和驱动的边界就清楚了。另一个体会是mmc协议本身不难难的是各种时序和边界情况。协议文档里那些卡应该在X个时钟内响应的要求在代码里就是各种超时和重试逻辑。调试的时候示波器和逻辑分析仪比printk管用得多尤其是信号完整性问题软件层面看不出来。最后这个框架的代码量不小但结构是清晰的。建议按host→core→card的顺序读先理解host驱动要提供什么再看core怎么用这些接口最后看上层怎么消费。不要一上来就扎进core/core.c的细节里容易迷路。