On 17/11/17 14:53, Mauro Carvalho Chehab wrote: > Em Fri, 17 Nov 2017 14:29:23 +0100 > Hans Verkuil <hverkuil@xxxxxxxxx> escreveu: > >> On 15/11/17 18:10, Gustavo Padovan wrote: >>> From: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxx> >>> >>> 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@xxxxxxxxxxxxx> >>> --- >>> 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@xxxxxxxxxxxxxxx/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
