Query about DMA map API implementation in non-coherent archs

["Vineet Gupta" <vineetg76@gmail.com>]

Hi,

I work for Linux port of "ARC" CPU a 32 bit RISC processor, with
explicit Cache Maintenance Instructions but non Coherent DMA. We do
have ways to make coherent memory by disabing per PAGE cache bit in
MMU.

I ran into a few road blocks when implementing the Streaming DMA mapping APIs.

As per dma-mapping and dma-api docs, for streaming DMA mappings arch
needs to provide 2 seperate APIs

1. map API to convert cpu address into DMA address
2. sync API to flush/invalidate the dcaches for non-coherent archs
(essentially when changing the ownership of buffer between cpu and
device).

However from what I understood, the map API need not take care of
proper cache sync.However both ARM and MIPS do the cache sync
operations in map API as well (this is done standalone in sync APIs
too). Is there a specific reason for this.

Drivers such as libata don't even call any sync API. For e.g. libata
only calls dma_map_sg ( ) while setting up the DMA.

Does that mean that the semantics of map API ought to have cache
coherency built in or the arch code has this to workaround drivers not
calling proper sync APIs.

Also DMA-MAP.txt "recommends" that the memory passed to map API be
from kmalloc or get_free_pages to make sure it is physically
contiguous. However "recommends" is a bit ambigous. What if someone
passes a vmalloc address which is only one page worth (ignoring the
gaurd page added by kernel). Should the map API return error or should
it walk the page tables to find the physical address.


Thanks,
Vineet