On Fri, 2018-05-25 at 12:11 +0530, sathyam panda wrote: > Hello, > > On 5/21/18, Ezequiel Garcia <ezequiel@xxxxxxxxxxxxx> wrote: > > The in-fence implementation involves having a per-buffer fence callback, > > that triggers on the fence signal. The fence callback is called > > asynchronously > > and needs a valid reference to the associated ideobuf2 buffer. > > > > Allow this by making the vb2_buffer refcounted, so it can be passed > > to other contexts. > > > > -Is it really required, because when a queued buffer with an in_fence > is deallocated, firstly queue is cancelled. > -And __vb2_dqbuf is called which calls dma_fence_remove_callback. > -So if fence callback has been called -__vb2_dqbuf will wait to > acquire fence lock. > -So during execution of fence callback, buffers and queue are still valid. > -And if __vb2_dqbuf remove callback first ,then dma_fence_signal will > wait for lock > - so there won't be any fence callback to call for that buffer when > dma_fence_signal resumes. > Hi Sathyam, Thanks for your review! The refcount is definitely required, as the fence callback only schedules a workqueue, which is completely asynchronous with respect to the rest of the ioctls. In particular, the workqueue is not synchronized with vb2_core_queue_release. Also, another subtle detail, dma_fence_remove_callback can fail to remove the callback. Thanks, Eze
