Message-ID: <459d26bc-f847-42cc-91fa-a939b6f205a8@ideasonboard.com>
Date: Thu, 8 Jan 2026 15:57:10 +0200
From: Tomi Valkeinen <tomi.valkeinen+renesas@...asonboard.com>
To: Niklas Söderlund <niklas.soderlund@...natech.se>
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

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.

>> - 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?

> - 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.

> 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 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.

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

 Tomi

Powered by blists - more mailing lists