Re: [PATCH v9 25/36] media: add V4L2_SUBDEV_FL_MULTIPLEXED

[Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>]

On 12/10/2021 17:55, Hans Verkuil wrote:
> On 05/10/2021 10:57, Tomi Valkeinen wrote:
>> Add subdev flag V4L2_SUBDEV_FL_MULTIPLEXED. It is used to indicate that
>> the subdev supports the new API with multiplexed streams (routing,
>> stream configs).
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
>> ---
>>   include/media/v4l2-subdev.h | 11 +++++++++++
>>   1 file changed, 11 insertions(+)
>>
>> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
>> index b3a72c98a2d3..7f9c83fac020 100644
>> --- a/include/media/v4l2-subdev.h
>> +++ b/include/media/v4l2-subdev.h
>> @@ -888,6 +888,17 @@ struct v4l2_subdev_internal_ops {
>>    * should set this flag.
>>    */
>>   #define V4L2_SUBDEV_FL_HAS_EVENTS		(1U << 3)
>> +/*
>> + * Set this flag if this subdev supports multiplexed streams. This means
>> + * that the driver supports routing and handles the stream parameter in its
>> + * v4l2_subdev_pad_ops handlers. More specifically, this means:
>> + *
>> + * - Centrally managed active state is enabled
>> + * - Legacy pad config is _not_ supported (state->pads)
>> + * - Routing ioctls are available
>> + * - Multiple streams per pad are supported
>> + */
>> +#define V4L2_SUBDEV_FL_MULTIPLEXED		(1U << 4)
> 
> This is an internal kAPI flag. But wouldn't it be useful to have this as
> an entity flag instead? E.g. MEDIA_ENT_FL_MULTIPLEXED
> 
> Or perhaps as a Sub-Device Capabilities Flag V4L2_SUBDEV_CAP_MULTIPLEXED.
> Or a combination. It is useful if you can detect this from userspace without
> having to call G_ROUTING to see if that exists.

This is probably true, but I haven't had a need for it yet so I didn't 
add a flag. Another reason is that I'm not quite happy with the 
V4L2_SUBDEV_FL_MULTIPLEXED. We might want to split it to smaller bits, 
perhaps separating routing and multiplexed streams.

So I'd prefer to wait until we actually have a need to detect this from 
the userspace, and hopefully we then know better how these features 
behave and what we want to expose.

This need might come when adding support to v4l2 tools and libcamera.

  Tomi