From: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
To: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Cc: Jacopo Mondi <jacopo.mondi@ideasonboard.com>,
tomm.merciai@gmail.com, linux-renesas-soc@vger.kernel.org,
biju.das.jz@bp.renesas.com,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
Hans Verkuil <hverkuil@kernel.org>,
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>,
Daniel Scally <dan.scally+renesas@ideasonboard.com>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 1/3] media: rzg2l-cru: Skip ICnMC configuration when ICnSVC is used
Date: Mon, 9 Feb 2026 17:05:01 +0100 [thread overview]
Message-ID: <aYoFBMBBT88qH756@zed> (raw)
In-Reply-To: <aYn_Vf1H1m1z44p2@tom-desktop>
Hi Tommaso
On Mon, Feb 09, 2026 at 04:37:57PM +0100, Tommaso Merciai wrote:
> Hi Jacopo,
> Thanks for your review!
>
> On Mon, Feb 09, 2026 at 03:21:59PM +0100, Jacopo Mondi wrote:
> > Hi Tommaso
> >
> > On Tue, Dec 30, 2025 at 06:09:15PM +0100, Tommaso Merciai wrote:
> > > When the CRU is configured to use ICnSVC for virtual channel mapping,
> > > as on the RZ/{G3E, V2H/P} SoC, the ICnMC register must not be
> > > programmed.
> >
> > I see a difference indeed between the [G3E, V2H/P] and the G2L version
> > of the IP in the presence of the VCSEL[1:0] field in register ICnMC.
> >
> > On [G3E, V2H/P] the selection of which virtual channel to accept
> > doesn't go through VCSEL[1:0] in ICnMC but a dedicated register ICnSVC
> > is provided for that purpose. So far so good.
> >
> > >
> > > Return early after setting up ICnSVC to avoid overriding the ICnMC
> > > register, which is not applicable in this mode.
> > >
> > > This prevents unintended register programming when ICnSVC is enabled.
> > >
> > > Fixes: 3c5ca0a48bb0 ("media: rzg2l-cru: Drop function pointer to configure CSI")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> > > ---
> > > drivers/media/platform/renesas/rzg2l-cru/rzg2l-video.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/media/platform/renesas/rzg2l-cru/rzg2l-video.c b/drivers/media/platform/renesas/rzg2l-cru/rzg2l-video.c
> > > index 162e2ace6931..480e9b5dbcfe 100644
> > > --- a/drivers/media/platform/renesas/rzg2l-cru/rzg2l-video.c
> > > +++ b/drivers/media/platform/renesas/rzg2l-cru/rzg2l-video.c
> > > @@ -268,6 +268,8 @@ static void rzg2l_cru_csi2_setup(struct rzg2l_cru_dev *cru,
> > > rzg2l_cru_write(cru, ICnSVCNUM, csi_vc);
> > > rzg2l_cru_write(cru, ICnSVC, ICnSVC_SVC0(0) | ICnSVC_SVC1(1) |
> > > ICnSVC_SVC2(2) | ICnSVC_SVC3(3));
> > > +
> > > + return;
> > > }
> > >
> > > icnmc |= rzg2l_cru_read(cru, info->image_conv) & ~ICnMC_INF_MASK;
> >
> > However, the rest of the rzg2l_cru_csi2_setup() doesn't only program
> > the virtual channel filtering through ICnMC (which should be skept for
> > G3E, V2H/P) but also programs DT filtering in INF[5:0] of register
> > ICnIPMC_C0 which seems to be available on G3E and V2H/P as well.
> >
> > Section "9.2.4.3.6 VC/Data Type Selector (for Image Processing)" of
> > the chip manual (V2H/P) prescribes:
> >
> > Only one data type can be handled by each SVC and the data types are
> > selected in the ICnIPMC_C0 to 3.INF[5:0] registers.
>
> You are correct, thanks.
> I miss that part.
>
> Maybe we can go for:
>
> static void rzg2l_cru_csi2_setup(struct rzg2l_cru_dev *cru,
> const struct rzg2l_cru_ip_format *ip_fmt,
> u8 csi_vc)
> {
> const struct rzg2l_cru_info *info = cru->info;
> u32 icnmc = ICnMC_INF(ip_fmt->datatype);
>
> if (cru->info->regs[ICnSVC]) {
> rzg2l_cru_write(cru, ICnSVCNUM, csi_vc);
> rzg2l_cru_write(cru, ICnSVC, ICnSVC_SVC0(0) | ICnSVC_SVC1(1) |
> ICnSVC_SVC2(2) | ICnSVC_SVC3(3));
> } else {
> /* Set virtual channel CSI2 */
> icnmc |= ICnMC_VCSEL(csi_vc);
> }
>
> icnmc |= rzg2l_cru_read(cru, info->image_conv) & ~ICnMC_INF_MASK;
> rzg2l_cru_write(cru, info->image_conv, icnmc);
> }
>
> ?
yes, I ended up with something similar locally to be able to move
forward and test more patches from this series.
static void rzg2l_cru_csi2_setup(struct rzg2l_cru_dev *cru,
const struct rzg2l_cru_ip_format *ip_fmt,
u8 csi_vc)
{
const struct rzg2l_cru_info *info = cru->info;
u32 icnmc = rzg2l_cru_read(cru, info->image_conv) & ~(ICnMC_INF_MASK |
ICnMC_VCSEL_MASK);
icnmc |= ICnMC_INF(ip_fmt->datatype);
/*
* VC filtering goes through SVC register on G3E/V2H and through ICnMC
* on G2L.
*/
if (cru->info->regs[ICnSVC]) {
/* FIXME: This only works if 'csi_vc' is 0. */
rzg2l_cru_write(cru, ICnSVCNUM, csi_vc);
rzg2l_cru_write(cru, ICnSVC, ICnSVC_SVC0(0) | ICnSVC_SVC1(1) |
ICnSVC_SVC2(2) | ICnSVC_SVC3(3));
} else {
icnmc |= ICnMC_VCSEL(csi_vc);
}
rzg2l_cru_write(cru, info->image_conv, icnmc);
}
>
> >
> > And this patch makes the driver skips that part.
> > Has this patch been tested ? It breaks my V2H/P setup:
> >
> > rzg2l-cru 16010000.cru1: Invalid MB address 0x0 (out of range)
>
> I've not seeing that on RZ/G3E.
> Thanks for sharing.
Without programming which DT to filter I don't see how this could
work to be honest..
>
>
> Kind Regards,
> Tommaso
>
> >
> >
> > > --
> > > 2.43.0
> > >
> > >
next prev parent reply other threads:[~2026-02-09 16:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-30 17:09 [PATCH 0/3] media: rzg2l-cru: Fixes and improvements Tommaso Merciai
2025-12-30 17:09 ` [PATCH 1/3] media: rzg2l-cru: Skip ICnMC configuration when ICnSVC is used Tommaso Merciai
2026-01-09 22:10 ` Lad, Prabhakar
2026-02-09 14:21 ` Jacopo Mondi
2026-02-09 15:37 ` Tommaso Merciai
2026-02-09 16:05 ` Jacopo Mondi [this message]
2025-12-30 17:09 ` [PATCH 2/3] media: rzg2l-cru: Use only frame end interrupts for DMA stopping state Tommaso Merciai
2026-01-09 22:10 ` Lad, Prabhakar
2026-02-09 15:13 ` Jacopo Mondi
2025-12-30 17:09 ` [PATCH 3/3] media: rzg2l-cru: Drop redundant buffer address clearing Tommaso Merciai
2026-01-09 22:10 ` Lad, Prabhakar
2026-02-09 15:41 ` Jacopo Mondi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aYoFBMBBT88qH756@zed \
--to=jacopo.mondi@ideasonboard.com \
--cc=biju.das.jz@bp.renesas.com \
--cc=dan.scally+renesas@ideasonboard.com \
--cc=hverkuil@kernel.org \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=stable@vger.kernel.org \
--cc=tomm.merciai@gmail.com \
--cc=tommaso.merciai.xr@bp.renesas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.