Re: [PATCH v2 1/4] dma-mapping: Add devm_ interface for dma_map_single()

[Eli Billauer <eli.billauer@gmail.com>]

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.
>
>