On Tue, Jan 24, 2012 at 02:03:22PM +0100, Daniel Vetter wrote:
On Mon, Jan 23, 2012 at 11:54:20AM +0100, Laurent Pinchart wrote:
On Monday 23 January 2012 11:35:01 Daniel Vetter wrote:
See my other mail, dma_buf v1 does not support cpu access.
v1 is in the kernel now, let's start discussing v2 ;-)
Ok, I'm in ;-)
I've thought a bit about this, and I think a reasonable next step would be to enable cpu access from kernelspace. Userspace and mmap support is a hole different beast altogether and I think we should postpone that until we've got the kernel part hashed out.
I'm thinking about adding 3 pairs of function to dma_buf (not to dma_buf_attachment).
dma_buf_get_backing_storage/put_backing_storage This will be used before/after kernel cpu access to ensure that the backing storage is in memory. E.g. gem objects can be swapped out, so they need to be pinned before we can access them. For exporters with static allocations this would be a no-op.
I think a start, length range would make sense, but the exporter is free to just swap in the entire object unconditionally. The range is specified in multiples of PAGE_SIZE - I don't think there's any usescase for a get/put_backing_storage which deals in smaller units.
The get/put functions are allowed to block and grab all kinds of looks. get is allowed to fail with e.g. -ENOMEM.
dma_buf_kmap/kunmap This maps _one_ page into the kernels address space and out of it. This function also flushes/invalidates any caches required. Importers are not allowed to map more than 2 pages at the same time in total (to allow copies). This is because at least for gem objects the backing storage can be in high-mem.
Importers are allowed to sleep while holding such a kernel mapping.
These functions are not allowed to fail (like kmap/kunmap).
dma_buf_kmap_atomic/kunmap_atomic For performance we want to also allow atomic mappigns. Only difference is that importers are not allowed to sleep while holding an atomic mapping.
These functions are again not allowed to fail.
I think we need to extend the kmap/kunmap functions with a few arguments to properly flush caches. I think a simple flag with read, write or read | write should be good enough. -Daniel