On Fri, Mar 16, 2012 at 8:22 AM, Rob Clark <rob.clark@xxxxxxxxxx> wrote: > On Fri, Mar 16, 2012 at 5:53 AM, Dave Airlie <airlied@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
