Re: [PATCH] media: imx219: Report streams using frame descriptors
From: Sakari Ailus
Date: Thu Jun 11 2026 - 14:49:35 EST
Hi Laurent,
On Thu, Jun 11, 2026 at 04:10:58PM +0300, Laurent Pinchart wrote:
> On Thu, Jun 11, 2026 at 04:06:38PM +0300, Tomi Valkeinen wrote:
> > On 11/06/2026 12:24, Sakari Ailus wrote:
> > > On Thu, Jun 11, 2026 at 12:13:02PM +0300, Tomi Valkeinen wrote:
> > >> From: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
> > >>
> > >> Implement the .get_frame_desc() subdev operation to report information
> > >> about streams to the connected CSI-2 receiver. This is required to let
> > >> the CSI-2 receiver driver know about virtual channels and data types for
> > >> each stream.
> > >>
> > >> Signed-off-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
> > >> Reviewed-by: Jacopo Mondi <jacopo.mondi@xxxxxxxxxxxxxxxx>
> > >> [tomi.valkeinen: picked from "Generic line based metadata support, internal pads" series]
> > >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx>
> > >> ---
> > >> This patch that adds .get_frame_desc() support to imx219 driver has been
> > >> circulating for a few years, and is currently posted in "[PATCH v12
> > >> 00/86] Generic line based metadata support, internal pads" series.
> > >>
> > >> However, as some bridge drivers require modern drivers that support
> > >> .get_frame_desc, specifically ds90ub960.c, let's pick the patch and
> > >> queue it separately from the huge metadata series.
> > >
> > > I've been recently working on
> > > <URL:https://lore.kernel.org/linux-media/20260518164318.3367888-1-sakari.ailus@xxxxxxxxxxxxxxx/>.
> > > In other words, drivers that have a single stream don't need this. We could
> >
> > Thanks, I had missed that. I like the idea of a helper that does the
> > fallback mechanism. But I wonder about the need for dynamic alloc, which
> > complicates the series. In any case, we can drop this series and
> > continue the discussion on your series.
>
> Maybe we can merge the fallback implementation separately from the
> dynamic allocation if the latter requires more work ? I'm also not a fan
> of the dynamic allocation, at least in the way it's implemented in the
> proposed series. I'm wondering if we could build the frame descriptors
> at stream enable time and store it in state structures instead.
I've changed the allocation to take place in the get_frame_desc() callback,
I'll post the next version soonish.
I think in the long run indeed this should be stored in the state. Without
this series we'll have all receiver drivers implement a fallback or
implement get_frame_desc() callback in all sub-device drivers which is
something I'd like to avoid.
--
Kind regards,
Sakari Ailus