Hi Daniel,
I have already written about this issue in the dma mapping patch thread. But would like to add it here, to keep all known issues in one place, as Kiko wanted it to be. This probably will help him track the missing pieces from the UMM.
On 03/22/2012 11:31 PM, Daniel Vetter wrote:
On Thu, Mar 22, 2012 at 11:54:55AM -0300, Christian Robottom Reis wrote:
Tomasz: proposed extension to DMA Mapping -- dma_get_pages Currently difficult to change the camera address into list of pages DMA framework has the knowledge of this list and could do this Depends on dma_get_pages Needs to be merged first Test application posted to dri-devel with dependencies to run demo Many dependenciesI kinda missed to yell at this patch when it first showed up, so I'll do that here ;-)
I think this is a gross layering violation and I don't like it at all. The entire point of the dma api is that device drivers only get to see device addresses and can forget about all the remapping/contig-alloc madness. And dma-buf should just follow this with it's map/unmap interfaces.
Furthermore the exporter memory might simply not have any associated struct pages. The two examples I always bring up:
- special purpose remapping units (like omap's TILER) which are managed by the exporter and can do crazy things like tiling or rotation transparently for all devices.
- special carve-out memory which is unknown to linux memory management. drm/i915 is totally abusing this, mostly because windows is lame and doesn't have decent largepage allocation support. This is just plain system memory, but there's no struct page for it (because it's not part of the system map).
Now the core dma api isn't fully up to snuff for everything yet and there are things missing. But it's certainly not dma_get_pages, but more things like mmap support for coherent memory or allocating coherent memroy which doesn't have a static mapping in the kernel address space. I very much hope that the interfaces we develop for dma-buf (and the insights gained) could help as examples here, so that in the further there's not such a gaping difference for the driver between dma_coherent allocations of it's own and imported buffer objects.
I have already faced the coherent memory issue. I would like to mention the scenario in which this was observed.
Origen has a encoder/decoder IP which can declare coherent regions. Now when dma_buf was used to share the buffer between this IP and another IP(for color space conversion), it was observed that the cache operations (aka cpu access to buffers) failed. The reason for this is, coherent memory wont have struct pages entries and also kernel addresses (not remapped into consistent dma area). When the cpu access the pages structure during the map_sg operations, it leads to a fault.
I had discussion with Marek on IRC for this. We need to find a mechanism to solve this issue. Please correct me if I am wrong somewhere in my analysis.
Yours, Daniel
Regards, Subash