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@ti.com mailto:rob@ti.com> wrote:
On Wed, Aug 10, 2011 at 7:11 AM, Sumit Semwal <sumit.semwal@ti.com <mailto:sumit.semwal@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@lists.linaro.org <mailto:Linaro-mm-sig@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@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig