Messages in this thread | | | Date | Wed, 14 Jan 2009 14:29:20 -0800 | From | "Vineet Gupta" <> | Subject | Re: Query about DMA map API implementation in non-coherent archs |
| |
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/ >
| |