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).
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)?
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:
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With