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>

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