On Fri, Mar 16, 2012 at 8:22 AM, Rob Clark rob.clark@linaro.org wrote:

On Fri, Mar 16, 2012 at 5:53 AM, Dave Airlie airlied@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