Re: [PATCH v3 10/15] [media] vb2: add 'ordered' property to queues

[Gustavo Padovan <gustavo.padovan@collabora.com>]

On Mon, 2017-10-02 at 14:43 +0100, Brian Starkey wrote:
> Hi,
> 
> On Thu, Sep 07, 2017 at 03:42:21PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan <gustavo.padovan@collabora.com>
> > 
> > For explicit synchronization (and soon for HAL3/Request API) we
> > need
> > the v4l2-driver to guarantee the ordering in which the buffers were
> > queued
> > by userspace. This is already true for many drivers, but we never
> > needed
> > to say it.
> > 
> > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
> > ---
> > include/media/videobuf2-core.h | 4 ++++
> > 1 file changed, 4 insertions(+)
> > 
> > diff --git a/include/media/videobuf2-core.h
> > b/include/media/videobuf2-core.h
> > index 5ed8d3402474..20099dc22f26 100644
> > --- a/include/media/videobuf2-core.h
> > +++ b/include/media/videobuf2-core.h
> > @@ -508,6 +508,9 @@ struct vb2_buf_ops {
> >  * @last_buffer_dequeued: used in poll() and DQBUF to immediately
> > return if the
> >  *		last decoded buffer was already dequeued. Set for
> > capture queues
> >  *		when a buffer with the V4L2_BUF_FLAG_LAST is
> > dequeued.
> > + * @ordered: if the driver can guarantee that the queue will be
> > ordered or not.
> > + *		The default is not ordered unless the driver
> > sets this flag. It
> > + *		is mandatory for using explicit fences.
> 
> If it's mandatory for fences (why is that?), then I guess this patch
> should come before any of the fence implementation?

As of this implementation it is mandatory for out-fences, so that is
why I didn't put it before the in-fences support.

> 
> But it's not entirely clear to me what this flag means - ordered with
> respect to what? Ordered such that the order in which the buffers are
> queued in the driver are the same order that they will be dequeued by
> userspace?

Exactly.

> I think the order they are queued from userspace can still be
> different from both the order they are queued in the driver (because
> the in-fences can signal in any order), and dequeued again in
> userspace, so "ordered" seems a bit ambiguous.

Exactly. That is what the current implementation does.

> 
> I think it should be more clear.

Sure, sorry for not being clear, the next iteration will have a much
better explanation.

Gustavo