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

[Subash Patel]

Hi Sumit,

I have couple of questions related with the buffer object sharing:

a) Process A (decoder related) and Process B (Graphics related) are 
sharing the buffer objects. For some reason Process B gets killed and 
respawns. In this process, it will now again request for fresh set of 
buffers. Now are we going to release previous buffers and do a huge 
buffer negotiations (discussed during Linaro connect) or just pass back 
the existing buffer objects(fd's)? I think it doesnt make sense to stop 
decoding entirely (which is quite time-consuming), and hence pass back 
already allocated buffer objects.

b) Should the user space take care of buffer locking mechanism? Means in 
multi-threaded scenario, if one fd(buffer object) is given for filling 
to the decoder, what if another thread(which may be responsible to pass 
this fd to another process on eg: socket) accesses same fd? Is it good 
to handle that in kernel space instead?

Regards,
Subash

On 08/25/2011 10:52 AM, Sumit Semwal wrote:
> Hi Rob,
>
> On 25 August 2011 06:33, Clark, Rob <rob at ti.com <mailto:rob at ti.com>> wrote:
>
>     On Wed, Aug 10, 2011 at 7:11 AM, Sumit Semwal <sumit.semwal at ti.com
>     <mailto:sumit.semwal at ti.com>> wrote:
>      >
>      > +/**
>      > + * struct dma_buf - shared buffer object
>      > + * @file: file pointer used for sharing buffers across, and for
>     refcounting.
>      > + * @ops: dma_buf_ops associated with this buffer object
>      > + * @priv: user specific private data
>      > + */
>      > +struct dma_buf {
>      > +       struct file *file;
>      > +       struct dma_buf_ops *ops;
>      > +       void *priv;
>      > +};
>      > +
>
>     hmm, I wonder if we should stuff a ptr in there to store the creating
>     driver (or device?) ptr?  This way if it somehow gets passed back to
>     the creating driver, it could realize that it is a dma_buf that it
>     created in the first place.. and that it was safe to cast and deref
>     the priv ptr.
>
> Hmmm... Do you mean the platform driver (device?) ptr? That's a good
> idea - I will make these changes you suggested, and re-post. I'm
> thinking of posting the next version to the upstream mailing lists as well.
>
> Everyone: if you could please spend some time for a review, it'd help me
> post something without obvious, stupid mistakes to the upstream mailing
> lists.
>
> Thanks and best regards,
> ~Sumit.
>
>
>     BR,
>     -R
>
>     _______________________________________________
>     Linaro-mm-sig mailing list
>     Linaro-mm-sig at lists.linaro.org <mailto:Linaro-mm-sig at lists.linaro.org>
>     http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>
>
>
>
> --
>
> 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/>
>
>
>
>
> _______________________________________________
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig