Query about DMA map API implementation in non-coherent archs

Query about DMA map API implementation in non-coherent archs

[Vineet Gupta]

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

Re: Query about DMA map API implementation in non-coherent archs

[Stefan Richter]

Vineet Gupta wrote:
...
> 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.
...

dma_map_*() transfers ownership of a buffer from CPUs to the device too.
 In case of DMA_TO_DEVICE or DMA_BIDIRECTIONAL, these calls therefore
have to make sure that the device sees current buffer contents.
-- 
Stefan Richter
-=====-==--= ---= -=-=-
http://arcgraph.de/sr/

Re: Query about DMA map API implementation in non-coherent archs

[Vineet Gupta]

On Sat, Jan 10, 2009 at 1:30 AM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> Vineet Gupta wrote:
> ...
>> 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.
> ...
>
> dma_map_*() transfers ownership of a buffer from CPUs to the device too.
>  In case of DMA_TO_DEVICE or DMA_BIDIRECTIONAL, these calls therefore
> have to make sure that the device sees current buffer contents.

I feel that DMA-api.txt should explicitly say that in part Id, just
before detailing each of the enumerator DMA_TO_DEVICE,
DMA_FROM_DEVICE...

shall I prepare a patch...


> --
> Stefan Richter
> -=====-==--= ---= -=-=-
> http://arcgraph.de/sr/
>