On Tue, 26 Apr 2011 16:26:19 +0200 Arnd Bergmann arnd@arndb.de wrote:
I don't thing that this argument has anything to do with what the underlying API should be, right? I can see this built on top of either the dma-mapping headers with extensions to map potentially uncached pages, and with the iommu API. Neither way would however save us from implementing the three items listed above.
Or simply extending the DMA mapping API to allow for allocations without mapping. I was just worried you had a more traditional driver model in mind (e.g. coherent alloc on the ring buffer, single mappings for data buffers, all mapped in the kernel driver at allocation time).
The DMA API does have some advantages, in that arches already support it, there's some infrastructure for handling per-bus mapping, etc., so building on top of it is probably a good idea.
It's certainly a good point to note that we should have a way to allocate pages for a device without mapping them into any address space right away. My feeling is still that the dma mapping API is the right place for this, because it is the only part of the kernel that has knowledge about whether a device needs uncached memory for coherent access, under what constraints it can map noncontiguous memory into its own address space, and what its addressing capabilities are (dma mask).
Right. Sometimes a device or platform can handle either cached or uncached though, and we need userspace to decide on the best type for performance reasons.