Async DMA question regarding dma_async_memcpy_buf_to_buf

[Scott Wood]

Bruce_Leonard at selinc.com wrote:
> Hummm, let me try again, I may be tripping up on my ignorance of the 
> kernel.  According to Linux Device Drivers 3, the DMA_TO/FROM_DEVICE 
> macros impact when the dma_map/unmap_single functions copy data and do 
> cache flushes to ensure cache coherency.  DMA_TO_DEVICE tells 
> dma_map_single() to ensure that all data is copied out to memory and cache 
> is flushed before doing the transfer and DMA_FROM_DEVICE tell 
> dma_unmap_single() to ensure all data is in main memory after the 
> transfer.

Right.

> (My understanding is that this is really only important on 
> archs that use bounce buffers which I'm not).

It's also important on architectures where DMA is non-coherent (mpc83xx 
DMA is coherent).

> So, no as far as "the device" (and I do mean the DMA engine) is concerned, 
> the "mapping" of the src and dest pointers make zero difference, the 
> hardware doesn't care since it's just acting on raw addresses.  However, 
> it does (or at least I think it does) matter to the kernel and making sure 
> that the cache doesn't get screwed up.

Right.

> But it sounds like 
> you're saying those macros are unimportant. 

No, they're very important on certain hardware.

> Can dma_async_memcpy_buf_to_buf() _safely_ be used to DMA either direction 
> (CPU <=> peripheral) _without_ cache coherency problems?

Any given memcpy operation involves *both* directions.  Data is copied 
out of host memory into the DMA engine's internal buffer (this is the 
src mapping), and then it its copied back into host memory at a 
different address (this is the dest mapping).

-Scott