On 01/10/18 17:07, Gustavo Padovan wrote:
> From: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxx>
>
> For explicit synchronization it important for userspace to know if the
> format being used by the driver can deliver the buffers back to userspace
> in the same order they were queued with QBUF.
>
> Ordered streams fits nicely in a pipeline with DRM for example, where
> ordered buffer are expected.
>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxx>
> ---
> Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 3 +++
> include/uapi/linux/videodev2.h | 1 +
> 2 files changed, 4 insertions(+)
>
> diff --git a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> index 019c513df217..368115f44fc0 100644
> --- a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> @@ -116,6 +116,9 @@ one until ``EINVAL`` is returned.
> - This format is not native to the device but emulated through
> software (usually libv4l2), where possible try to use a native
> format instead for better performance.
> + * - ``V4L2_FMT_FLAG_UNORDERED``
> + - 0x0004
> + - This is a format that doesn't guarantee timely order of frames.
I'd rephrase this:
"This format doesn't guarantee ordered buffer handling. I.e. the order in
which buffers are dequeued with VIDIOC_DQBUF may be different from the order
in which they were queued with VIDIOC_QBUF."
(Use proper links to VIDIOC_(D)QBUF)
I would also like to see an example of a driver that uses this. The cobalt
driver is a candidate for this.
Regards,
Hans
>
>
> Return Value
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 982718965180..58894cfe9479 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -716,6 +716,7 @@ struct v4l2_fmtdesc {
>
> #define V4L2_FMT_FLAG_COMPRESSED 0x0001
> #define V4L2_FMT_FLAG_EMULATED 0x0002
> +#define V4L2_FMT_FLAG_UNORDERED 0x0004
>
> /* Frame Size and frame rate enumeration */
> /*
>
