📚 课程目录第4章设备驱动与内存交互

4. 设备驱动与内存交互

好，咱们今天聊点硬核的——Cache一致性。这玩意儿，说白了就是嵌入式底层开发里最容易踩坑的地方之一。我做了十几年驱动，见过太多因为Cache没处理好导致的诡异bug：数据明明写进去了，读出来却是旧的；DMA搬运完了，CPU看到的还是缓存里的脏数据。嗯，今天咱们就把这个坎儿彻底迈过去。

4.1 先搞清楚Cache长什么样

在动手解决问题之前，得先知道对手是谁。Cache的结构，我习惯把它理解成一个分层级的“快递中转站”。

核心观点：Cache是CPU和主存之间的高速缓存，目的是弥合两者速度的鸿沟。但它的存在，也给DMA这类“绕过CPU”的数据通路带来了麻烦。

典型的ARM Cortex-A系列处理器，Cache分三层：

L1 Cache：每个核心独享，速度最快（1-2个时钟周期），分指令Cache和数据Cache。
L2 Cache：通常多个核心共享，速度稍慢（10-20个时钟周期）。
L3 Cache：部分高性能芯片才有，所有核心共享，容量最大但延迟也最高。

你想想看，CPU读一个变量，先看L1，没有再看L2，再没有才去主存里翻。这个机制本身没问题，但一旦DMA介入，事情就复杂了。

4.2 DMA与Cache一致性问题——到底谁坑了谁？

DMA控制器可以直接访问物理内存，不经过CPU。这就导致了一个经典的“双写”问题：

场景A：CPU写，DMA读——CPU把数据写进了Cache，但还没刷回主存。DMA直接从主存读，读到的是旧数据。
场景B：DMA写，CPU读——DMA把新数据写进了主存，但CPU的Cache里还留着旧副本。CPU读Cache，拿到的还是老数据。

这两种情况，都会导致程序行为完全不可预测。我曾经在一个视频采集驱动里遇到过：摄像头通过DMA把一帧图像数据放到内存里，CPU去处理时，发现图像有一半是花的。查了两天，最后发现是Cache没刷干净。

避坑指南：千万不要假设“数据量小就不会出问题”。Cache一致性跟数据量无关，只跟访问路径有关。哪怕只传一个字节，只要路径不一致，就可能翻车。

4.3 解决思路：两种武器

Linux内核提供了两套API来解决这个问题。我个人的经验是：选对工具，事半功倍。

API	适用场景	底层机制	性能开销
`dma_alloc_coherent`	长期、频繁的DMA传输（如网卡、音视频）	分配非缓存（Non-cacheable）或写合并（Write-combine）内存	低（无需手动维护一致性）
`dma_map_single`	临时、一次性的DMA传输（如块设备I/O）	在现有缓存内存上执行Cache刷新/无效操作	中（每次传输需要刷Cache）

4.4 dma_alloc_coherent——一劳永逸的方案

这个函数分配的内存，CPU和DMA看到的是同一份数据。说白了，就是让MMU把这段内存的页表属性设为“不缓存”。CPU访问时直接走主存，不经过Cache。

// 分配一致性的DMA缓冲区
dma_addr_t dma_handle;
void *cpu_addr = dma_alloc_coherent(dev, size, &dma_handle, GFP_KERNEL);
if (!cpu_addr) {
    dev_err(dev, "Failed to allocate coherent DMA memory\n");
    return -ENOMEM;
}

// 使用完毕后释放
dma_free_coherent(dev, size, cpu_addr, dma_handle);

这里有个细节：dma_handle是DMA控制器看到的物理地址，cpu_addr是CPU看到的虚拟地址。两者指向同一块物理内存。

我的建议：如果你的设备需要频繁做DMA传输（比如每秒几千次），优先用dma_alloc_coherent。虽然分配时稍慢，但运行时零开销。我在做千兆网卡驱动时，就是靠它把吞吐量从600Mbps提到了950Mbps。

4.5 dma_map_single——灵活但需要小心

有时候，你不想为了一个临时DMA操作去专门分配一致性内存。这时候dma_map_single就派上用场了。它会在现有内存上做Cache一致性维护。

// 映射一个缓冲区用于DMA传输
dma_addr_t dma_handle = dma_map_single(dev, cpu_addr, size, DMA_TO_DEVICE);
if (dma_mapping_error(dev, dma_handle)) {
    dev_err(dev, "DMA mapping failed\n");
    return -EIO;
}

// 传输完成后解除映射
dma_unmap_single(dev, dma_handle, size, DMA_TO_DEVICE);

注意direction参数：

DMA_TO_DEVICE：CPU写，DMA读。映射时会做Cache清理（clean），把脏数据刷回主存。
DMA_FROM_DEVICE：DMA写，CPU读。映射时会做Cache无效化（invalidate），让CPU下次访问时重新从主存加载。
DMA_BIDIRECTIONAL：双向传输。映射时既清理又无效化，性能开销最大。

我曾经踩过的坑：有一次我用了DMA_BIDIRECTIONAL，结果发现性能下降了一半。后来仔细看手册才知道，这个方向会强制刷掉整个Cache行，而不仅仅是相关数据。所以，能用单向就别用双向。

4.6 知识结构图：Cache一致性核心逻辑

下面这张图，是我自己总结的Cache一致性处理决策流程。你写驱动时，照着这个思路走，基本不会错。

4.7 实战对比：什么时候用哪个？

我整理了一个对比表，方便你写代码时快速决策：

场景	推荐API	理由
网卡驱动（RX/TX环形缓冲区）	`dma_alloc_coherent`	每个包都要DMA，频率极高，不能每次刷Cache
块设备驱动（一次读写几KB）	`dma_map_single`	传输不频繁，用一致性内存浪费宝贵的不缓存区域
音频驱动（周期性DMA）	`dma_alloc_coherent`	需要低延迟、无抖动，Cache刷新的不确定性会引入音频卡顿
GPIO模拟SPI（临时DMA）	`dma_map_single`	偶尔用一次，没必要专门分配一致性内存

一个小技巧：如果你不确定用哪个，先看你的DMA缓冲区生命周期。如果缓冲区在驱动初始化时分配、在驱动卸载时释放，用dma_alloc_coherent。如果缓冲区是上层传下来的临时数据（比如来自用户空间的read/write），用dma_map_single。

4.8 总结一下

Cache一致性，说白了就是让CPU和DMA看到同一份数据。Linux内核给了你两把钥匙：dma_alloc_coherent是“锁死”一致性，适合高频场景；dma_map_single是“临时”一致性，适合低频场景。选对了，你的驱动就稳了。

嗯，这一章就到这里。记住：写驱动时，多想想数据是怎么流动的，Cache在中间扮演了什么角色。想通了，bug自然就少了。