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

Sumit Semwal sumit.semwal at linaro.org
Tue Aug 30 08:08:35 UTC 2011


Hi Subash,

On 30 August 2011 11:12, Subash Patel <subashrp at 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 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 <Linaro-mm-sig at lists.linaro.org>>
>>
>>    http://lists.linaro.org/**mailman/listinfo/linaro-mm-sig<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<http://www.facebook.com/pages/Linaro>>
>> |
>> Twitter <http://twitter.com/#!/**linaroorg<http://twitter.com/#!/linaroorg>>
>> | Blog
>> <http://www.linaro.org/linaro-**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<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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linaro.org/pipermail/linaro-mm-sig/attachments/20110830/a8230d54/attachment.html>


More information about the Linaro-mm-sig mailing list