SDIO常见问题指南
搞 mmc驱动就没办法只搞 eMMC或者是 SD Card这单一驱动，除非你是在 Intel、MTK或者是big Hisilicon吧。原因主要是两点，第一点，eMMC、SD Card和SDIO都是在 MMC Card基础演进，技术点上有很多相同之处；第二点，IP核大部分公司用的都是 Synospsys的 DesignWare IP（dw/dwc），这个可以在 Linux代码中略窥一二，主要是看文件名和寄存器的 bit偏移。毕竟自研 IP是个系统性的工程，需要投入大量的人力，而且功能和兼容性还需要时间的积累、迭代，还是直接用买到的轻松。不过在当前这个大环境，自研 IP是一个让人血液沸腾，十分有意义的事情😆。
扯完了，下面开始正题吧。
eMMC、SD、SDIO三者虽然同源，但是问题爆发的时间点却是不一样的。eMMC作为关键路径，问题基本在样片阶段就被发现、解决完了，它追求的不是能用，而是稳定；SD卡问题多出现客户侧或是用户侧，主要原因是市场上什么牛鬼蛇神都可以生产 SD卡，可想而知它们的质量与兼容性是个让人头疼的事情；SDIO的问题则多出现在与 SDIO设备对接的研发阶段，不管是在原厂还是客户研发侧，而且目前还没有见过 SDIO自身的问题，dwc和 Linux真是稳。
SDIO问题基本集中在识别类上，主要有以下几种情况：
1、对接的 SDIO WiFi模组没有给电或是没使能。
处理的第一个客户问题就是这个，RTL8189不识别，当时接手 mmc模块没两个月，客户凶的厉害，让我这个 USB老司机怂得不敢和客户电话沟通😶。软件 check了一圈没啥毛病，看 log是 device没有对 host的命令返回 Response。客户不愿意把环境给到我定位，刚切换产品线的我，协调内部资源也是懵逼，最后在 AE帮助下总算搭好公板环境。公板也复现了客户问题，难道是漏出的缺陷？那事情就有点大了。后面找硬件确认 VCC、EN管脚和信号管脚等才发现，使能管脚一直为低，模块没使能怎么工作嘛，同步让客户修改，问题解决。
后续针对这个问题，还开了个回溯小会，分析问题漏出原因，后面根因涉及另外一个部门也就不了了之。会后感慨这个产品线的风格真棒，这就是为什么可以做到业界第一，把 TI打的满地找牙的原因之一吧。
针对 RTL819这个模块，有两种解法，第一种是硬件直接拉高 EN管脚，第二种软件控制拉高 EN管脚。其他模块可能要用第二种比较稳妥，当然这个问题也可以归类为上电时序。
2、SDIO WiFi模组或 SOC的 SDIO管脚虚焊。
这类问题，kernel log上看到的情况和第一个问题是一样的，但是在硬件排查时会发现相关信号管脚没有电平输出，或者信号比较奇怪。出现问题的阶段基本是在工厂产测时候发现的，工厂这时候就会说我要停产啦，这种停产问题就又急又严重，最高优先级的事项了。情况多是在一个批次中有一定数量的问题产品，客户做更换 SOC实验发现跟 SOC走，然后说你 SOC有问题😨，要赔偿了。这时候要冷静，客户的实验结果未经分析都不可信，首先要好好和客户确认实验数据，每个步骤的细节，总是能发现矛盾或者纰漏点的，这时候不能怼客户，因为他也急呀。秉持你们是一根绳上的蚂蚱，以及你是这块专家的心态，重新安排实验（可以提前想好要做的实验），尽可能的将软件相关问题排除完，下来拉通硬件、逻辑、芯片量产的人看看还有什么追加实验。如果是虚焊的问题，基本重新焊接问题就不复现了（实在不行换到公板上），抓住这个重点的实验现象，让硬件重点 check，让 FAE拉通客户侧资源 check，问题基本到这里就是客户自行解决了。据我了解，虚焊可以通过 X-ray检测，不知道是不是常规手段。
3、对接的 SDIO WiFi模组上电时序不对。
这类问题遇到蛮多的，基本都是 WL_REG_ON这类使能管脚没有拉高，或者拉高太早或太晚了，或者是万用表测量是高电平，实际上没有用上拉电阻，导致电平不稳定。在 kernel log上看到的情况和第一个问题是一样的。也有某厂家的模组（利益相关，不说是谁了），上电时序要求及其严格，模组供电、管脚使能、模组时钟的供给都要十分精确，只能放到它自己的驱动代码里实现了。
4、host对 SDIO的管脚复用配置错误。
这类问题多在系统迭代升级遇到，在 kernel log上看到的情况和第一个问题是一样的，硬件的检测也没啥问题，只能依靠经验在 u-boot阶段或是 sdio rescan阶段把 CMD、DATA和 CLK管脚的管脚复用寄存器打印出来，确认和配置值是否一致。是在 u-boot还是 sdio rescan阶段还要看整体方案设计的管脚复用是在哪个阶段配置的，如果是在 sdio驱动代码中配置，则要在 Linux终端上确认是否被别人改动了。
5、host没有给 SDIO逻辑提供运行时钟。
这类问题是有点搞笑的，只遇到一次，某些 SE（System Engineer）以为自己知道系统全貌，就开始瞎搞，人为的为他人制造问题，浪费项目人力，正常操作是不懂就要拉通对应 CBB问，确认🤨。
这个问题出现的场景可能是，前几天还能识别的 SDIO WiFi，今天突然就不识别了，这段时间我也没上代码到库上呀，奇怪。Kernel log上会出现 “Hardware doesn’t specify base clock frequency”，再读下 host控制器的 SDHCI_CAPABILITIES（0x40），发现是 0x0，那这个问题就是逻辑没有运行时钟了。
6、host对 SDIO的 dts节点配置错误。
这个问题要根据具体的硬件环境配置和软件方案排查，如果 VCC是恒供电，SDIO WiFi模组也是焊接在 PCB上的，那 dtsi就不应该有 “full-pwr-cycle”，同时还要有 “non-removable”，见到有 “cap-mmc-hw-reset”这些没半毛钱关系的节点也要去掉，还可以加入 “no-sd”，“no-mmc”这些描述告诉协议栈不用发多余的命令去 check device具体是什么设备。
问题排查流程总结：
1、硬件确认 VCC、EN、信号管脚，确认上电时序是否符合模组手册要求；
2、客户硬件设计特殊，让硬件 check电路设计，是否符合设计约束；
3、软件确认客户是否有私有修改，dtsi是否正确描述；
4、根据 kernel log分析，不充分就合入 debug patch，查看 CMD和 Response；
5、device不响应 CMD，需要考虑硬件问题或是管脚复用等；
6、不响应特定 CMD，则跟随协议与 kernel代码流程，确认是否 device原因；
7、读取控制器关键寄存器，确认控制器状态（SDHCI_HOST_CONTROL 0x28、SDHCI_CAPABILITIES 0x40等）和交互状态（SDHCI_PRESENT_STATE 0x24、SDHCI_INT_STATUS 0x30）；
8、先进行软件还是硬件排查这个是不确定的，软件最快速的排查方法是合入 debug patch，查看 CMD和 Response以及熟悉协议流程，这个很重要。