From: Hans Verkuil <hverkuil@xs4all.nl>
To: Gustavo Padovan <gustavo@padovan.org>, linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
Shuah Khan <shuahkh@osg.samsung.com>,
linux-kernel@vger.kernel.org,
Gustavo Padovan <gustavo.padovan@collabora.com>
Subject: Re: [PATCH v3 01/15] [media] v4l: Document explicit synchronization behaviour
Date: Mon, 11 Sep 2017 12:50:22 +0200 [thread overview]
Message-ID: <22b8926c-4a44-0f22-0717-c36d64003272@xs4all.nl> (raw)
In-Reply-To: <20170907184226.27482-2-gustavo@padovan.org>
On 09/07/2017 08:42 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan <gustavo.padovan@collabora.com>
>
> Add section to VIDIOC_QBUF about it
>
> v2:
> - mention that fences are files (Hans)
> - rework for the new API
>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
> ---
> Documentation/media/uapi/v4l/vidioc-qbuf.rst | 31 ++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> index 1f3612637200..fae0b1431672 100644
> --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> @@ -117,6 +117,37 @@ immediately with an ``EAGAIN`` error code when no buffer is available.
> The struct :c:type:`v4l2_buffer` structure is specified in
> :ref:`buffer`.
>
> +Explicit Synchronization
> +------------------------
> +
> +Explicit Synchronization allows us to control the synchronization of
> +shared buffers from userspace by passing fences to the kernel and/or
> +receiving them from it. Fences passed to the kernel are named in-fences and
> +the kernel should wait them to signal before using the buffer, i.e., queueing
wait them -> wait on them
(do you wait 'on' a fence or 'for' a fence? I think it's 'on' but I'm not 100% sure)
> +it to the driver. On the other side, the kernel can create out-fences for the
> +buffers it queues to the drivers, out-fences signal when the driver is
Start a new sentence here: ...drivers. Out-fences...
> +finished with buffer, that is the buffer is ready. The fence are represented
s/that is/i.e/
s/The fence/The fences/
> +by file and passed as file descriptor to userspace.
s/by file/as a file/
s/as file/as a file/
> +
> +The in-fences are communicated to the kernel at the ``VIDIOC_QBUF`` ioctl
> +using the ``V4L2_BUF_FLAG_IN_FENCE`` buffer
> +flags and the `fence_fd` field. If an in-fence needs to be passed to the kernel,
> +`fence_fd` should be set to the fence file descriptor number and the
> +``V4L2_BUF_FLAG_IN_FENCE`` should be set as well. Failure to set both will
s/Failure to set both/Setting one but not the other/
> +cause ``VIDIOC_QBUF`` to return with error.
> +
> +To get a out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE`` flag should
> +be set to notify it that the next queued buffer should have a fence attached to
> +it. That means the out-fence may not be associated with the buffer in the
> +current ``VIDIOC_QBUF`` ioctl call because the ordering in which videobuf2 core
> +queues the buffers to the drivers can't be guaranteed. To become aware of the
> +of the next queued buffer and the out-fence attached to it the
> +``V4L2_EVENT_BUF_QUEUED`` event should be used. It will trigger an event
> +for every buffer queued to the V4L2 driver.
This makes no sense.
Setting this flag means IMHO that when *this* buffer is queued up to the driver,
then it should send the BUF_QUEUED event with an out fence.
I.e. it signals that userspace wants to have the out-fence. The requirement w.r.t.
ordering is that the BUF_QUEUED events have to be in order, but that is something
that the driver can ensure in the case it is doing internal re-ordering.
This requirement is something that needs to be documented here, BTW.
Anyway, the flag shouldn't refer to some 'next buffer', since that's very confusing.
> +
> +At streamoff the out-fences will either signal normally if the drivers wait
s/drivers wait/driver waits/
> +for the operations on the buffers to finish or signal with error if the
> +driver cancel the pending operations.
s/cancel/cancels/
Thinking with my evil hat on:
What happens if the application dequeues the buffer (VIDIOC_DQBUF) before
dequeuing the BUF_QUEUED event? Or if the application doesn't call VIDIOC_DQEVENT
at all? Should any pending BUF_QUEUED event with an out fence be removed from the
event queue if the application calls DQBUF on the corresponding buffer?
Regards,
Hans
>
> Return Value
> ============
>
next prev parent reply other threads:[~2017-09-11 10:50 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-07 18:42 [PATCH v3 00/15] V4L2 Explicit Synchronization support Gustavo Padovan
2017-09-07 18:42 ` [PATCH v3 01/15] [media] v4l: Document explicit synchronization behaviour Gustavo Padovan
2017-09-08 2:39 ` Nicolas Dufresne
2017-09-11 10:50 ` Hans Verkuil [this message]
2017-09-11 11:01 ` Hans Verkuil
2017-09-11 13:18 ` Gustavo Padovan
2017-09-11 13:26 ` Hans Verkuil
2017-09-11 13:34 ` Gustavo Padovan
2017-09-11 13:35 ` Hans Verkuil
2017-09-07 18:42 ` [PATCH v3 02/15] [media] vb2: add explicit fence user API Gustavo Padovan
2017-09-11 10:55 ` Hans Verkuil
2017-09-11 11:03 ` Hans Verkuil
2017-10-02 13:42 ` Brian Starkey
2017-10-04 20:12 ` Gustavo Padovan
2017-09-07 18:42 ` [PATCH v3 03/15] [media] vb2: check earlier if stream can be started Gustavo Padovan
2017-09-07 18:42 ` [PATCH v3 04/15] [media] vb2: add in-fence support to QBUF Gustavo Padovan
2017-10-02 13:43 ` Brian Starkey
2017-09-07 18:42 ` [PATCH v3 05/15] [media] uvc: enable subscriptions to other events Gustavo Padovan
2017-09-07 18:42 ` [PATCH v3 06/15] [media] vivid: assign the specific device to the vb2_queue->dev Gustavo Padovan
2017-09-07 18:42 ` [PATCH v3 07/15] [media] v4l: add V4L2_EVENT_BUF_QUEUED event Gustavo Padovan
2017-09-07 18:42 ` [PATCH v3 08/15] [media] vb2: add .buffer_queued() to notify queueing in the driver Gustavo Padovan
2017-09-07 18:42 ` [PATCH v3 09/15] [media] v4l: add support to BUF_QUEUED event Gustavo Padovan
2017-09-07 18:42 ` [PATCH v3 10/15] [media] vb2: add 'ordered' property to queues Gustavo Padovan
2017-10-02 13:43 ` Brian Starkey
2017-10-04 20:18 ` Gustavo Padovan
2017-09-07 18:42 ` [PATCH v3 11/15] [media] vivid: mark vivid queues as ordered Gustavo Padovan
2017-09-07 18:42 ` [PATCH v3 12/15] [media] vb2: add videobuf2 dma-buf fence helpers Gustavo Padovan
2017-09-07 18:42 ` [PATCH v3 13/15] [media] vb2: add infrastructure to support out-fences Gustavo Padovan
2017-09-07 18:42 ` [PATCH v3 14/15] fs/files: export close_fd() symbol Gustavo Padovan
2017-09-07 18:51 ` Eric Biggers
2017-09-07 20:36 ` Al Viro
2017-09-07 21:22 ` Gustavo Padovan
2017-09-07 22:03 ` Al Viro
2017-09-07 22:09 ` Hans Verkuil
2017-09-07 22:18 ` Gustavo Padovan
2017-09-07 18:42 ` [PATCH v3 15/15] [media] vb2: add out-fence support to QBUF Gustavo Padovan
2017-10-02 13:41 ` [PATCH v3 00/15] V4L2 Explicit Synchronization support Brian Starkey
2017-10-04 20:08 ` Gustavo Padovan
2017-10-13 1:56 ` Brian Starkey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=22b8926c-4a44-0f22-0717-c36d64003272@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=gustavo.padovan@collabora.com \
--cc=gustavo@padovan.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@osg.samsung.com \
--cc=shuahkh@osg.samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).