Message-ID: <20260111173131.GD1275677@ragnatech.se>
Date: Sun, 11 Jan 2026 18:31:31 +0100
From: Niklas Söderlund <niklas.soderlund@...natech.se>
To: Tomi Valkeinen <tomi.valkeinen+renesas@...asonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>,
	Sakari Ailus <sakari.ailus@...ux.intel.com>,
	linux-media@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Jacopo Mondi <jacopo.mondi@...asonboard.com>,
	Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>
Subject: Re: [PATCH v4 00/15] media: rcar: Streams support

Hello Tomi,

Thanks again for your diligent work on this series!

On 2026-01-08 15:57:10 +0200, Tomi Valkeinen wrote:
> Hi Niklas,
> 
> On 31/12/2025 11:57, Niklas Söderlund wrote:
> > Hi Tomi,
> > 
> > Thanks for your persistent work on this series!
> > 
> > On 2025-12-16 17:18:17 +0200, Tomi Valkeinen wrote:
> >> Add streams support to Renesas rcar platform driver.
> >>
> >> The series keaps compatibility with the current upstream for a single
> >> stream use case. However, in upstream there's a limited custom
> >> multi-stream support implemented to the rcar driver, which will be
> >> replaced with the upstream's Streams API.
> >>
> >> I have tested this series on Sparrow-Hawk board, with a few different
> >> setups:
> >>
> >> IMX219 connected to the CSI0 connector
> >> - The following patches applied to my test branch in addition to this
> >>   series:
> >>   1) The v4l2_subdev_get_frame_desc_passthrough dependency
> >>   2) Revert of commit e7376745ad5c8548e31d9ea58adfb5a847e017a4 ("media:
> >>      rcar-vin: Fix stride setting for RAW8 formats"), as that commit
> >>      breaks RAW8
> > 
> > That is so odd, I do grab RAW8 on V4H with a IMX219. In what way is do 
> > you see RAW8 breaking?
> 
> I also used V4H with IMX219. Let's compare our setups and results on irc
> and find out what's going on.

Sounds good.

> 
> >> - Tested with a single video stream
> >>
> >> IMX219 connected to the CSI0 connector
> >> - Plenty of other patches applied to enable full streams support and
> >>   embedded data support in imx219 and v4l2 framework
> >> - Tested with video and embedded data streams
> >>  
> >> Arducam FPD-Link board + 4 x IMX219 connected to the CSI0 connector
> >> - Plenty of other patches applied to enable full streams support and
> >>   embedded data support in imx219 and v4l2 framework, and TPG support in
> >>   ub953
> >> - Tested with video and embedded data streams from all four cameras (so
> >>   8 streams in total)
> >> - Also tested with ub953's TPG, combined with video & embedded streams
> >>   from other cameras.
> > 
> > As there are dependencies on patches that have been on the list for a 
> > long time that would block merging this work. Could we try and shift 
> > focus and get some of the nice fixups and cleanups merged first? IMHO we 
> > could even aim for merging the rework (reduction) of the ad-hoc VC 
> > support done in the graph ASAP to get it out of the way.
> > 
> > It would also be nice if we could sort the RAW8 issue separately to get 
> > it out of the way.
> 
> Sounds fine to me.
> 
> > I have other work touching these drivers I'm holding of on to not cause 
> > conflicts with your nice work, and it will make my work smaller/easier 
> > too!
> > 
> > Could we start by breaking this out into:
> > 
> > - A series that just removes the ad-hoc VC thru media graph in the R-Car 
> >   VIN and CSI-2 drivers.
> 
> That's just the patch 6, "media: rcar-vin: Link VINs on Gen3 to a single
> channel on each CSI-2" patch, isn't it?

If it do not depend on anything in 1-5, yes.

> 
> > - And then we can follow up with the cleanup of each of the drivers as 
> >   separate series.
> 
> How about merging 1-6 as a first step (assuming they pass reviews and
> tests =)? I'm not sure if there's any benefit in sending the above VIN
> patch alone, then the cleanups after that. Or perhaps patches 1-8.

See below,

> 
> > This would make it easier for everybody I think. Each series becomes 
> > smaller to review, we can get fixes and cleanup in now and not wait for 
> > all stream dependences to land first.
> 
> I'm fine with breaking it to smaller pieces than 1-8 if you want. I
> think the split could then be 1-5, 6-8, and the rest later. But I think
> 1-5 are quite small and straightforward, so I'm hoping we can work with
> smaller amount of patch sets.

I think we can go for 1-8, but I would split it into 3 series. One for 
rcar-isp, one for rcar-csi2 and one for rcar-vin. That way we can move 
forward more quickly IMHO as review and test of each in isolation will 
go quicker.

Does this sound OK to you?

> 
> >> I have observed one issue with the embedded data (i.e. requiring bunch
> >> of patches not in upstream): when stopping streaming, VIN says that it
> >> cannot stop the stream. I haven't debugged that, but a possible issue is
> >> that the if the video stream for the imx219 is stopped first, the
> >> embedded data stops also, and VIN does not get the frame-end it is
> >> waiting for.
> > 
> > I would not be comfortable merging with this regression. I have bad 
> > experiences when VIN report it can't stop the stream. More often then 
> > not it also means it then can't start streaming again...
> 
> It's not a regression, and on the "why it doesn't matter" side is that
> embedded data is not supported upstream, so the user cannot hit this
> issue. Also, I did not notice any issues in restarting the streaming again.

OK if you need more patches and the 'can't stop streaming' have only 
been observed for that it's OK. But I really don't want to merge 
anything that increases the likelyhood of this state to happen when 
stopping.

If it only happens with embedded data we should refuse to start 
streaming if embedded data is enabled and we still have not sorted this 
out.

> 
> That said, I agree that it must be sorted out.
> 
>  Tomi
> 

-- 
Kind Regards,
Niklas Söderlund

Powered by blists - more mailing lists