| Message ID | 20170907184226.27482-11-gustavo@padovan.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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? 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? 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. I think it should be more clear. Cheers -Brian > * @fileio: file io emulator internal data, used only if emulator is active > * @threadio: thread io internal data, used only if thread is active > */ >@@ -560,6 +563,7 @@ struct vb2_queue { > unsigned int is_output:1; > unsigned int copy_timestamp:1; > unsigned int last_buffer_dequeued:1; >+ unsigned int ordered:1; > > struct vb2_fileio_data *fileio; > struct vb2_threadio_data *threadio; >-- >2.13.5 >
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
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. * @fileio: file io emulator internal data, used only if emulator is active * @threadio: thread io internal data, used only if thread is active */ @@ -560,6 +563,7 @@ struct vb2_queue { unsigned int is_output:1; unsigned int copy_timestamp:1; unsigned int last_buffer_dequeued:1; + unsigned int ordered:1; struct vb2_fileio_data *fileio; struct vb2_threadio_data *threadio;