[Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
Dave Airlie
airlied at gmail.com
Wed Oct 12 05:41:57 PDT 2011
On Tue, Oct 11, 2011 at 10:23 AM, Sumit Semwal <sumit.semwal at ti.com> wrote:
> This is the first step in defining a dma buffer sharing mechanism.
>
> A new buffer object dma_buf 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 get_scatterlist and
> put_scatterlist operations.
>
> Atleast one 'attach()' call is required to be made prior to calling the
> get_scatterlist() operation.
>
> Couple of building blocks in get_scatterlist() are added to ease introduction
> of sync'ing across exporter and users, and late allocation by the exporter.
>
> mmap() file operation is provided for the associated 'fd', as wrapper over the
> optional allocator defined mmap(), to be used by devices that might need one.
Why is this needed? it really doesn't make sense to be mmaping objects
independent of some front-end like drm or v4l.
how will you know what contents are in them, how will you synchronise
access. Unless someone has a hard use-case for this I'd say we drop it
until someone does.
Dave.
More information about the dri-devel
mailing list