expected userspace prime/dma-buf usage

[Rob Clark]

On Fri, Mar 16, 2012 at 8:22 AM, Rob Clark <rob.clark at linaro.org> wrote:
> On Fri, Mar 16, 2012 at 5:53 AM, Dave Airlie <airlied at gmail.com> wrote:
>> Just wondering how we expect userspace to use dma-buf/prime interfaces.
>>
>> Currently I see one driver in sharing the buffer with handle->fd, then
>> passing the fd to the other driver and it using fd->handle, do we then
>> expect the importing driver to close the fd?
>
> Importing driver should:
>
>  dbuf = dma_buf_get(fd);
>  ... store the 'struct dma_buf *' for however long is needed.. this holds
>      a ref to the 'struct file' that backs the dma-buf.. and then when no
>      longer needed:
>  dma_buf_put(dbuf);
>
> think of dma_buf_get()/dma_buf_put() as basically similar to
> fget()/fput().. the fget() would either atomically succeed (if the
> file descriptor was still valid) and increment the ref count, or fail.
>  The fput() would decrement the refcnt.  The last fput() triggers
> ->release() (which then in turn decrements the ref count of the
> original gem buffer object, etc).

oh, and userspace would close the fd when it no longer needs it..  in
case of prime, once you've done fd->handle, how the handle holds a ref
to the imported buffer so you can close the fd.

Other subsystems, it may be different.. if you're repeatedly passing
the fd into the driver each time you use the buffer (ie. no gem handle
or similar) then userspace would need to keep the fd open so they have
it to pass back in to the driver the each time.. v4l2 is working this
way

BR,
-R