[Linaro-mm-sig] [RFC] dma-shared-buf: Add buffer sharing framework

[Sumit Semwal]

Hi Daniel,

On 2 September 2011 21:48, Daniel Vetter <daniel at ffwll.ch> wrote:

> On Fri, Sep 02, 2011 at 05:51:37PM +0200, Arnd Bergmann wrote:
> > On Friday 02 September 2011, Clark, Rob wrote:
> > > > Imho the appeal of this is that there's no preferred party of a
> shared
> > > > buffer (the one the buffer originated from and allocated it), but
> that is
> > > > handled by the dma core (and some platform specific magic for really
> weird
> > > > cases).
> > > >
> > > > We could even go so far and make the dma_buf creation a real syscall
> > > > instead of shoving it into some random ioctls.
> > >
> > > hmm, I don't quite get why making it a syscall would help..
> >
> > It was indeed one of the main drivers for the current design to have no
> > specific way to create a dma buffer but to let every subsystem handle
> > it in its own way. That doesn't prevent you from adding a chardev, file
> > system or syscall that only has the purpose of creating dma buffers,
> > but it should not be essential to have that.
>
> iirc we've converged on that design because it's simpler and requires
> fewer changes in exisiting subsystems. But thinking more about this I'm
> not sure anymore whether this is a good trade-off if we want to handle the
> buffer negotiation problem. Imo that needs a priviledge/central party for
> the buffer creation.
>
> We certainly don't want to implement all that complexity right away, but
> should keep it in mind when designing the userspace api. E.g. the central
> allocator could easily (kernel-internally) fall back on the currently
> discussed scheme by simply allocating the buffer on the first
> attach_device (which whould happen through a subsystem specific ioctl).
>
Ok, so do you think the following as dma_buf_ops would be ok?
 - create,
 - attach_device,
 - rename {get, put}_scatterlist to "buffer_{map, unmap}, adding struct
device*
Obviously, the 'release' callback should then take care of doing all
book-keeping related to 'de-attaching' struct device* as well.

Then we can have a 'central allocator' device which will use this framework
to allow negotiation and sync'ing. Also in absence of this central allocator
device, one of the subsystems can take up the role of allocator in the
earlier-suggested way?

> -Daniel
> --
> Daniel Vetter
> Mail: daniel at ffwll.ch
> Mobile: +41 (0)79 365 57 48
>
> --

Thanks and regards,

Sumit Semwal

Linaro Kernel Engineer - Graphics working group

Linaro.org <http://www.linaro.org/>* **│ *Open source software for ARM SoCs*
***

Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> |
Twitter<http://twitter.com/#!/linaroorg>
 | Blog <http://www.linaro.org/linaro-blog/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linaro.org/pipermail/linaro-mm-sig/attachments/20110908/94cc67be/attachment.html>