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 -- 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
