Re: [PATCH v3 10/15] [media] vb2: add 'ordered' property to queues
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
> >
> > 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
> > ---
> > 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
Re: [PATCH v3 10/15] [media] vb2: add 'ordered' property to queues
Hi,
On Thu, Sep 07, 2017 at 03:42:21PM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan
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
---
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 intis_output:1;
unsigned intcopy_timestamp:1;
unsigned intlast_buffer_dequeued:1;
+ unsigned intordered:1;
struct vb2_fileio_data *fileio;
struct vb2_threadio_data*threadio;
--
2.13.5
[PATCH v3 10/15] [media] vb2: add 'ordered' property to queues
From: Gustavo Padovan
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
---
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.
* @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 intis_output:1;
unsigned intcopy_timestamp:1;
unsigned intlast_buffer_dequeued:1;
+ unsigned intordered:1;
struct vb2_fileio_data *fileio;
struct vb2_threadio_data*threadio;
--
2.13.5
