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

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.

 Tomi

Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
Changes in v4:
- Rebased on v6.18, with minor conflicts resolved
- Improved patch descriptions
- Re-ordered the patches a bit to move changes that could be applied
  without the full streams support to the beginning of the series
- Added "media: rcar-vin: Link VINs on Gen3 to a single channel on each
  CSI-2" which removes possibility of wrong routing config on Gen3
- Added "media: rcar-csi2: Improve FLD_FLD_EN macros" which was part of
  another patch in v3
- Addressed minor comments (constifyings, cosmetics)
- Fixed the missing stream_count checks in disable_streams ops
- Fixed a few instances in csisp and csi2 where
  v4l2_subdev_state_get_format() was called with hardcoded pad/stream,
  instead of using the data from the route
- Dropped unnecessary ISPPROCMODE_DT_REG register clears
- Squashed "media: rcar-csi2: Add more stream support to
  rcsi2_calc_mbps()" into a previous patch
- Dropped wrong use_isp check from csi2's rcsi2_set_routing()
- Link to v3: https://lore.kernel.org/r/20250530-rcar-streams-v3-0-026655df7138@ideasonboard.com

Changes in v3:
- Rebased on top of latest linux-media
- Dropped dependencies which are already in linux-media (only remaining
  dependency is v4l2_subdev_get_frame_desc_passthrough)
- Tested on white-hawk board, using the staging deser TPG
- Also tested in a WIP branch for GMSL2 (two video streams)
- Link to v2: https://lore.kernel.org/r/20250326-rcar-streams-v2-0-d0d7002c641f@ideasonboard.com

Changes in v2:
- Rebased on top of latest upstream, and updated the dependencies to
  match the latest serieses sent.
- Add new patch "media: rcar-csi2: Use the pad version of v4l2_get_link_freq()"
- Drop "media: rcar-csi2: Fix typo" (it was not a typo)
- Update the code in calc_mbps(). The previous method relied on
  V4L2_CID_LINK_FREQ, but that's not available if the link-freq is
  provided via get_mbus_config().
- Dropped dependencies to Niklas' old series which doesn't apply
  cleanly. It's needed for multi-stream, but not for the current
  upstream which only has a single stream use case.
- Link to v1: https://lore.kernel.org/r/20250219-rcar-streams-v1-0-f1b93e370aab@ideasonboard.com

---
Tomi Valkeinen (15):
      media: rcar-isp: Improve ISPPROCMODE_DT_PROC_MODE_VC
      media: rcar-csi2: Improve FLD_FLD_EN macros
      media: rcar-csi2: Move rcsi2_calc_mbps()
      media: rcar-csi2: Simplify rcsi2_calc_mbps()
      media: rcar-csi2: Optimize rcsi2_calc_mbps()
      media: rcar-vin: Link VINs on Gen3 to a single channel on each CSI-2
      media: rcar-isp: Move {enable|disable}_streams() calls
      media: rcar-csi2: Move {enable|disable}_streams() calls
      media: rcar-csi2: Switch to Streams API
      media: rcar-isp: Switch to Streams API
      media: rcar-csi2: Add .get_frame_desc op
      media: rcar-isp: Call get_frame_desc to find out VC & DT
      media: rcar-csi2: Call get_frame_desc to find out VC & DT (Gen3)
      media: rcar-csi2: Add full streams support
      media: rcar-isp: Add full streams support

 drivers/media/platform/renesas/rcar-csi2.c         | 437 +++++++++++++++------
 drivers/media/platform/renesas/rcar-isp/csisp.c    | 232 ++++++++---
 .../media/platform/renesas/rcar-vin/rcar-core.c    |  27 +-
 3 files changed, 509 insertions(+), 187 deletions(-)
---
base-commit: f7b88edb52c8dd01b7e576390d658ae6eef0e134
change-id: 20250219-rcar-streams-1fdea8860e5e
prerequisite-change-id: 20250218-frame-desc-passthrough-66805e413974:v4
prerequisite-patch-id: bce4a915a29a64f88ed1bb600c08df37d2ba20c6
prerequisite-patch-id: 69b75e7dad9ced905cb39a72f18bebbf3e8f998a
prerequisite-patch-id: 58463f6944c76acd6cf203b14a2836cdb0db2461

Best regards,
-- 
Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>

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?

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

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.

- And then we can follow up with the cleanup of each of the drivers as 
  separate series.

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

