Thread (8 messages) 8 messages, 4 authors, 2011-12-26

[Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism

From: airlied@gmail.com (Dave Airlie)
Date: 2011-12-20 20:20:36
Also in: dri-devel, linux-media, linux-mm, lkml

quoted
This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the
changelog below.

Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the
need to have a common mechanism to share memory buffers across different
devices - ARM, video hardware, GPU.

This need comes forth from a variety of use cases including cameras, image
processing, video recorders, sound processing, DMA engines, GPU and display
buffers, and others.

This RFC is an attempt to define such a buffer sharing mechanism- it is the
result of discussions from a couple of memory-management mini-summits held by
Linaro to understand and address common needs around memory management. [1]

A new dma_buf buffer object is added, with operations and API to allow easy
sharing of this buffer object across devices.

The framework allows:
- a new buffer-object to be created with fixed size.
- different devices to 'attach' themselves to this buffer, to facilitate
? backing storage negotiation, using dma_buf_attach() API.
- association of a file pointer with each user-buffer and associated
? ?allocator-defined operations on that buffer. This operation is called the
? ?'export' operation.
- this exported buffer-object to be shared with the other entity by asking for
? ?its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
? ?the associated exporter-defined operations.
- the exporter and user to share the scatterlist using map_dma_buf and
? ?unmap_dma_buf operations.

Documentation present in the patch-set gives more details.

This is based on design suggestions from many people at the mini-summits,
most notably from Arnd Bergmann [off-list ref], Rob Clark [off-list ref] and
Daniel Vetter [off-list ref].

The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski [off-list ref], who demonstrated buffer sharing
between two v4l2 devices. [2]

References:
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389

Patchset based on top of 3.2-rc3, the current version can be found at

http://git.linaro.org/gitweb?p=people/sumitsemwal/linux-3.x.git
Branch: dma-buf-upstr-v2

Earlier versions:
v2 at: https://lkml.org/lkml/2011/12/2/53
v1 at: https://lkml.org/lkml/2011/10/11/92

Best regards,
~Sumit Semwal
I think this is a really good v1 version of dma_buf. It contains all the
required bits (with well-specified semantics in the doc patch) to
implement some basic use-cases and start fleshing out the integration with
various subsystem (like drm and v4l). All the things still under
discussion like
- userspace mmap support
- more advanced (and more strictly specified) coherency models
- and shared infrastructure for implementing exporters
are imo much clearer once we have a few example drivers at hand and a
better understanding of some of the insane corner cases we need to be able
to handle.

And I think any risk that the resulting clarifications will break a basic
use-case is really minimal, so I think it'd be great if this could go into
3.3 (maybe as some kind of staging/experimental infrastructure).

Hence for both patches:
Reviewed-by: Daniel Vetter <redacted>
Yeah I'm with Daniel, I like this one, I can definitely build the drm
buffer sharing layer on top of this.

How do we see this getting merged? I'm quite happy to push it to Linus
if we don't have an identified path, though it could go via a Linaro
tree as well.

so feel free to add:
Reviewed-by: Dave Airlie <airlied@redhat.com>

Dave.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help