Re: [PATCH v2 00/14] Metadata series preparation

[Jacopo Mondi <jacopo.mondi@ideasonboard.com>]

Hi Sakari

On Fri, Feb 13, 2026 at 07:16:44PM +0200, Sakari Ailus wrote:
> Hi Jacopo,
>
> Thank you for reviewing this!
>
> On Fri, Feb 13, 2026 at 03:36:43PM +0100, Jacopo Mondi wrote:
> > Hi Sakari
> >
> > On Wed, Feb 11, 2026 at 11:09:06AM +0200, Sakari Ailus wrote:
> > > Hi folks,
> > >
> > > This smallish set contains patches that prepare for merging the metadata
> > > series.
> > >
> > > There are simple cleanups but also two noteworthy changes: the addition of
> > > the VALIDATE_LATE media link flag and the addition of the new struct
> > > v4l2_subdev_client_info struct to the get_fmt, set_fmt, get_selection and
> > > set_selection pad operation arguments.
> > >
> > > The VALIDATE_LATE allows using the link_validate callback as the way to
> > > validate the links connected to the sink pads of video nodes on pipelines
> > > with multiple capture video nodes. Without this flag, the entire pipeline
> > > will be validated at the time of the first streamon, with the V4L2 pixel
> > > (or other) format set on the other capture video nodes at the time,
> > > requiring all formats to be set before starting streaming anywhere. But
> > > this does generally not match with what the userspace would do, hence the
> >
> > What would userspace do instead ?
> >
> > Is there a use case for formats not being known at pipeline start time ?
>
> Yes. Try capturing from two video nodes with e.g. yavta.
>

maybe yavta is not the right tool to handle streaming on a complex
platform, or should at least be modified to delay start stream after
all formats are set up.

Anyway..

> I recall the vsp driver does link validation as part of the streamon
> operation without involving the link_validate callback for this reason.
>
> >
> > Is the userspace expected to enable all links with the VALIDATE_LATE
> > flags ?
>
> It's not supposed to be a user-settable flag. The purpose is really to
> allow the framework to do the job it's supposed to.
>

This doesn't explain me nothing.

The only documentation patch for this in
[PATCH v2 07/14] media: mc: Add MEDIA_LNK_FL_VALIDATE_LATE

just reports:

+The ``VALIDATE_LATE`` flag is used to signal that the validation of the link may
+be delayed until actual hardware operation even if the rest of the pipeline
+would be validated at an earlier point of time.

in Documentation/userspace-api/media/mediactl/media-ioc-setup-link.rst

Have I missed any other part of the documentation maybe ?

How are drivers supposed to use it ? Create links to multiplexed
subdevs with this flag ?

Again, if the problem is a userspace tool not setting up all formats
before calling s_stream, a driver flag to accommodate it doesn't seem
right.

> >
> >         for_each_video_node() {
> >                 set_format()
> >                 clear_validate_late();
> >                 vidioc_streamon()
> >         }
> >
> > As I understand it, the use case is solely delay setting the format on
> > the video device and its sink pads ?
>
> Correct.
>

Still not sure why we should allow that.

I'll ask-again:

 Is there a use case for formats not being known at pipeline start time ?

> >
> > > new flag. The patches in the upcoming metadata series version adds the
> > > support for the flag to the IPU6 driver.
> > >
> > > Secondly, the new struct v4l2_subdev_client_info enables passing around
> > > file handler specific client capability information, which is used to
> > > differentiate UAPI between existing users and those that are aware of the
> > > new common raw sensor model. This is effectively required if we want to
> > > add support for the new model to existing raw sensor drivers: the new
> > > model is in a direct conflict with how things worked before the model.
> >
> > Can you elaborate a little on why a per-ioctl flag is required ?
> > Doesn't this open the door to possible mixups ?
> >
> > I fail to see what the advantage is over per-subdev_fh client
> > capabilities.
>
> It's a per-file handle flag, but the sub-device IOCTL handlers currently
> don't take the file handle (or information related to it) as an argument.

Could you elaborate on the reason why the flag should be an operation
argument an not a per-file handle setting ?

> Therefore this needs to be added to the relevant ops -- it could also be
> all pad ops; it would be possible to avoid adding new functions that take
> client_info pointer and work on the active state (see the third-last
> patch).
>
> >
> > > There still needs to be a single driver internal state, the different
> > > UAPIs simply offer a different view to that state. In-kernel users that do
> > > not deal with capabilities just use NULL when calling these ops. This also
> > > means that whatever client capabilities are being used, there may not be a
> > > change to inter-driver interfaces such as get_fmt() when dealing with
> > > external pads.
> >
> > Do we expect drivers that still use in-kernel operation calls to be
> > ported to use streams ?
>
> Those that benefit from it can be ported. But interoperability is good
> between those that use streams than those that don't so there's no hurry.
>
> >
> > I'll review the rest of the series in the meantime.
>
> Thank you. I'm down to ~ 80 patches once these are merged.
>

I really hoped we could have landed the 66 patch series to start
building on it

> --
> Kind regards,
>
> Sakari Ailus