Hi Subash,
On 30 August 2011 11:12, Subash Patel subashrp@gmail.com wrote:
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.
Buffer sharing mechanism, is not the same as allocator mechanism - obviously. The allocator kernel driver would need to decide this I guess; and the 'get_scatterlist()' / 'put_scatterlist()' callback APIs allow such control to the allocator. The decision can either happen within the allocator driver, or be taken by the associated user-space framework - buffer sharing framework should not pose any restrictions on this I feel. This decision should lie outside of the sharing framework.
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?
Buffer-locking, and syncing should be the responsibility of the allocating / exporting driver - again, get_scatterlist() / put_scatterlist() will allow to somewhat 'control' access [read Rob's suggestion in one of his previous replies about this].
Regards, Subash
Best regards,
~Sumit.
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 Linaro-mm-sig@lists.linaro.org>
http://lists.linaro.org/**mailman/listinfo/linaro-mm-sighttp://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/Linarohttp://www.facebook.com/pages/Linaro> | Twitter <http://twitter.com/#%21/**linaroorghttp://twitter.com/#!/linaroorg> | Blog <http://www.linaro.org/linaro-**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-sighttp://lists.linaro.org/mailman/listinfo/linaro-mm-sig