Re: [PATCH v9 11/15] vb2: add in-fence support to QBUF

From: Brian Starkey
Date: Wed May 09 2018 - 06:35:16 EST


On Tue, May 08, 2018 at 08:18:06PM -0300, Gustavo Padovan wrote:

Hi Hans,

On Mon, 2018-05-07 at 14:07 +0200, Hans Verkuil wrote:
On 04/05/18 22:06, Ezequiel Garcia wrote:
> From: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxx>


> diff --git a/include/media/videobuf2-core.h
> b/include/media/videobuf2-core.h
> index 364e4cb41b10..28ce8f66882e 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -17,6 +17,7 @@
> #include <linux/poll.h>
> #include <linux/dma-buf.h>
> #include <linux/bitops.h>
> +#include <linux/dma-fence.h>
> #define VB2_MAX_FRAME (32)
> #define VB2_MAX_PLANES (8)
> @@ -255,12 +256,21 @@ struct vb2_buffer {
> * done_entry: entry on the list that
> stores all buffers ready
> * to be dequeued to userspace
> * vb2_plane: per-plane information; do not
> change
> + * in_fence: fence received from vb2 client
> to wait on before
> + * using the buffer (queueing to
> the driver)
> + * fence_cb: fence callback information
> + * fence_cb_lock: protect callback signal/remove
> */
> enum vb2_buffer_state state;
> struct vb2_plane planes[VB2_MAX_PLANES];
> struct list_head queued_entry;
> struct list_head done_entry;
> +
> + struct dma_fence *in_fence;
> + struct dma_fence_cb fence_cb;
> + spinlock_t fence_cb_lock;
> +

So for the _MPLANE formats this is one fence for all planes. Which
makes sense, but how
does drm handle that? Also one fence for all planes?

Yes, this is one fence for all planes.

The DRM concept for planes is a totally different concept and is
basically a representation of an user definable square on the screen,
and to that plane there in one framebuffer attached - display hw has no
such a multiplanar for the same image AFAICT. So you probably need some
blit to convert the v4l2 multiplanar to a DRM framebuffer.

Lots of display hardware can do multi-planar formats, and there's
space in struct drm_framebuffer for up to 4 buffer handles (e.g. 3
handles are passed for Luma, Cr, and Cb when the framebuffer format is

The V4L2 code here matches with the DRM "explicit sync"
(IN_FENCE_FD/OUT_FENCE_PTR) stuff, which is probably what we want.
The main difference is that in DRM, explicit fences aren't associated
with framebuffers, they're associated with the things using the
framebuffers - but practically it doesn't make a difference.

There can be per-buffer "implicit sync" via dma-buf reservation
objects, but I don't think this series should attempt to deal with


I think there should be a comment about this somewhere.

Yes, we've been over this exact discussion a few times :)
Having entirely different things with the same name is quite confusing.



Gustavo Padovan
Principal Software Engineer
Collabora Ltd.