> 
>  Tomi
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> ---
> Changes in v4:
> - Rebased on v6.18, with minor conflicts resolved
> - Improved patch descriptions
> - Re-ordered the patches a bit to move changes that could be applied
>   without the full streams support to the beginning of the series
> - Added "media: rcar-vin: Link VINs on Gen3 to a single channel on each
>   CSI-2" which removes possibility of wrong routing config on Gen3
> - Added "media: rcar-csi2: Improve FLD_FLD_EN macros" which was part of
>   another patch in v3
> - Addressed minor comments (constifyings, cosmetics)
> - Fixed the missing stream_count checks in disable_streams ops
> - Fixed a few instances in csisp and csi2 where
>   v4l2_subdev_state_get_format() was called with hardcoded pad/stream,
>   instead of using the data from the route
> - Dropped unnecessary ISPPROCMODE_DT_REG register clears
> - Squashed "media: rcar-csi2: Add more stream support to
>   rcsi2_calc_mbps()" into a previous patch
> - Dropped wrong use_isp check from csi2's rcsi2_set_routing()
> - Link to v3: https://lore.kernel.org/r/20250530-rcar-streams-v3-0-026655df7138@ideasonboard.com
> 
> Changes in v3:
> - Rebased on top of latest linux-media
> - Dropped dependencies which are already in linux-media (only remaining
>   dependency is v4l2_subdev_get_frame_desc_passthrough)
> - Tested on white-hawk board, using the staging deser TPG
> - Also tested in a WIP branch for GMSL2 (two video streams)
> - Link to v2: https://lore.kernel.org/r/20250326-rcar-streams-v2-0-d0d7002c641f@ideasonboard.com
> 
> Changes in v2:
> - Rebased on top of latest upstream, and updated the dependencies to
>   match the latest serieses sent.
> - Add new patch "media: rcar-csi2: Use the pad version of v4l2_get_link_freq()"
> - Drop "media: rcar-csi2: Fix typo" (it was not a typo)
> - Update the code in calc_mbps(). The previous method relied on
>   V4L2_CID_LINK_FREQ, but that's not available if the link-freq is
>   provided via get_mbus_config().
> - Dropped dependencies to Niklas' old series which doesn't apply
>   cleanly. It's needed for multi-stream, but not for the current
>   upstream which only has a single stream use case.
> - Link to v1: https://lore.kernel.org/r/20250219-rcar-streams-v1-0-f1b93e370aab@ideasonboard.com
> 
> ---
> Tomi Valkeinen (15):
>       media: rcar-isp: Improve ISPPROCMODE_DT_PROC_MODE_VC
>       media: rcar-csi2: Improve FLD_FLD_EN macros
>       media: rcar-csi2: Move rcsi2_calc_mbps()
>       media: rcar-csi2: Simplify rcsi2_calc_mbps()
>       media: rcar-csi2: Optimize rcsi2_calc_mbps()
>       media: rcar-vin: Link VINs on Gen3 to a single channel on each CSI-2
>       media: rcar-isp: Move {enable|disable}_streams() calls
>       media: rcar-csi2: Move {enable|disable}_streams() calls
>       media: rcar-csi2: Switch to Streams API
>       media: rcar-isp: Switch to Streams API
>       media: rcar-csi2: Add .get_frame_desc op
>       media: rcar-isp: Call get_frame_desc to find out VC & DT
>       media: rcar-csi2: Call get_frame_desc to find out VC & DT (Gen3)
>       media: rcar-csi2: Add full streams support
>       media: rcar-isp: Add full streams support
> 
>  drivers/media/platform/renesas/rcar-csi2.c         | 437 +++++++++++++++------
>  drivers/media/platform/renesas/rcar-isp/csisp.c    | 232 ++++++++---
>  .../media/platform/renesas/rcar-vin/rcar-core.c    |  27 +-
>  3 files changed, 509 insertions(+), 187 deletions(-)
> ---
> base-commit: f7b88edb52c8dd01b7e576390d658ae6eef0e134
> change-id: 20250219-rcar-streams-1fdea8860e5e
> prerequisite-change-id: 20250218-frame-desc-passthrough-66805e413974:v4
> prerequisite-patch-id: bce4a915a29a64f88ed1bb600c08df37d2ba20c6
> prerequisite-patch-id: 69b75e7dad9ced905cb39a72f18bebbf3e8f998a
> prerequisite-patch-id: 58463f6944c76acd6cf203b14a2836cdb0db2461
> 
> Best regards,
> -- 
> Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> 

-- 
Kind Regards,
Niklas Söderlund

Hi,

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 think I found it. It's broken for all formats and resolutions, based
on luck:

VNIS_REG has the lowest 4 bits always 0. From the doc: "These bits
specify the width of the transfer destination memory in 16-pixel
unit."

We do nothing to comply with that.

 Tomi

Hi Tomi,

Thanks for digging in this.

On 2026-01-26 16:01:36 +0200, Tomi Valkeinen wrote:
> Hi,
> 
> 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 think I found it. It's broken for all formats and resolutions, based
> on luck:
> 
> VNIS_REG has the lowest 4 bits always 0. From the doc: "These bits
> specify the width of the transfer destination memory in 16-pixel
> unit."
> 
> We do nothing to comply with that.

Yes we do, but maybe not enough?

In rvin_format_bytesperline() we align for this, we even consider the 
special cases for NV12 and NV16.

The value written to VNIS_REG is vin->format.bytesperline / fmt->bpp, 
and the value writen to vin->format.bytesperline is ALIGN(pix->width, 
align) * fmt->bpp. And for all formats (not NV12 or NV16) is 0x10, so we 
do align it to the 16-pixel unit no?

