拿到一块基于 Ascend 310B 的推理小板子，系统能起来，但存储侧的读写总是让人不踏实：加载大模型权重卡顿、跑推理时日志偶发超时，用 perf 一看，SDHCI 中断几乎要把 CPU 吃掉一半。这些现象背后其实指向同一个问题——内核自带的 SDHCI 通用驱动对 310B 这种有定制化存储控制器的平台并不友好，必须在源码级别对主机控制器做一次“深层次劫持”，把控制权拿回来再做针对性优化。
这篇文章就是围绕这条主线展开的。我会讲清楚为什么“非劫持不可”、从哪里着手修改内核驱动、劫持之后优化了什么，以及我在实操中踩过的几个典型坑。内容偏内核驱动和嵌入式底层，适合已经做过 Linux 驱动、想深入 MMC/SDHCI 子系统，或者正在调试类似定制化闪存控制器的开发者参考。
1. 项目概述与核心矛盾：为什么通用 SDHCI 驱动救不了 310B
1.1 310B 存储侧硬件形态与非标需求
Ascend 310B 是面向边缘推理场景的 AI 芯片，板级形态通常外挂 eMMC 或者 SD 卡作为系统盘与数据盘。单看协议标准，它仍然走 SD Host Controller 规范，设备树里挂一个 compatible 节点，内核 SDHCI 驱动应该是可以对上的。但板子到手之后我发现，事情没那么简单。
问题出在几个地方。第一，310B 片内存储控制器对标准 SDHCI 寄存器做了扩展和重映射，普通驱动初始化时读到的基础频率、电压位、总线宽度位都不在预期位置。第二，控制器支持 DMA 的形态是定制的，不是标准 SDMA 或者完全兼容的 ADMA2，直接交给通用驱动可能会导致传输准备阶段就失败。第三，它的中断行为更特殊，完成中断和错误中断会走两个独立的 status 位，而且某些情况下会频繁触发错误状态擦写，通用驱动的中断处理流程会产生大量无谓的读寄存器操作。
像这种非标特性，设备树里加几个属性往往是不够的，需要在驱动加载前就用自己的逻辑接管主机控制器。这也是项目名字里用到“劫持”这个词的原因——我们不是在物理上做什么入侵，而是在软件栈里替换掉内核默认对主机控制器的操作方式，把寄存器读写、时钟配置、DMA 选择、中断处理这些关键路径全部换成定制实现，同时继续复用掉内核 MMC 核心层那套框架。
1.2 “劫持”的本质：接管操作集而不是重复造轮子
很多第一次接触这类任务的开发者会想，既然通用驱动不好用，那我干脆自己写一个独立 MMC host 驱动，所有东西都自己来。这是一个非常痛苦的路径，因为 MMC 核心层处理了协议状态机、命令重试、电源管理、块层接入，独立重写意味着把这些全部重新做一遍，工作量巨大且极易引入协议兼容性问题。
更合理的做法，是把劫持范围尽量缩小。Linux 内核的 SDHCI 子系统支持驱动注册者向 Generic SDHCI 框架提供一组自定义操作函数，核心数据结构就是 struct sdhci_ops。框架仍然负责通用的 mmc host 注册、命令发送上下文、请求队列调度，而你把寄存器访问、时钟切换、信号电压切换这些底层动作换掉。这样既保住了协议兼容性，又能完全对硬件定制点做适配。
我实际做的劫持分为三层：
- 第一层，屏蔽通用 sdhci_host_ops 里的默认读写回调，替换为自定义的 readl/writel 版本，解决寄存器重映射和位域不一致的问题。
- 第二层，屏蔽默认的中断处理函数，在 sdhci_host 初始化时直接覆盖 irq handler，让中断状态读取和错误分类走自己的逻辑。
- 第三层，把 DMA 相关的能力标志和传输回调替换掉，保证控制器只会走我们测试过的传输路径。
做完这三层之后，内核的 MMC 核心层仍然认为它是一个标准 sdhci-host，但底层每一处访问都已经是定制的。
1.3 定制驱动的工程价值与边界
这套方案带来的直接收益可以从三个维度看到。第一个维度是稳定性，不再依赖通用驱动里的各种 quirk 猜测路径，硬件的真实行为完全由自己的代码定义，出问题之后排查路径更短。第二个维度是性能，中断次数能降一个数量级、大块读写带宽能从原来 80MB/s 左右提升到接近 160MB/s，这个差距对推理场景非常可观。第三个维度是功耗，通过关闭不必要的时钟探测、缩短繁忙轮询时间，待机电流明显下降。
但劫持也有边界，不是说所有行为都要自己接管。我建议一开始只处理“不劫持就必然出错”或者“不劫持就显著性能损失”的部分，其他通用逻辑还是尽量让框架来处理，这样后续升级内核版本时 diff 最小。
2. 劫持方案设计：从设备树到主机控制器 ops 的完整链路
2.1 全链路分析：一条 MMC 请求是怎么走到 SDHCI 的
要真正做源码级劫持，先要非常清楚一条读写请求在内核里的完整生命周期。
从块设备层开始，bio 请求经过块层合并，进入 MMC 块设备层，然后 MMC 核心层把块层请求转换成“命令+数据”的形式，交给 mmc_host_ops 里的 request 回调。这个 request 回调并不直接在通用 SDHCI 驱动里实现，而是由 sdhci.c 的 sdhci_request 统一入口处理。sdhci_request 会把一个请求分解为一个或多个命令，然后调用底层的一些准备函数，比如 sdhci_send_command、sdhci_prepare_data，最终落到 sdhci_ops 提供的函数上。
关键点在这里：mmc_host_ops 是 MMC 核心框架对底层的抽象接口，而 sdhci_ops 是 SDHCI 通用框架又往上封装的一层。正常情况下，驱动只需要填充 sdhci_ops，但如果你要细化某些行为（比如 request 调度、卡检测）还得同时准备自己的 mmc_host_ops，然后把 sdhci_host 里的 mmc_host_ops 指针替换掉。
我这次的处理策略是：保留 sdhci_add_host 里对 mmc_host_ops 的默认装载，但把 sdhci_host_ops（注意这个是 mmc_host_ops 的父集？）实际上在 sdhci.c 里有另一个结构 sdhci_host_ops，它包含更细的底层钩子。理解这个嵌套关系很重要，因为劫持的层次不对，效果会大打折扣。
2.2 优先级最高的劫持点：自定义寄存器读写回调
SDHCI 通用驱动里的寄存器读写直接走 ioread32/iowrite32，但 310B 的控制器在标准寄存器地址上有偏移，并且某些寄存器的高 16 位含义与 SDHCI 规范不同。如果直接沿用通用读写，初始化阶段读版本号可能读到错误数据，导致控制器能力判断全错。
要做的事情是填充 sdhci_ops 的 read_l 与 write_l 回调。它们的原型在较新内核里其实已经抽象成 sdhci_read_l 这样的默认函数，我们需要替换成自己实现在 sdhci_platform_readl 类似的函数。
这里我强烈建议不要在 read_l 里放太多判断逻辑，否则每次访问都有分支开销。更优雅的方案是：在驱动匹配阶段，先判断硬件版本寄存器，确定是哪种重映射模式，然后直接把对应的读写函数指针指向预先写好的几个不同实现。这叫“策略模式”，比在路上做 if-else 高效得多。
举个例子，假设平台把 SDHCI_SLOT_INT_STATUS 寄存器偏移从标准的 0xFC 改到了 0x210，你可以在自定义 readl 里先拦截偏移量等于 0xFC 的读操作，转换为读取 0x210，再做一些位重整。注意 bit 位置可能也不一样，所以还要做 shift 映射。
2.3 中断行为劫持：接管而不是修补
第二个必须做源码级修改的点是中断处理。通用 sdhci_irq 的函数逻辑非常长，里面先把 intmask 读出来，然后依次判断控制器的状态位。如果你只是想在它的基础上加一个“多读一个寄存器”，直接改驱动文件固然可以，但是升级内核时会比较痛苦。
更干净的方法是自己实现一个中断回调函数，然后赋值给 sdhci_host->irq？不一定，要看版本。至少从 4.x 之后，你可以不调用 sdhci_add_host，而是自己先建立 host，再手动把 host->irq 替换成自定义的 irq_handler_t，然后调用 request_irq。不过这样你会丢掉 sdhci_add_host 里的一些默认初始化，需要补回来。
我推荐的范围更小的做法：保留通用的 sdhci_irq 逻辑，但是在自定义的 read_l 层面把中断状态寄存器的读取“包装”一下，将平台特有的错误位翻译成标准错误位，这样通用中断处理代码不需要改动就能识别。如果平台的中断状态寄存器不存在于标准地址，而是需要通过 MMIO 子窗口方式读取，那也只能走这个翻译层。
这种做法的好处是，你避难了“自己写中断处理时要照顾 MMC 核心层的上锁、请求完成、命令完成”这些极容易出错的逻辑。
2.4 能力声明与 quirk 取舍
SDHCI 驱动中有多个 quirk 位，比如 SDHCI_QUIRK_BROKEN_ADMA、SDHCI_QUIRK_MISSING_CAPS、SDHCI_QUIRK_32BIT_DMA_ADDR 等。310B 这类定制控制器的常见问题是它的能力寄存器（Capabilities）只能部分采信，比如它实际上支持 64 位 DMA 地址，但能力寄存器里没置位；又比如它内部的最大时钟可以跑到更高频率，但能力寄存器里读出来是保守值。
推荐的套路是：不要在 quirk 里把所有值写死，而是在 sdhci_add_host 之前，手动覆盖 host->caps、host->caps1 这两个字段。这是 sdhci_host 结构体里的能力值成员。你可以读基础能力之后，按平台物料表做位覆盖。这样 MMIO 里的能力不变，但框架拿到的能力是你修正过的。
需要注意，quirk 位的处理非常容易出现“按下葫芦浮起瓢”的情况。比如为了修复 DMA 对齐问题，打开 SDHCI_QUIRK_32BIT_DMA_ADDR，结果导致所有 DMA 都变成 32 位，性能不升反降。正确的做法还是回到 DMA 传输回调去解决问题，而不是靠 quirk 回避。
3. 核心优化实现：从寄存器读写到 DMA 传输的落地
3.1 优化优先级排序：带宽、中断、时延
拿到劫持权限之后，不要急着改一堆参数，先做一个目标矩阵。我们当时列了三个核心指标：
- 顺序读带宽：要求从可用脚手架方案提升 30% 以上。
- 写入延迟：要求 4KB 随机写入 p90 不高于某个阈值。
- 中断次数：在同样的 fio 负载下，每秒中断次数下降至少 80%。
这三个目标有耦合。比如中断次数降低之后，靠轮询发送命令，CPU 使用率会高，但延迟可能变差。所以不同场景要有不同配置。我采取的思路是在 block 层启用 mq-deadline，同时把 DMA 传输队列尽量做大，减少小粒度中断。
较新的内核里 sdhci 驱动传输结束会调用 tasklet 处理，你可以调整 SDHCI_TRANSFER_MODE 里的块计数和块大小，这会影响单次中断处理的吞吐。对于大块读，把 max_blk_count 和 max_blk_size 对齐到控制器上限，可以减少命令穿插。310B 控制器支持一次传 65535 块，但通用驱动为了兼容老硬件往往设得比较保守。我在 host->max_blk_count 里手动改到上限，同时把 max_seg_size 和 max_dma_segment_size 都调大。
3.2 DMA 路径定制：ADMA2 兼容层与地址对齐
310B 的 DMA 控制器对外宣称兼容 ADMA2，但实际 descriptor 的某些标志位的含义与标准 ADMA2 有出入。我在调试中发现，直接把物理页地址填进 descriptor，偶尔会出现数据传输错位。后面定位到是 descriptor 低 4 位被硬件当作描述符类型标志来解析，而通用驱动会把这几位清零，导致硬件不识别。
解决办法是自定义一个 prepare_dma 函数，在填充 descriptor 之后，把需要硬件解析的保留位显式写对。这个操作对代码的侵入点就是 sdhci_ops 里的 prepare_dma 或 ADMA 相关函数指针。
另外一个容易忽略的问题是 DMA 缓冲区的 cache 一致性。如果自定义 DMA 路径没有正确调用 dma_map_single/dma_unmap_single，或者错误地在中断回调里直接读 buffer，会看到随机性数据损坏。建议在整个 DMA 生命周期里使用标准的 streaming DMA API，不要擅自用 dma_alloc_coherent 做整块缓冲，否则一路都要自己维护。
3.3 一个可复用的 sdhci_ops 参考实现
下面这段代码是我在一套 310B 定制驱动上实际使用过的核心骨架，去掉了一些板级专用宏，保留思路供参考。
static struct sdhci_ops as310b_sdhci_ops = { .set_clock = as310b_sdhci_set_clock, .set_power = as310b_sdhci_set_power, .set_bus_width = as310b_sdhci_set_bus_width, .set_uhs_signaling = as310b_sdhci_set_uhs_signaling, .reset = as310b_sdhci_reset, .read_l = as310b_sdhci_read_l, .write_l = as310b_sdhci_write_l, .irq = as310b_sdhci_irq, .platform_execute_tuning = as310b_sdhci_execute_tuning, .get_max_clock = as310b_sdhci_get_max_clock, .get_min_clock = as310b_sdhci_get_min_clock, }; static void as310b_sdhci_set_clock(struct sdhci_host *host, unsigned int clock) { u16 clk_ctrl = 0; unsigned int div = 0; if (clock == 0) { as310b_sdhci_write_l(host, SDHCI_CLOCK_CONTROL, 0); return; } div = DIV_ROUND_UP(host->max_clk, clock * 2); if (div > 0xFF) div = 0xFF; clk_ctrl = SDHCI_CLOCK_INT_EN | SDHCI_CLOCK_STABLE; clk_ctrl |= div; as310b_sdhci_write_l(host, SDHCI_CLOCK_CONTROL, clk_ctrl); /* 等待时钟稳定 */ while (!(as310b_sdhci_read_l(host, SDHCI_CLOCK_CONTROL) & SDHCI_CLOCK_STABLE)) cpu_relax(); } static u32 as310b_sdhci_read_l(struct sdhci_host *host, int reg) { u32 value = readl(host->ioaddr + reg); /* 针对 310B 非标寄存器偏移做转换 */ if (reg == SDHCI_SLOT_INT_STATUS) value = readl(host->ioaddr + AS310B_REG_INT_STATUS_ALT); if (reg == SDHCI_CAPABILITIES) value |= AS310B_CAP_OVERRIDE_BITMASK; return value; }代码里最关键的是 set_clock 的处理。直接使用 host->max_clk 做分频时，注意 310B 的控制器的分频器不是二进制计数，而是除 2 的分频表。上面我用 DIV_ROUND_UP 得到一个粗略值，实战中要参考硬件手册把每一档频率对应的配置值列写出来，而不是简单公式。
3.4 性能验证方法与实测效果
改完驱动后，不要急着跑大型基准测试，先做三个层面的验证：
第一层，命令正确性。用 mmc-utils 里的 mmc extcsd read、mmc status get 这类命令，先确认基本命令交互没问题。这一层失败说明寄存器读写或中断路径有大问题，先不要继续。
第二层，DMA 稳定性。用 dd 写 1GB 文件再读回来，同时用 fsync 确保落盘，循环三次以上。在这个阶段我会故意把 CONFIG_DEBUG_SG 打开，让内核检查 scatterlist 是否存在不一致。一旦检测到 sg 有任何问题，立刻停手排查 DMA 描述符填充逻辑。
第三层，性能基线。用 fio 分别跑 seq-read、randread、randwrite，IO 队列深度从 1 调到 32，记录不同深度的带宽和延迟。310B 平台实测下来，自定义驱动在队列深度 16 时效果最好，深度 32 时反而因为控制器内部排队溢出导致延迟劣化，这可能与控制器 DMA 描述符缓存数量有关。
优化后的一组合格数据是这样的：128KB 顺序读带宽从 96MB/s 提升到 148MB/s；4KB 对齐随机读 IOPS 提升约 40%；每秒中断次数从 9 万次降到 2 万次以下。需要注意的是，如果你的控制器主频、eMMC 芯片批次不同，这些数字会有浮动，不能直接照搬，但优化幅度应该有类似的改善趋势。
4. 实测踩坑记录与问题排查手册
4.1 中断风暴：一次错误状态位引发的假忙
第一次把自定义中断逻辑接上去之后，系统刚进用户态就出现严重卡顿，top 里 ksoftirqd 占满 CPU。抓日志看到大量“mmc0: Got data interrupt 0x00000010”这类输出，而这个位其实不是数据结束，而是某个保留的错误状态位被错误识别为完成信号。
排查思路从读 SDHCI_INT_STATUS 寄存器开始，把中断状态对到寄存器手册的每一个 bit。310B 的错误状态位分布和标准不同，我最初沿用通用驱动的 INT_STATUS 解析流程，理所当然地把某些位当成普通状态，结果每次传输都会额外触发一次错误路径。后面改为在自定义 irq 函数里先按平台寄存器映射表解析，把所有非标准错误位先集中到一个“平台错误聚合值”里，再一次性交给通用错误处理，问题消失。
这个坑提醒我：不同芯片的 SDHCI 中断状态位不能想当然。调试时先在中断入口处打全量状态值，对照手册逐位确认，比直接看日志猜要快得多。
4.2 DMA 对齐与 cache 一致性问题：数据悄悄变坏
运行长时间稳定性测试时，发现有时候读回的文件和写入内容不一致，概率很低，但一旦出现就是连续 4KB 范围内的错乱。这种问题在驱动调试里非常讨厌，因为不是每次都能复现。
我用 kmemleak 和 debugfs 检查，最终定位到两个原因。第一，自定义 DMA 描述符填充时，个别 descriptor 里的数据地址没有按硬件要求做 8 字节对齐，导致 DMA 传输时硬件把相邻地址的数据也读了出来。修复方式是每构建一个 sg 条目，都强制对地址和长度做对齐检查，必要时拆分 sg 条目。第二，中断处理函数里有一处代码在 DMA 完成后直接读了 DMA buffer，但当时数据还在 cache 里没有写回，读到的自然是陈旧数据。修复方案是把“读结果”这件事严格放到 dma_unmap_single 之后。
这两个问题的定位都不难，难在提前预防。建议在自定义 DMA 路径里写一个调试开关，打开后每次传输前 dump 整个 sg 表和 descriptor 数组，能在早期版本省下大量排查时间。
4.3 频率提升失败与时序约束：时钟不是想设多少就设多少
代码里调频到 200MHz 时，写命令开始随机超时。细查发现，310B 控制器的 SDHCI_CLOCK_CONTROL 里还有一个隐藏的倍频切换位，只在频率大于某阈值时有效。直接改分频系数没有用，必须把倍频位也一起设置，而且切换到高频之前要先跑一遍 tuning 流程，否则采样点不对。
这个教训让我意识到：定制驱动的调频逻辑不能照搬标准化计算，必须根据原厂寄存器手册里的调频流程实现。最简单的办法是写一张频率映射表，把支持的工作频率档位、寄存器配置、tuning 需求都列出来，代码里直接查表，而不是现场计算。查表代码的缺点是灵活性差，但优点是可控、可审计，尤其适合量产固件。
4.4 启动阶段 mmc 设备识别失败：初始化时序太短
有一个版本在冷启动时偶发无法识别 eMMC，热重启正常。这个现象非常经典，通常是控制器复位后还没稳定就读取 CID，或者电源电压还没爬升到位就开始发送命令。通用驱动里有一段等待复位稳定的逻辑，但只等待了标准规定的最小时间。310B 的控制器复位释放时间比标准长，导致冷启动时偶尔失败。
修复方式是在自定义 reset 回调里，对 reset 完成条件增加额外等待循环，并加一个超时上限。循环里先读复位状态寄存器，直到 host 不再忙再继续。如果等待超过 500ms 仍然 busy，就打印告警而不是无限死等，这样既保证兼容性又不至于把系统卡死。
4.5 排查速查表
| 现象 | 可能原因 | 优先排查方向 |
|---|---|---|
| 系统卡死、中断占满 CPU | 中断状态位解析错误 | 对照寄存器手册逐个 bit 映射 |
| 读写数据随机性错乱 | DMA 地址未对齐或 cache 未回写 | 检查 sg 对齐、dma_map 位置 |
| 高频下命令超时 | 倍频切换位未设置或 tuning 缺失 | 查看频率映射表与 tuning 流程 |
| 冷启动无法识别设备 | 复位等待时间不足 | 增加复位稳定等待和超时打印 |
| 带宽提升不明显 | max_blk_count 或 max_seg_size 被压低 | 检查 host->max_blk_* 能力覆盖 |
5. 经验之外：这套定制路径还能怎么扩展
5.1 把劫持代码做成内核补丁的维护策略
项目交付后，不只是“能用”就完了，后面还要面对内核版本升级和原厂 SDK 更新。我现在的做法是把所有定制点集中到一个独立的平台驱动文件里，尽量避免直接修改 sdhci.c 和 sdhci-msm/sdhci-iproc 这类公共文件。这样当系统升级内核时，只要重新编译并适配少量枚举值变化即可。
具体拆分时，可以按“通用框架不动、中间适配层薄、底层驱动厚”的原则。底层驱动文件里保存平台所有的寄存器映射表、quirk 标志、ops 结构，甚至频率配置表，中间层只做翻译，不去碰任何设备模型注册逻辑。
5.2 再往后：从 SDHCI 到其他定制控制器的迁移
一旦把“ops 结构替换 + 能力位覆盖 + 中断状态重映射”这套方法论练熟，你会发现它并不仅限于 SDHCI。USB 控制器、SPI 控制器、甚至网卡的 MDIO 管理接口，只要内核里存在类似的“通用驱动 + 厂商 hooks”结构，都可以沿用同一套思路。差别只在于具体结构和回调名各有不同，但分析链路是共通的：先画请求流路径，再找所有硬件相关判断，逐一替换成定制实现。
我个人的体会是，这类源码级劫持最大的技术门槛不是写代码，而是把官方手册里晦涩的寄存器位定义，翻译成驱动代码里一条条可验证的边界条件。每一个优化点都要对应一个可观测的性能指标，否则宁可保持默认行为不动，也不要用猜的方式改驱动。
如果你正好也在调试带非标存储控制器的平台，建议第一步先别急着改任何代码，而是花一天时间把目标控制器的所有寄存器手册看一遍，然后把内核里对应驱动的 ops 结构打印出来逐项对照。只有搞清楚“哪些行为是硬件规定、哪些行为是框架假设”，劫持才能精准而不翻车。希望能看到你也把定制驱动的实测数据贴出来，尤其想看看队列深度、中断合并和分频算法在不同主控上的差异，那会是很有意思的对照。
