Hi Rob,
On 8 September 2011 19:48, Clark, Rob rob@ti.com wrote:
On Thu, Sep 8, 2011 at 4:57 AM, Sumit Semwal sumit.semwal@linaro.org wrote:
Hi Daniel,
On 2 September 2011 21:48, Daniel Vetter daniel@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*
actually, all I think we needed was to add 'struct device *' to get_scatterlist (and maybe doesn't hurt for put).. I'm not entirely sure why we need create/attach_device? The create fxn especially seems wrong.. what if you are the 2nd device to import the buffer?
Ah... I guess I misunderstood your 'it seems like a sane approach' to mean you agree with the 2-step process suggested by Daniel :) - my bad!
Since I'm a newbie to this domain, I thought both of you saw some scenario I couldn't. Now when I read your email again, I realised you were talking of 'not having to change the dmabuf API', so well, apologies for mis-reading.
All the discussion about deferring allocation of backing pages could still be handled in the first get_scatterlist() call.
I think the interesting questions are:
- what to add to 'struct device_dma_parameters'
- how to handle things like "I need luma over here, chroma over
there".. maybe this could be handled by making luma and chroma two buffers, and having some sub-devices?
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?
central allocator or not, I don't think that the importing device should know or care.. *who* allocates and *who* imports, doesn't really seem relevant to me for dmabuf API..
Ok, you're right of course. The importer need not know at all on who's the allocator, and vice-versa, in context of dmabuf API, and that's what we started with.
BR, -R
-Daniel
Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48
--