[Linaro-mm-sig] [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
laurent.pinchart at ideasonboard.com
Mon Jan 30 14:44:20 UTC 2012
On Tuesday 24 January 2012 14:03:22 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.
Userspace access through mmap can already be handled by the subsystem that
exports the buffer, so I'm fine with postponing implementing this inside dma-
> I'm thinking about adding 3 pairs of function to dma_buf (not to
> 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.
> 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).
> 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?
Before commenting (I don't plan on flaming :-)), I'd like to take a small step
back. Could you describe the use case(s) you think of for kernel mappings ?
> If this sounds sensible I'll throw together a quick rfc over the next few
> 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
More information about the Linaro-mm-sig