DMA 和 CPU 之间的那点“小矛盾”我是在一次摄像头图像花屏的调试中彻底领教了。当时驱动代码里明明做了 cache 操作但图像数据就是隔三差五出现错位和撕裂查了一整天最后发现问题是设备树里少了一个dma-coherent属性。从那以后我就意识到这个看上去毫不起眼的属性其实是 DMA 驱动开发里最容易踩坑、也最容易被人忽视的环节之一。很多做嵌入式 Linux 的朋友尤其是从裸机开发转过来的一开始都会对 DMA 和缓存一致性这个概念感到头大。裸机时代内存属于谁、由谁访问、要不要做缓存同步全都由你自己说了算但到了 Linux 内核里CPU 有缓存DMA 引擎直接访问内存两边如果不协调好轻则数据错乱重则内核崩溃。而dma-coherent这个设备树属性恰恰就是用来告诉内核“我这套硬件平台DMA 访问内存时是和 CPU 缓存保持一致的不需要软件再去做额外的同步”。这篇文章我就想顺着这个属性把 DMA 一致性的原理、内核里的实现路径、设备树里怎么配、实际调试中怎么用以及我踩过的几个典型大坑一次性聊透。1. 先搞明白 DMA 和 CPU 缓存之间的“各说各话”1.1 为什么 DMA 天然容易和 cache 打架要理解dma-coherent首先得理解 DMA 为什么会和 CPU 缓存产生冲突。CPU 在读写内存的时候不会每次都直接访问 DDR而是会先把数据搬到各级 Cache 里比如 L1、L2有的平台还有 L3。Cache 的意义在于速度快、命中率高绝大多数时候 CPU 在缓存里就能完成读写只有缓存未命中才会真的去触碰 DDR。问题就出在这里DMA 控制器是直接访问物理内存的它不经过 CPU更看不到 CPU Cache。于是就会出现两种非常典型的冲突场景。第一种是 CPU 往某块内存写了一段数据数据其实还躺在 CPU Cache 里没来得及刷回 DDRDMA 引擎这时候去读这块内存读到的是一堆陈旧数据。第二种反过来DMA 往内存里搬进来新的数据但 CPU Cache 里还保留着旧数据CPU 去读的时候命中缓存拿到的还是老数据。我把这种局面比喻成两个人共用一本笔记本第一个人在自己脑子里记了三页纸的摘要说要用的时候直接从脑子里的摘要取第二个人却直接去翻实体笔记本两个人看的根本不是同一份内容。裸机环境下这个问题通常靠程序员手动维护比如访问外设 DMA 缓冲区之前先clean cache之后再做invalidate cache。但 Linux 内核里驱动千千万不可能靠每个驱动开发者都精通缓存操作的时序来保证正确性所以内核必须提供一套规范的 API 和机制让驱动开发者不直接碰 cache也能写出正确的 DMA 驱动。1.2 没有 dma-coherent 的时候驱动要额外做哪些事如果硬件不支持一致性也没有在系统层面给某个设备声明dma-coherent那么驱动在使用 DMA 传输数据时必须按照缓存操作的“套路”来处理。以内核里的 DMA API 为例最典型的是两种情况的处理用dma_map_single()做流式映射时驱动要根据数据传输方向在映射之后、传输开始之前调用dma_sync_single_for_device()把 CPU Cache 里脏数据刷回内存或者让 Cache 里的旧数据失效传输完成后再用dma_sync_single_for_cpu()做反向操作。这些步骤漏掉任何一次数据就有可能是错的。而且这种操作本身就是有性能开销的每次刷 Cache 都要把几百 KB 甚至几 MB 的数据逐行写回在高速外设场景下这种开销非常可观。而使用dma_alloc_coherent()分配一致性内存时内核在底层会保证这块内存不会被 Cache 随意缓存或者通过硬件机制保证 Cache 和内存始终同步驱动拿到这块内存后不需要再做额外的 cache 操作。但前提是内核必须知道当前设备是否具备这种“一致性”能力。dma-coherent属性恰恰就是设备树里用来向上层传递这个关键信息的载体。所以理解dma-coherent不是去背一个设备树属性名而是要明白它在整个 DMA 子系统里扮演的“提示符”角色——它告诉内核你可以放心大胆地为这个设备走一致性映射路径不需要为它做多余的缓存同步动作。内核拿到这个信息以后dma_alloc_coherent()、dma_pool这些接口的行为都会因此发生改变设备的dma_ops也会被设置成对应的实现。2. 设备树里的 dma-coherent声明、语义与内核实现路径2.1 设备树里怎么配一个最小实例设备树是硬件描述语言对驱动来说最重要的还是它最终能转换成内核能识别的资源信息。dma-coherent是一个布尔属性不需要写值只要在设备节点里出现就代表这个设备的 DMA 操作具备缓存一致性能力。一个典型的配置长这样soc { usb_controller: usb31d00000 { compatible vendor,usb-xhci; reg 0x0 0x31d00000 0x0 0x100000; interrupts GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH; dma-coherent; }; };就这么一行没有值没有1之类的参数但却能决定xhci-plat驱动在probe阶段绑定到platform_device时是走一致性映射还是走非一致性映射路径。这个属性对驱动是透明的驱动本身无法直接通过某个device tree API去查询它而是由内核框架在设备初始化阶段读取并写入到struct device内部的标志位里。2.2 内核里怎么解析的从 device_node 到 device设备树解析这块函数调用链看起来很长但关键点并不复杂。当平台设备被创建时内核会调用of_dma_configure()这个函数负责从device_node里读取 DMA 相关的属性包括dma-ranges、dma-coherent以及dma-noncoherent。static int of_dma_configure(struct device *dev, struct device_node *np) { bool coherent; ... coherent of_property_read_bool(np, dma-coherent); ... if (coherent) dev-dma_coherent true; ... }of_property_read_bool()这个接口只要设备节点里存在dma-coherent属性就返回 true不管它有没有值。所以设备树里那种dma-coherent;的空属性和dma-coherent 0;这样的写法真实的解析结果并没有本质区别因为内核关心的只是该属性是否存在。因此平时写设备树的时候遵循规范用空属性就好。设置完dev-dma_coherent之后内核在后续 DMA API 的调用中就会根据这个标志位以及平台相关的dma_ops来决定实际的内存映射和缓存操作策略。比如在 ARM64 平台上arch_setup_dma_ops()会根据是否 coherent 来设置对应的dma_ops一致的设备会走arm_coherent_dma_ops而不一致的设备则会走到arm_dma_ops。这两个dma_ops里的实现在是否调用dma_cache_maint这类的缓存维护操作上有着本质的差别。2.3 dma-coherent 和 dma-noncoherent 到底是什么关系有朋友会问既然有了dma-coherent为什么又冒出个dma-noncoherent其实这两个属性是同一个特性的正反面。在老一些的设备树规范中大家默认设备是不一致的所以只用dma-coherent来“取反”但是后来规范发展了也引入了显式的dma-noncoherent来消除默认值带来的歧义。这两个属性同时在节点里出现时以dma-noncoherent为准因为内核里对这两个属性的解析顺序是固定的非一致性的判断优先级更高if (of_property_read_bool(np, dma-noncoherent)) { dev-dma_coherent false; } else if (of_property_read_bool(np, dma-coherent)) { dev-dma_coherent true; }从设备树维护的角度来说我个人的建议是只要设备确实不具备一致性就显式地写上dma-noncoherent这样后续维护设备树的人一眼就能看清设计意图不用靠猜默认值来推断。凡是涉及 DMA 的设备节点最好都明确声明这两个属性中的一个不要留白因为“留白”意味着你依赖的是内核版本相关的默认行为升级内核后可能会发现驱动行为变了。3. 从分配到底层映射dma-coherent 在驱动里的实际用法3.1 驱动如何申请一致性内存dma_alloc_coherent设备树里声明了dma-coherent驱动层最直接的受益者就是dma_alloc_coherent()。它的原型是void *dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t *dma_handle, gfp_t flag);这个接口会返回两个地址一个虚拟地址void *是 CPU 用来访问内存的一个dma_addr_t *是 DMA 引擎用来发起传输的物理地址在启用 IOMMU 的设备上也可能是经过 IOMMU 映射后的总线地址。驱动在使用这块内存时CPU 侧直接通过虚拟地址读写然后通知 DMA 控制器用dma_handle里的地址去搬数据全程不需要显式做 cache 同步。在内核实现里面dma_alloc_coherent()会根据设备标志位来决定走哪条路径。如果设备是 coherent 的ARM64 平台上会直接调用__dma_direct_alloc_pages()从 CMA 或原子池里分配内存并且配置页表时将这块内存映射为 Normal Non-Cacheable 或是在硬件支持的情况下映射成 Normal Write-Back Cacheable 但带硬件一致性的属性。如果设备不是 coherent 的同样的函数会额外执行缓存维护操作保证分配出来的内存区域在 CPU 侧看起来是“干净”的。实际编码中我建议驱动在申请一致性内存之前先明确设置一次dev-coherent_dma_mask比如dma_set_coherent_mask(dev, DMA_BIT_MASK(32));如果不设置掩码dma_alloc_coherent()在分配时可能会因为 mask 太小而失败或者无法满足外设的寻址能力。我在新平台 bring-up 时见过太多类似“分配失败、返回 NULL”的问题最后查下来都是掩码没设对。3.2 一致性映射和流式映射什么时候用哪个更合理驱动里并非所有 DMA 场景都适合用dma_alloc_coherent()。因为一致性映射通常意味着被分配的内存不能被 Cache 友好地利用要么是关闭了 Cache要么是通过硬件特性保证同步这在某些场景下会损失性能。与其一把梭全用一致性内存不如根据传输模式来选择合适的 API。流式映射dma_map_single()/dma_map_sg()适合数据量大、频率高、传输完成后 CPU 不需要长期保留数据的场景比如网络收发包、USB 数据传输、SD 卡读写。这类场景每次传输前做一次映射传输完成后做一次反映射内核会在底层根据设备是否 coherent来决定是否执行 cache clean/invalidate。做这些操作时设备是 coherent 的情况下底层会直接跳过 cache 操作减少了一次内存同步的额外开销。一致性映射则适合驱动和硬件需要长期共享一块内存、且 CPU 和 DMA 会频繁交替访问同一个区域的场景比如采集设备的帧缓冲、显存、硬件加密引擎的输入输出缓冲区。这类场景里每次传输都做映射和反映射反而得不偿失直接在初始化阶段分配好一块 consistency 内存整个生命周期内只用它反而简洁高效。拿我调试过的一个 VPU 解码驱动举例硬件在解码时需要反复从某个 buffer 读数据、写数据驱动如果在每次解码任务里去做 map/unmap解码一帧的开销会显著增加因为 VPU 访问内存的频次极高。最终方案就是 probe 阶段用dma_alloc_coherent()把解码用的帧缓冲全部提前分配好VPU 跑起来之后不再频繁和 CPU 做缓存同步性能提升非常明显。3.3 典型驱动示例从 probe 到传输为了让你更直观地看到dma-coherent在驱动里的完整效果我用一个精简的虚拟 DMA 驱动示例说明整个流程。先看伪代码static int my_dma_probe(struct platform_device *pdev) { struct device *dev pdev-dev; struct my_dma_dev *dma_dev; dma_addr_t dma_handle; void *cpu_addr; dma_dev devm_kzalloc(dev, sizeof(*dma_dev), GFP_KERNEL); if (!dma_dev) return -ENOMEM; dma_set_coherent_mask(dev, DMA_BIT_MASK(32)); cpu_addr dma_alloc_coherent(dev, MY_BUF_SIZE, dma_handle, GFP_KERNEL); if (!cpu_addr) return -ENOMEM; dma_dev-cpu_addr cpu_addr; dma_dev-dma_addr dma_handle; writel(lower_32_bits(dma_handle), dma_dev-base DMA_SRC_ADDR); writel(MY_BUF_SIZE, dma_dev-base DMA_XFER_SIZE); ... } static void my_dma_start(struct my_dma_dev *dma_dev) { // 当设备声明了 dma-coherent 时从这里到传输结束 // 都不需要调用 dma_sync_single_for_device ... writel(1, dma_dev-base DMA_START); }这段代码如果放在一个非 coherent 的设备上跑即使内核不报错数据的正确性也无法保证因为缺少了dma_sync_single_for_device()。也正因如此驱动开发者必须清楚地知道当前平台硬件是否表里如一地支持 coherent否则代码看起来没问题实际效果却像开盲盒。4. 硬件视角什么样才算真正的 cache coherent4.1 硬件一致性的几种典型实现设备树里的dma-coherent不是随便加的它是对硬件能力的描述。只有硬件确实具备一致性访问能力时这个布尔属性才不是“撒谎”。在我的经验里常见的一致性实现方式有四种。第一种是设备本身访问内存时就带有“缓存感知”的能力典型代表是某些 SoC 内部的总线控制器比如 ARM 的 ACE/CHI 总线协议下外设可以通过缓存一致性总线接口直接和其他核共享缓存。这种情况下DMA 访问内存时总线会主动查询 CPU 缓存如果发现数据在缓存里就直接从缓存拿或推进缓存更新保证两边看到的数据是同一个版本。第二种是设备通过 ACPAccelerator Coherency Port这样的端口接到互连总线上和 CPU 的缓存层级直接进行一致性交互。这种设计常见于一些多媒体加速器上外设访问内存时会通过 ACP 去监听 CPU 的 Cache本质上也是硬件帮你做了原本软件要做的同步。第三种也是最常见的是设备本身不具备一致性能力但系统通过 IOMMU/SMMU 的某种特性比如 DVMDistributed Virtual Memory消息或特定的页表属性把一致性能力“翻译”给外设。这种方式本质上依赖系统级地址转换和控制单元来实现并不是每个平台都支持通常与iommu-map、iommus这些属性配合。第四种最简单粗暴直接把 DMA 缓冲区所在的物理内存映射成 Non-Cacheable或 Device 属性CPU 访问这块内存时完全不经过 CacheDMA 和 CPU 面对的是同一个物理地址的同一份数据天然不会不一致。这种方案最古老也最可靠唯一的代价就是 CPU 读写这块内存的性能会不如 Cacheable 区域。4.2 没有硬件一致性时系统是怎么“伪装”的当硬件不完全提供一致性支持、但驱动又需要“一致”的效果时内核就采用我们前面反复提到的软件方案在适当的时间点做 cache clean / invalidate。这种方案也叫“伪一致性”因为它是通过软件时序配合来模拟硬件契约。在内核代码里这种情况下最核心的函数是dma_cache_maint()它最终会调用平台相关的arch_sync_dma_for_device()/arch_sync_dma_for_cpu()在不同指令集架构上实现方式也不一样。比如在 ARM32 上就是outer_cache和dmac_map_area的组合在 ARM64 上则使用dc civac、dc cvac等缓存操作指令。这种方案最关键的问题在于时序约定驱动必须在 DMA 写内存之前把 CPU Cache 里的脏数据刷下去在 DMA 读内存之前把 CPU Cache 里的旧数据失效。一旦时序出错数据同步就会出现问题。比如一个网络驱动在ndo_start_xmit()里把 SKB 的物理地址交给 DMA 引擎之前就必须保证缓存数据已经刷回内存否则网卡发出去了可能是旧数据。因为这类问题只在特定时序下出现平时不容易复现所以调试难度极大。4.3 与 IOMMU 结合时coherent 配置怎么配合很多现代 SoC 上DMA 传输并不是直接访问物理内存而是要经过 IOMMU/SMMU 做地址转换。这种情况下“一致性”能力还要进一步看 IOMMU 如何处理缓存。如果 SMMU 本身不具备或者没有启用与 CPU Cache 的一致性协议那么即便设备树里写了dma-coherent实际数据在 SMMU 做转换的过程中也可能会遇到缓存不同步的问题。从设备树配置的角度通常要看两个角度一是 IOMMU 节点自身是否支持并配置了 coherent 属性二是终端设备节点是否也要声明 coherent。以 ARM SMMU-v3 为例SMMU 内部有一组和缓存相关的控制位在设备树或 ACPI 表中会有相应的描述。如果 SMMU 可以和 CPU Cache 做一致性交互那么它通常会把这种能力向下传递给经过它做 DMA 的终端设备。换句话说终端设备节点的dma-coherent只有在整条路径互连总线、SMMU、内存控制器都支持一致性时才是真实可靠的。我在实际项目中遇到过一种情况同一个外设 IP在平台 A 上直连总线不经过 SMMU设备树里写dma-coherent没问题换到平台 B 上该外设挂在 SMMU 后面而 SMMU 配置里缺失了 coherent 相关的固件配置结果同样一份设备树跑起来就数据错乱。排查到最后才发现不是外设的驱动变了而是它背后的“一致性通道”变了。所以跨平台复用设备树时dma-coherent这个属性一定要重新审视不能想当然地复制粘贴。5. 常见坑与排查实录5.1 现象一数据偶尔错乱概率性翻车这是最让人头疼的问题没有之一。图像偶发花屏、网络偶发丢包、存储偶发校验失败而且用示波器和总线分析仪很难抓到规律。这类问题我排查过多次最常遇到的原因有三种第一种设备树里漏写了dma-coherent或者驱动里错误地使用了非一致性映射导致每次传输时缓存同步的时序不完全满足要求。比如在中断上下文里访问 CPU 侧的 buffer中断返回后驱动和 DMA 之间的同步路径被打断导致数据不一致。第二种是中断和轮询并发访问同一块 buffer软件上没有做好保护。比如一个 eth0 的驱动发送路径在进程上下文完成中断在硬中断上下文两边如果同时去访问dma_alloc_coherent()分配出来的缓冲区而缓冲区被 CPU 写入了但还没刷 CacheDMA 引擎提前开始搬运就会搬出旧数据。第三种是底层内存类型配置错误导致 DMA 操作访问的物理内存和 CPU 映射的虚拟内存并不指向同一块物理内存。这种情况在开启 IOMMU 后比较常见因为 DMA 的“地址”是经过 SMMU 翻译后的地址如果映射关系配错DMA 引擎搬的根本就是另一块内存。遇到概率性问题我的第一条建议就是先确认设备树属性cat /sys/kernel/debug/dma-api/dump或者直接在驱动里打印dev-dma_coherent确认这个设备在运行时到底被内核判成哪种类型。接着检查驱动里有没有正确使用dma_map_single()/dma_alloc_coherent()如果驱动里用了流式映射却漏掉dma_sync_single_for_device()问题就很可能出在这里。5.2 现象二配置了 dma-coherent 反而性能变差这个现象比较反直觉但也真实存在。dma-coherent的本质是让 DMA 和 CPU 共享缓存一致性但一致性保证是有硬件开销的。比如在一个不支持ACE/CHI总线的平台上强制给设备声明dma-coherent内核虽然不会报错但底层可能会退化成“全 Cache 一致 软件兜底”的模式性能上反而没有“直通非缓存映射”来得好。更典型的情况是dma_alloc_coherent()分配的一致性内存如果底层映射成 Non-CacheableCPU 访问这块内存的每一次读写在底层都会触发外设总线上的完整事务在没有写合并和读组合优化的低端平台上性能会比 Cacheable 的映射差一截。所以我们才会看到有些设备驱动明明知道硬件是 coherent 的也依然选择用dma_pool 流式映射的方式来管理其高频访问的缓冲区就是为了在缓存性能和一致性保证之间找一个平衡点。遇到性能下降时建议先用perf看 CPU 侧的 cache miss 率和内存带宽再对比配置前后的数据。如果发现 DMA 传输本身没变快但 CPU 访问 DMA buffer 的耗时成了瓶颈那就要重新评估这个设备是不是真的适合dma-coherent或者考虑换用流式映射来让 hotspot 数据保留在 Cache 里。5.3 现象三dma_alloc_coherent 分配失败dma_alloc_coherent()返回 NULL 或触发 OOM这类问题不算少见尤其是在内存碎片比较严重、或者 CMA 区域被占满的时候。一致性内存通常来自两个池子一个是一般的 page allocator另一个是 CMA。当设备掩码是 32 位时如果系统内存高于 4GDMA 分配区域会受到限制能从低端内存拿到的页就非常有限分配大块内存时很容易失败。我调试过一个多媒体驱动需要分配 16MB 的帧缓冲结果dma_alloc_coherent()在连续运行了几个小时后失败。排查后发现是 CMA 区域被其他设备的大块分配消耗殆尽而且没有及时回收。解法是在内核启动参数里扩大 CMA 区域比如cma64M并确保设备驱动释放 buffer 时会真的回到 CMA 池而不只是回到 page allocator。另外dma_alloc_coherent()使用的掩码是coherent_dma_mask如果不额外设置继承默认值可能不满足设备需求。我在驱动里常这样设dma_set_mask_and_coherent(dev, DMA_BIT_MASK(30));同时支持dma_set_mask()和dma_set_coherent_mask()确保绝大部分 DMA API 都能和设备的寻址能力匹配。5.4 排查工具和方法让 dma-coherent 问题无所遁形定位 DMA 一致性问题时我常用的方法按优先级排列第一确认设备树属性生效情况。挂上 debugfs 或者直接在驱动里dev_info()把dev-dma_coherent打印出来先确认内核理解的和设备树描述的一致。第二使用 DMA API debug 功能。内核开启CONFIG_DMA_API_DEBUG后可以检测出 DMA API 的不规范调用比如映射后忘记解映射、同步操作的方向错误等。不过这个选项开启后会对性能有影响一般只在调试版本里打开。第三用 tracepoint 观察实际行为。内核提供了dma:前缀的一系列 trace 事件比如dma_map_single、dma_unmap_alloc、dma_alloc_consistent等可以读出映射地址、长度、方向再结合硬件寄存器的值比对能较快定位问题是出在 CPU 侧还是设备侧。第四物理内存 dump 比对。分配一个固定的 buffer让 CPU 先写入 pattern再由 DMA 读回来如果设备和 CPU 读到的数据不一致那就说明一致性链路有问题。可以直接在驱动里做一个自检模块把 0xAA、0x55、随机数等 pattern 反复写入、读回、比对这种自检代码哪怕上线后也可以留着方便后续现场定位问题。5.5 我总结的几条实用经验调试多了之后我对dma-coherent这个属性形成了一套自己的使用守则新板子 bring-up 时先不要急着接管全部 DMA 功能写一个最简单的数据回环测试通过dma_alloc_coherent() 外设自测模式确认一致性链路是否打通。设备树不是“调参”用的而是描述硬件能力的。dma-coherent是否能写要看芯片手册里有没有明确说明设备访问内存时具备一致性能力或者总线是否提供了这种机制。驱动代码里不要只依赖设备树的声明也要在关键路径上做防御性判断比如统一使用 DMA API 而不是直接操作phys_to_virt()之类的底层函数这样即使设备树配置错了也更容易通过 API 内部逻辑发现异常。尽量保持设备和驱动之间的“能力契约”清晰。如果硬件是 non-coherent 的驱动开发时就要在初始化阶段明确调用dma_set_ops()或至少统一走流式映射 API避免在 probe 之后才暴露问题。最后再分享一个小技巧当你在两个硬件平台之间移植同一个外设驱动时不要直接拷贝设备树里的dma-coherent属性而是先把两个平台的芯片手册里关于总线连接、SMMU 配置、缓存一致性支持的章节找出来对照一遍再填属性。我自己就是因为图省事直接吃了平台 B 的大亏从那以后dma-coherent在我心里再也不是一个“可加可不加”的补丁而是必须从硬件原理上确认的一项关键配置。
