Re: [PATCH v2 1/4] dma-mapping: Add devm_ interface for dma_map_single()
From: Eli Billauer
Date: Wed Jun 04 2014 - 11:04:45 EST
Hi,
I believe that I need a managed dma_map_single() my own driver, which
doesn't fall in the case of a single use: The driver allocates its
buffers with __get_free_pages() (or the to-be managed version of it).
Then it cuts the allocated memory into smaller buffers (in some cases,
and with certain alignment rules), and then calls dma_map_single() to
do the DMA mapping for each. The buffers are held along the driver's
lifetime, with DMA sync API juggling control back and forth to the
hardware. Note that the DMA is noncoherent.
Once could argue, that since dma_map_noncoherent() calls
__get_free_pages() under the hood, I could request the larger chunk from
dma_map_noncoherent(), and cut it into smaller DMA buffers. My concern
is that the dma_sync_single_*() functions expect a DMA handle, not a
physical address I've made up with my own buffer splitting. I don't see
any problem with this trick on platforms I've worked with, but I'm not
sure if this is the proper way to go. dma_map_single(), on the other
hand, returns a DMA handle.
The DMA pool functions could be interesting, but I understand that they
would supply me with coherent memory only.
Anything I missed?
Thanks,
Eli
On 04/06/14 17:14, Tejun Heo wrote:
Hello,
On Wed, Jun 04, 2014 at 04:12:11PM +0200, Joerg Roedel wrote:
Yes, but those drivers usually get DMA buffers at init time with the
dma_alloc_* interfaces. The dma_map_* interfaces discussed here belong
to the streaming DMA-API, so they are usually used for only one DMA
transaction before dma_unmap_* is called on them.
A devm interface for the dma_alloc_* family of functions would
actually make sense, but not for the dma_map_* functions.
Ah, okay. Fair enough.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/