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. Comments, flames? If this sounds sensible I'll throw together a quick rfc over the next few days. Cheers, Daniel PS: Imo the next step after this would be adding userspace mmap support. This has the funky requirement that the exporter needs to be able to shot down any ptes before it moves around the buffer. I think solving that nice little problem is a good exercise to prepare us for solving similar "get of this buffer, now" issues with permanent device address space mappings ... -- Daniel Vetter Mail: daniel@xxxxxxxx Mobile: +41 (0)79 365 57 48 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
