lkml.org 
[lkml]   [2017]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC v5 06/11] [media] vb2: add explicit fence user API
    From
    Date
    On 17/11/17 14:53, Mauro Carvalho Chehab wrote:
    > Em Fri, 17 Nov 2017 14:29:23 +0100
    > Hans Verkuil <hverkuil@xs4all.nl> escreveu:
    >
    >> On 15/11/17 18:10, Gustavo Padovan wrote:
    >>> From: Gustavo Padovan <gustavo.padovan@collabora.com>
    >>>
    >>> Turn the reserved2 field into fence_fd that we will use to send
    >>> an in-fence to the kernel and return an out-fence from the kernel to
    >>> userspace.
    >>>
    >>> Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
    >>> when sending a fence to the kernel to be waited on, and
    >>> V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.
    >>>
    >>> v4:
    >>> - make it a union with reserved2 and fence_fd (Hans Verkuil)
    >>>
    >>> v3:
    >>> - make the out_fence refer to the current buffer (Hans Verkuil)
    >>>
    >>> v2: add documentation
    >>>
    >>> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
    >>> ---
    >>> Documentation/media/uapi/v4l/buffer.rst | 15 +++++++++++++++
    >>> drivers/media/usb/cpia2/cpia2_v4l.c | 2 +-
    >>> drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 ++--
    >>> drivers/media/v4l2-core/videobuf2-v4l2.c | 2 +-
    >>> include/uapi/linux/videodev2.h | 7 ++++++-
    >>> 5 files changed, 25 insertions(+), 5 deletions(-)
    >>>
    >>> diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst
    >>> index ae6ee73f151c..eeefbd2547e7 100644
    >>> --- a/Documentation/media/uapi/v4l/buffer.rst
    >>> +++ b/Documentation/media/uapi/v4l/buffer.rst
    >>> @@ -648,6 +648,21 @@ Buffer Flags
    >>> - Start Of Exposure. The buffer timestamp has been taken when the
    >>> exposure of the frame has begun. This is only valid for the
    >>> ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
    >>> + * .. _`V4L2-BUF-FLAG-IN-FENCE`:
    >>> +
    >>> + - ``V4L2_BUF_FLAG_IN_FENCE``
    >>> + - 0x00200000
    >>> + - Ask V4L2 to wait on fence passed in ``fence_fd`` field. The buffer
    >>> + won't be queued to the driver until the fence signals.
    >>> +
    >>> + * .. _`V4L2-BUF-FLAG-OUT-FENCE`:
    >>> +
    >>> + - ``V4L2_BUF_FLAG_OUT_FENCE``
    >>> + - 0x00400000
    >>> + - Request a fence to be attached to the buffer. The ``fence_fd``
    >>> + field on
    >>> + :ref:`VIDIOC_QBUF` is used as a return argument to send the out-fence
    >>> + fd to userspace.
    >>
    >> How would userspace know if fences are not supported? E.g. any driver that does
    >> not use vb2 will have no support for it.
    >>
    >> While the driver could clear the flag on return, the problem is that it is a bit
    >> late for applications to discover lack of fence support.
    >>
    >> Perhaps we do need a capability flag for this? I wonder what others think.
    >
    > We're almost running out of flags at v4l2 caps (and at struct v4l2_buffer).

    struct v4l2_capability has more than enough room to add a new device_caps2 field.
    So I see no problem there, and it is very useful for applications to know what
    features are supported up front and not when you start to use them.

    Think about it: you're setting up complete fence support in your application, only
    to discover when you queue the first buffer that there is no fence support! That
    doesn't work.

    The reserved[] array wasn't added for nothing to v4l2_capability.

    struct v4l2_buffer is indeed very full. But I posted an RFC on October 26 introducing
    a struct v4l2_ext_buffer, designed from scratch. We can switch to a u64 flags there.

    See here: https://www.mail-archive.com/linux-media@vger.kernel.org/msg121215.html

    I am waiting for fences and the request API to go in before continuing with that
    RFC series, unless we think it is better to only support fences/request API with
    this redesign. Let me know and I can pick up development of that RFC.

    >
    > So, I would prefer to not add more flags on those structs if there is
    > another way.
    >
    > As the fences out of order flags should go to ENUM_FMT (and, currently
    > there's just one flag defined there), I wander if it would make sense
    > to also add CAN_IN_FENCES/CAN_OUT_FENCES flags there, as maybe we
    > would want to disable/enable fences based on the format.

    I don't see a reason for that. There is no relationship between formats
    and fences. Fences apply to buffers, not formats. Whereas the 'ordered'
    value can be specific to a format.

    Regards,

    Hans

    \
     
     \ /
      Last update: 2017-11-17 17:19    [W:4.164 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site