外设要持续往内存灌数据、或者要读取大块内存数据时CPU要么疯狂轮询寄存器要么全程参与搬运和拷贝这两条路在高速场景下都是灾难。做驱动的人迟早会碰到DMA——直接内存访问它让外设和内存之间建立一条不经过CPU逐字节搬运的通道而驱动要做的就是把这条通道正确地申请、映射、启动并回收还要在cache一致性、地址空间、并发边界这些地方把坑填平。这篇内容是我多年内核驱动开发中围绕DMA分析和驱动编写的实践总结适合已经在写驱动但被DMA细节卡住的朋友也适合刚接触DMA、想以一份可复现的驱动为线索理解全流程的入门者。下面直接进入正题。1. DMA到底在帮你解决什么问题1.1 没有DMA的时候数据是怎么走的可以想象一个外设不断产生采样数据的场景。没有DMA时最常见的一种实现是外设每完成一次传输就往中断控制器发一个中断驱动程序在中断服务程序里通过总线读取外设的FIFO再写入内存。这个过程中总线访问由CPU发起数据每过一个字节CPU内核就会因为等待外设而停滞。如果外设FIFO很小、数据速率又高中断来得非常频繁CPU大部分时间都会耗在处理中断和搬运数据上留给其他任务的执行时间所剩无几。另一种实现是CPU主动轮询外设状态寄存器这种方式在小批量传输时很常见因为程序简单延迟也可控。但一旦传输规模上来例如以几十MB/s的速率发送数据轮询本身就会把CPU彻底占死。这里的关键不是“CPU在忙”而是“CPU忙的事情没有任何计算价值”——它在充当搬运工。DMA把这件事从CPU身上剥离出来DMA控制器负责按约定的方向、长度和内存地址发起总线读写传输完成的标志通过中断或者状态位告诉驱动。CPU只负责在开头下命令、在结尾收结果中间时间可以做自己的事。1.2 DMA控制器的角色并不是一个简单的搬运器很多人第一次看DMA会觉得它就是“自动拷贝数据”这个理解大方向没错但实际操作时DMA控制器不是单纯地把一段内存搬到另一段内存。在真实系统里DMA控制器至少要做几件事从内存中读取传输描述符传输方向、源地址、目的地址、长度、步长、中断设置根据地址和长度发起总线事务处理总线压力与仲裁以及在传输结束后更新状态或者触发中断。用文件拷贝来类比CPU手动拷贝是“一个员工从A柜子逐件把文件搬到B柜子”DMA就是“你给快递公司下一张运单注明从哪里取、送到哪里、多少件剩下的事快递公司完成完成后打电话通知你”。驱动的工作其实就是填写这张运单然后等电话。这张运单在不同硬件体系里长得不同有些DMA控制器支持二维传输即每传输一段后源地址和目的地址可以分别跳变一定步长这在视频图像处理里非常常见有些则只支持线性传输驱动就需要把不连续的内存拆成多笔描述符。1.3 从CPU视角看DMA的地址不是内存地址这是DMA驱动编写里最容易产生误解的地方必须一开始就扎在心里。CPU眼里有虚拟地址和物理地址驱动代码里访问寄存器、访问内存用的要么是虚拟地址要么是内核已经把物理地址映射好的地址。但DMA控制器是独立于CPU之外的总线主设备它发出的访问请求走的是总线地址空间在启用IOMMU/SMMU的系统里这个总线地址与物理地址可能不是一回事。驱动开发者需要始终分开三种地址CPU虚拟地址、物理地址、总线/DMA地址。申请DMA缓冲区时你要告诉DMA控制器它自己的总线地址告诉CPU这个缓冲区在内核的虚拟地址。绝大多数内核DMA API已经帮你完成了物理地址与总线地址之间的转换但前提是你必须使用标准API而不是自己拿着物理地址就往上填。否则遇到开启IOMMU且DMA地址重映射的系统外设拿到的地址就是一张错地图数据会去向未知区域。2. 驱动动手前必须先想清楚的DMA映射设计2.1 一致性映射与流式映射两条完全不同的路内核DMA子系统把映射分成两大类一致性映射coherent mapping和流式映射streaming mapping。这两类的差异不是API不同这么简单它们的适用场景、开销和注意事项都截然不同。一致性映射常用于外设和驱动需要长期共享一个缓冲区的场景最典型的是DMA描述符环形队列、控制信息块。这类内存由函数dma_alloc_coherent()分配返回值是CPU虚拟地址另一个指针参数输出DMA地址。使用一致性映射的内存驱动和DMA控制器可以随时访问不必担心cache一致性导致的数据不新鲜问题。代价是分配一致性内存的开销相对较高且通常要满足对齐与连续要求不适合高频地按包分配再释放。流式映射则适用于一次性的数据传输比如网络收包、块设备I/O。驱动用dma_map_single()或者dma_map_page()把已有的内核缓冲区映射成DMA可访问的地址传输完成后用dma_unmap_single()解除映射。这种映射会按方向做必要的cache维护开销较小但协议要求严格在DMA控制器正在读这些内存的时候CPU不能随便碰这块缓冲区DMA传输完成后CPU访问之前必须先调用dma_sync_single_for_cpu()做同步。很多驱动bug就是没遵守这两个阶段约束导致数据要么是呆在cache里的旧数据要么是cache和内存互相覆盖。2.2 上手最快的内核DMA API清单实际写驱动时真正高频用到的API并不多把它们和对应场景整理清楚比背一大本手册有用得多。下面是我近些年反复使用的接口场景推荐API说明分配长期共享的DMA缓冲区dma_alloc_coherent()返回CPU虚拟地址输出DMA地址释放一致性缓冲区dma_free_coherent()必须与alloc成对调用流式映射单个数据包dma_map_single()用于已存在的缓冲区须给定方向解除流式映射dma_unmap_single()传输完成或失败后调用刷新流式映射缓存到内存dma_sync_single_for_device()DMA开始前调用让CPU看到最新数据dma_sync_single_for_cpu()DMA完成后、CPU读取前调用分配描述符环dma_alloc_coherent()优先换页开销小不易踩坑获取错误状态dma_mapping_error()map后必须检查有个容易混淆的点dma_sync_single_for_device()和dma_sync_single_for_cpu()看似对称但使用阶段完全不同。for_device是CPU写数据、把数据准备好之后告诉DMA控制器“现在你可以读这些内存了”for_cpu是DMA传输完成后告诉CPU“内存已经被外设更新请刷一下cache再读”。顺序反了数据就错乱。2.3 地址映射里那些必须遵守的硬性要求内核文档在DMA-API.txt里写了不少规则实际项目里让我栽过跟头的集中在这么几条。第一大小和地址对齐。一致性映射内部会按体系结构要求对齐但流式映射的缓冲区没有强制的对齐保障而很多DMA控制器要求起始地址按某种边界对齐长度也要对齐。比如某个外设要求传输长度必须是4字节整数倍否则直接把数据总线上的低两位忽略导致数据错位。驱动最好在最上层就校验读写长度。第二不能把栈内存、静态变量直接传给dma_map_single()。栈内存和普通对象可能位于内核映射的虚拟地址段但未必有连续的物理页而且无法保证总线地址连续。正确做法是给DMA搬运建立专用缓冲区从kmalloc()或者dma_alloc_coherent()得到的缓冲区里分配。第三dma_map_single()之后必须检查dma_mapping_error()。不是每个平台都保证成功启用IOMMU后地址空间可能不足映射会失败。忽略返回值代码可能在架构限定的低内存环境下静默出错数据被DMA写到莫须有的地址上。3. 实操从零写一个带DMA的字符设备驱动3.1 设备树里如何描述DMA能力假设现在有个模拟外设“X”它有一组控制寄存器接收DMA地址、长度、启动命令传输完成后触发一个中断。设备树节点可以这样描述/ { compatible vendor,my-dma-device; reg 0x0 0x1e100000 0x0 0x1000; interrupts 0 57 4; dmas dma0 1; dma-names rx; };reg给出外设寄存器区的物理地址和大小interrupts给出中断号重点是dmas和dma-names。这两个属性把外设和系统DMA控制器关联起来驱动可以通过dma_request_slave_channel()按名字请求对应的DMA通道。有些外设自带DMA控制器不需要外部dmas属性此时驱动直接操作自己的DMA寄存器即可。为聚焦DMA驱动本身的细节下面的示例先不依赖外部DMA控制器而是直接操作外设内部DMA逻辑。3.2 驱动骨架与probe阶段的资源申请驱动以平台驱动方式加载。probe函数要做的事情可以归纳为四步解析设备树资源、映射寄存器、申请中断、分配DMA缓冲区。#include linux/module.h #include linux/platform_device.h #include linux/of.h #include linux/dma-mapping.h #include linux/interrupt.h #include linux/cdev.h #include linux/wait.h #include linux/uaccess.h #define DMA_BUF_SIZE 4096 struct my_dma_dev { void __iomem *regs; struct resource *mem; int irq; struct cdev cdev; dev_t devno; void *buf_cpu; dma_addr_t buf_dma; wait_queue_head_t dma_wait; int dma_done; struct device *dev; }; static int my_dma_probe(struct platform_device *pdev) { struct my_dma_dev *d; struct device *dev pdev-dev; int err; d devm_kzalloc(dev, sizeof(*d), GFP_KERNEL); if (!d) return -ENOMEM; d-dev dev; d-mem platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!d-mem) return -ENXIO; d-regs devm_ioremap(dev, d-mem-start, resource_size(d-mem)); if (!d-regs) return -ENOMEM; d-irq platform_get_irq(pdev, 0); if (d-irq 0) return -ENXIO; d-buf_cpu dma_alloc_coherent(dev, DMA_BUF_SIZE, d-buf_dma, GFP_KERNEL); if (!d-buf_cpu) return -ENOMEM; init_waitqueue_head(d-dma_wait); d-dma_done 0; platform_set_drvdata(pdev, d); err devm_request_irq(dev, d-irq, my_dma_isr, 0, my-dma, d); if (err) return err; /* 注册字符设备... */ return 0; }dma_alloc_coherent()这里分配了4KB缓冲区CPU侧直接用d-buf_cpu读写DMA侧用d-buf_dma告诉外设数据从哪里放。申请中断与分配DMA缓冲的顺序在这个例子中并不关键但建议先分配缓冲区再申请中断避免中断已经使能、传输触发后缓冲区还没就绪的窗口。3.3 触发一次DMA传输并等待完成用户程序通过read接口请求外设的数据。驱动程序在read里需要做几件核心的事把DMA地址和长度写入外设寄存器启动传输等待中断最后把缓冲区数据拷贝到用户空间。static ssize_t my_dma_read(struct file *fp, char __user *user_buf, size_t len, loff_t *off) { struct my_dma_dev *d fp-private_data; size_t xfer_len min(len, DMA_BUF_SIZE); long ret; if (xfer_len 0) return 0; d-dma_done 0; writel(lower_32_bits(d-buf_dma), d-regs 0x00); writel(upper_32_bits(d-buf_dma), d-regs 0x04); writel(xfer_len, d-regs 0x08); writel(1, d-regs 0x0C); /* start */ ret wait_event_interruptible_timeout(d-dma_wait, d-dma_done, HZ); if (ret 0) { dev_err(d-dev, dma timeout\n); return -ETIMEDOUT; } if (ret 0) return ret; if (copy_to_user(user_buf, d-buf_cpu, xfer_len)) return -EFAULT; return xfer_len; }写DMA地址的时候64位平台必须拆成两个32位寄存器写如果外设只支持32位地址则只写低32位同时要保证分配的缓冲区落在外设可寻址的地址范围内。wait_event_interruptible_timeout避免外设故障时read永远睡死。中断服务程序要做的事情相对简单读取外设状态寄存器确认中断源把dma_done置1唤醒等待队列。static irqreturn_t my_dma_isr(int irq, void *data) { struct my_dma_dev *d data; u32 status readl(d-regs 0x10); if (!(status 0x1)) return IRQ_NONE; d-dma_done 1; writel(0x1, d-regs 0x10); /* clear interrupt */ wake_up_interruptible(d-dma_wait); return IRQ_HANDLED; }这里有个细节d-dma_done被中断上下文修改read进程在等待队列上被唤醒后读取它。如果对数据新鲜度要求更高可以使用带spinlock保护或者smp_wmb()确保内存序但单核上这个写法通常够用。严谨起见生产驱动的dma_done建议定义成unsigned int并用READ_ONCE/WRITE_ONCE访问。3.4 设备文件层与用户态验证程序字符设备注册使用标准C接口。为了把示例保持在可读范围内我不会把整个文件都贴出来只说明与DMA相关的部分。file_operations里初始化.read my_dma_readopen时让fp-private_data container_of(inode-i_cdev, struct my_dma_dev, cdev)。用户态验证程序不需要特殊权限背景只要内核模块成功加载、设备节点存在#include fcntl.h #include unistd.h #include stdio.h #include string.h int main(void) { char buf[4096]; int fd open(/dev/my-dma, O_RDONLY); if (fd 0) { perror(open); return 1; } memset(buf, 0, sizeof(buf)); ssize_t n read(fd, buf, sizeof(buf)); if (n 0) { perror(read); return 1; } printf(read %zd bytes: %s\n, n, buf); close(fd); return 0; }这个程序的作用不只是验证数据通路更重要的是它能让DMA传输的全过程可控、可观测。配合dmesg、寄存器dump工具能够逐步确认寄存器配置、中断触发和缓冲区内容三段链路。第一次调试时建议把DMA缓冲区在probe时用固定值初始化这样一旦用户态读到脏数据或者全0能快速判断是外设没写数据还是映射地址错误。4. cache一致性、性能优化与边界条件4.1 cache一致性到底防的是什么CPU访问内存时先查cacheDMA控制器访问内存时直接走总线访问DDR它看不到CPU的cache。于是问题来了如果驱动用CPU写了一份数据数据可能还躺在cache里没有真正落到DDRDMA控制器此时去读DDR读到的是旧数据。反过来DMA控制器把新数据写到DDR后CPU去读对应地址如果cache里还保留着旧副本CPU会读到自己cache里的旧数据新数据被晾在一边。一致性映射的方案是分配这种内存时CPU对它的cache访问策略被设置为不缓存或者使用特别的同步机制让CPU侧访问与DMA控制器访问看到的是同一块物理内存不存在两套副本。流式映射的缓冲区则是一块普通内存传输的前后驱动按阶段调用sync API来手动冲刷/失效cache。这是理解DMA驱动数据正确性的地基。4.2 性能优化避免把DMA变成一只慢速搬运工DMA的优势是解放CPU但不代表只要用了DMA性能就一定好。几个常见的性能瓶颈点我在调试中遇到过不止一两次。首个热点是映射开销。如果驱动在设计上把DMA缓冲区反复 map/unmap而且每包数据量很小、频率很高那么map/unmap过程中cache冲刷带来的开销可能大于数据搬运本身。网络驱动和块设备驱动通常使用预先分配的DMA缓冲池或描述符环而不是每包临时映射。描述符环本身用dma_alloc_coherent()分配环上每一项记录数据缓冲区的DMA地址和长度外设直接从环上取任务驱动通过更新环头尾指针来交互真正做到无锁或少锁。其次是中断合并。传输在数据块不大的情况下可以不必每包都中断CPU。现在很多DMA控制器支持一次描述符链表处理完所有下发任务后只上报一次完成中断。驱动里对应的是内心等待完成事件里硬件中断被聚合网络侧的NAPI就是这种思路。从CPU开销来看一次中断处理通常几百纳秒到几微秒频率上来后CPU占用率会肉眼可见地上升。然后是带宽利用率。大量小传输的每次总线事务都有地址、长度等开销实际有效载荷占比低。如果业务允许驱动应该尽量把相邻的小数据合并成一次较大长度的DMA传输。很多外设的寄存器或者DMA描述符支持突发传输模式burst启用后DMA控制器可以连续占有总线多个周期效率提高明显。但这也意味着其他总线主设备等待时间变长系统级的影响需要考虑。4.3 那些容易写出“偶发bug”的边界条件DMA驱动的bug特别擅长偶发复现现场环境一变就消失非常折磨人。最常踩的边界条件按严重程度排序可以列一个自查清单长度是否为外设要求的整数倍。很多外设要求32位对齐、64位对齐长度不足时DMA控制器行为未定义通常是传输多出几个字节覆盖缓冲区尾部。DMA缓冲区是否越界。外设写数据时如果突发长度超过配置长度会越界写坏相邻内存。这种错误很难追踪因为被写坏的内存区域可能完全与DMA无关。未调用dma_sync_single_for_cpu()就提前读取流式映射缓冲区。如果下次map覆盖了旧数据可能看不出问题但如果同一缓冲区被重复使用就可能出现“上一次读到了上一次传输的影子数据”。在DMA还没结束时驱动就释放或复用了缓冲区。这属于典型的use-after-free变体竞态通常在低负载时看不出来高负载下数据被覆盖。没有处理dma_mapping_error()。IOMMU开启时地址空间碎片化映射有可能失败直接使用错误地址会让外设访问不存在的页表项。我在审查驱动时会重点检查每一处DMA启动与完成事件之间是否交错出现对同一缓冲区的CPU访问所有映射与解映射是否严格成对是否每个map点都检查了错误返回值。这三点全部干净DMA驱动大概率能稳定运行很久。5. 现场排障实录从症状定位到DMA驱动根因5.1 症状一数据中出现随机旧数据某次调试模拟项目X时现象是用户态读取外设音频数据声音偶发夹杂爆音。初步怀疑是数据竞争。配合FTrace跟踪后我注意到每一次爆音都发生在驱动刚完成一次流式映射、还没调用sync函数的窗口期。进一步看代码驱动在接收DMA中断后直接通过memcpy_fromio从寄存器读取数据而不是从sync后的缓冲区读取。我在这里做了两处修正将接收路径改成dma_alloc_coherent的缓冲区流式接收时在中断服务函数里置标志等到工作队列进程上下文调用dma_sync_single_for_cpu()确保CPU读到的数据是DMA最新写入的。这类问题的根因并不玄妙就是违背了流式映射的阶段规则。排查时的技巧是定位数据出现时刻与cache失效时刻之间的时间窗口把窗口扩大复现率就会上升。5.2 症状二DMA传输超时中断丢失另外一个项目里DMA启动后等待队列超时中断始终不来。排查时先看/proc/interrupts里对应中断号是否累计增长如果中断号确实没有触发问题出在硬件或者寄存器配置。随后我用devmem读取状态寄存器发现DMA控制器的状态位停在“等待总线授权”这说明DMA控制器发出的总线请求没有得到仲裁响应。最终定位是设备树里DMA引脚复用配置错误寄存器虽然可以写但物理信号根本没有到达总线。如果/proc/interrupts显示中断号在增长但驱动仍然超时那么问题多半出在软件侧。我会怀疑中断服务程序读状态寄存器的条件不满足提前返回IRQ_NONE或者中断服务程序被注册为共享中断但检查了错误的中断状态位。此时应该在ISR里打印原始状态值而不是依赖推测。5.3 工具与手段把DMA驱动调试从玄学变工程除了初级的printk真正好用的调试手段按效率排序dma_api相关日志内核动态打印接口trace_event可以监控dma_map_page等调用事件配合tracefs提取main path的map/unmap序列。高版本内核还提供了CONFIG_DMA_API_DEBUG开启后会额外校验map/unmap是否配对、是否有缓冲区越界是DMA驱动开发阶段的必备选项。CRASH转储与文档当内存被DMA写坏导致内核崩溃时vmcore里的内存转储能直观看到哪个区域被污染。先用devmem列出设备寄存器当前值然后再分析谁在操作对应的物理页。IOMMU调试节点如果平台支持IOMMU/sys/kernel/iommu/下的分组信息能看到设备DMA页表映射状态。当DMA地址错误时DT组页表里对应的映射条目会缺失或指向错误物理页。实践下来DMA驱动最有效的排障思路是“把每个环节变成可观察的变量”。寄存器看一眼知道发没发中断数看一眼知道来没来buffer数据看一眼知道对没对、新不新鲜。把这三件事做到位绝大多数偶发问题都能收敛到确定原因而不是靠重启碰运气。6. 经验速查表DMA驱动编写的自检清单这是我每次给DMA驱动做code review时都会对照的清单也送给读到这里的你。检查项正确做法错误后果缓冲区分配使用标准DMA API分配非DMA内存被外设踩踏偶发崩溃地址传递传DMA地址给控制器传CPU虚拟地址外设访问错误内存映射方向每个方向都正确设置cache数据不一致读脏数据map/unmap配对严格成对内存泄漏、DMA地址失效后仍被访问sync顺序按device/cpu阶段调用数据要么旧、要么CPU cache覆盖新数据中断确认清除正确的中断状态位中断风暴或传输完成标志丢失长度对齐按外设要求对齐数据错位或长度覆盖超时处理对等待加超时外设故障时进程永久睡眠IOMMU启用场景使用dma_map API而非物理地址重映射地址空间中数据无法到达有些检查项在架构无关的教科书上不会特别强调但在真实项目里恰恰是最大的坑。比如很多板级外设对DMA地址宽度有限制在64位CPU上如果外设只支持32位总线地址而驱动使用默认的dma_alloc_coherent分配的地址恰好高于32位范围DMA会静默丢地址。这种情况一般通过设备树或者DMA mask设置约束dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));在probe函数中越早调用越好。如果平台有IOMMU它仍然可以完成映射只是外围总线地址会落在可寻址范围内如果地址空间本身约束不了就要在驱动里对返回的DMA地址做判断一旦超过上限就重新分配。另一个容易被忽略的点是DMA缓冲区对齐。某些DMA控制器要求起始地址按缓存行对齐dma_alloc_coherent通常能满足但流式映射一个由netdev_alloc_skb分配的socket缓冲时其起始地址未必满足苛刻对齐这时需要在外设侧做容忍或使用align参数重新分配专用缓冲池。这个坑的赔率很高它不导致立即崩溃而是在高负载时随机产生数据偏移非常难定位。作为收尾我个人在实际操作中的体会是写DMA驱动七分靠对数据通路状态的掌控三分靠平台经验。对DMA API的调用时机、地址空间和缓存一致性的把握永远是驱动的正确性基石。而一旦遇到异常现象最快的方法不是翻手册而是把DMA控制器当前配置、中断到达数、缓冲区内容三样东西摆到桌面上原因往往自己就浮现出来了。希望这篇基于实际项目中DMA分析和驱动编写经验的总结能让你少走几个弯路。