Maybe their is a corner case I have missed or maybe I'm missing some 
other angle? And I agree adding and removing the fmt->bpp multiplier is 
not the best here. As we have finally moved this driver to media graph 
only there are lots of areas things can be cleaned up and improved as we 
no longer need to consider all that Gen2 special cases. I bet this can 
likely be cleaned up.

> 
>  Tomi
> 

-- 
Kind Regards,
Niklas Söderlund

Hi,

On 26/01/2026 21:39, Niklas Söderlund wrote:
> Hi Tomi,
> 
> Thanks for digging in this.
> 
> On 2026-01-26 16:01:36 +0200, Tomi Valkeinen wrote:
>> Hi,
>>
>> 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 think I found it. It's broken for all formats and resolutions, based
>> on luck:
>>
>> VNIS_REG has the lowest 4 bits always 0. From the doc: "These bits
>> specify the width of the transfer destination memory in 16-pixel
>> unit."
>>
>> We do nothing to comply with that.
> 
> Yes we do, but maybe not enough?
> 
> In rvin_format_bytesperline() we align for this, we even consider the 
> special cases for NV12 and NV16.
> 
> The value written to VNIS_REG is vin->format.bytesperline / fmt->bpp, 
> and the value writen to vin->format.bytesperline is ALIGN(pix->width, 
> align) * fmt->bpp. And for all formats (not NV12 or NV16) is 0x10, so we 
> do align it to the 16-pixel unit no?
> 
> Maybe their is a corner case I have missed or maybe I'm missing some 
> other angle? And I agree adding and removing the fmt->bpp multiplier is 
> not the best here. As we have finally moved this driver to media graph 
> only there are lots of areas things can be cleaned up and improved as we 
> no longer need to consider all that Gen2 special cases. I bet this can 
> likely be cleaned up.
Right, but if we have the stride / 2 code in, we will get strides not
aligned to 16 bytes unless the bytesperline happened to be aligned to 32
bytes.

I sent "[PATCH] media: renesas: vin: Fix RAW8 (again)". I still don't
understand exactly how the RAW8 processing goes in the hardware, but
afaics the stride / 2 is required, I cannot get any proper images
without that. The documentation doesn't really describe it so I'm not
totally content with all this.

Anyway, please test the new patch on your end, perhaps we'll finally
have a conclusion on the RAW8 =).

 Tomi

Hi Tomi,

On 2026-01-27 10:59:21 +0200, Tomi Valkeinen wrote:
> Hi,
> 
> On 26/01/2026 21:39, Niklas Söderlund wrote:
> > Hi Tomi,
> > 
> > Thanks for digging in this.
> > 
> > On 2026-01-26 16:01:36 +0200, Tomi Valkeinen wrote:
> >> Hi,
> >>
> >> 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 think I found it. It's broken for all formats and resolutions, based
> >> on luck:
> >>
> >> VNIS_REG has the lowest 4 bits always 0. From the doc: "These bits
> >> specify the width of the transfer destination memory in 16-pixel
> >> unit."
> >>
> >> We do nothing to comply with that.
> > 
> > Yes we do, but maybe not enough?
> > 
> > In rvin_format_bytesperline() we align for this, we even consider the 
> > special cases for NV12 and NV16.
> > 
> > The value written to VNIS_REG is vin->format.bytesperline / fmt->bpp, 
> > and the value writen to vin->format.bytesperline is ALIGN(pix->width, 
> > align) * fmt->bpp. And for all formats (not NV12 or NV16) is 0x10, so we 
> > do align it to the 16-pixel unit no?
> > 
> > Maybe their is a corner case I have missed or maybe I'm missing some 
> > other angle? And I agree adding and removing the fmt->bpp multiplier is 
> > not the best here. As we have finally moved this driver to media graph 
> > only there are lots of areas things can be cleaned up and improved as we 
> > no longer need to consider all that Gen2 special cases. I bet this can 
> > likely be cleaned up.
> Right, but if we have the stride / 2 code in, we will get strides not
> aligned to 16 bytes unless the bytesperline happened to be aligned to 32
> bytes.
> 
> I sent "[PATCH] media: renesas: vin: Fix RAW8 (again)". I still don't
> understand exactly how the RAW8 processing goes in the hardware, but
> afaics the stride / 2 is required, I cannot get any proper images
> without that. The documentation doesn't really describe it so I'm not
> totally content with all this.
> 
> Anyway, please test the new patch on your end, perhaps we'll finally
> have a conclusion on the RAW8 =).

Reading the comments in that patch and the documentation and I now see 
the other way the docs could be interpreted :-) I agree that if it works 
(I'm sure it does) it also satisfy the documentation. I will give it a 
spin and reply in that patch. It would indeed be super to solve this 
correctly, thanks for your efforts!

> 
>  Tomi
> 

-- 
Kind Regards,
Niklas Söderlund

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

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