问题描述
许多关于设备驱动程序编程的指南建议，流DMA映射(即由dma_map_single()和朋友创建的DMA映射)应尽可能短地保持打开状态，因为它们会消耗资源(即，IOMMU映射资源，如果平台具有一个，或在需要时设置跳动缓冲区).
Many guides on device driver programming suggest that streaming DMA mappings (i.e. those created by dma_map_single() and friends), be held open for as short a time as possible, as they consume resources (i.e. IOMMU mapping resources if the platform has one, or a bounce buffer when required).
就我而言，我正在使用能够支持64位DMA的PCIe设备，因此应该不需要反弹缓冲区(在这种情况下，似乎也不需要IOMMU的特殊处理，正确的) ?).数据来自设备(即已与DMA_TO_CPU映射)，并且当有新数据通过中断可用时，设备会通知我，这时我将触发dma_sync_for_cpu()，然后再访问仅通过DMA处理的数据我.
In my case, I'm working with a PCIe device capable of 64-bit DMA, so a bounce buffer should be unnecessary (and it doesn't seem like special treatment from the IOMMU is required in this case either, correct?). The data is coming from the device (i.e. it's mapped with DMA_TO_CPU), and the device notifies me when new data is available via interrupt, at which point I trigger a dma_sync_for_cpu() before accessing the data that was just DMA-ed to me.
还有其他原因使我不应该无限期地打开映射(当然，直到数据使用方关闭)?
Are there other reasons that I ought not to just leave the mapping open indefinitely (until the data consumer shuts down, of course)?
推荐答案
我在Linux内核源代码中发现了至少一个实例，在该实例中，流DMA映射可能会在不确定的时间内保持打开状态:
I've found at least one instance in the Linux kernel source where a streaming DMA mapping may be left open for an indeterminate amount of time:
在用于处理同步DMA(drivers/firewire/core-iso.c)的火线驱动程序代码中，当用户空间调用mmap()时，将建立DMA映射，并且看起来只要用户空间使设备保持打开状态，该映射就会保持打开状态.
In the firewire driver code for handling isochronous DMA (drivers/firewire/core-iso.c), a DMA mapping is established when userspace invokes mmap(), and it appears that this mapping stays open for as long as userspace keeps the device open.
这篇关于Linux内核:是否可以无限期地打开流DMA映射?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！