Message-ID:
 <TYCPR01MB11332D8F192023ADF4D8490398682A@TYCPR01MB11332.jpnprd01.prod.outlook.com>
Date: Fri, 9 Jan 2026 10:03:01 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Cosmin-Gabriel Tanislav <cosmin-gabriel.tanislav.xa@...esas.com>, John
 Madieu <john.madieu.xa@...renesas.com>, "Rafael J . Wysocki"
	<rafael@...nel.org>, Daniel Lezcano <daniel.lezcano@...aro.org>, Zhang Rui
	<rui.zhang@...el.com>, Lukasz Luba <lukasz.luba@....com>, Rob Herring
	<robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
	<conor+dt@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>, Geert
 Uytterhoeven <geert+renesas@...der.be>, magnus.damm <magnus.damm@...il.com>
CC: "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>
Subject: RE: [PATCH v5 5/5] thermal: renesas: rzg3e: add support for RZ/T2H
 and RZ/N2H

Hi Cosmin,

> -----Original Message-----
> From: Cosmin-Gabriel Tanislav <cosmin-gabriel.tanislav.xa@...esas.com>
> Sent: 09 January 2026 09:57
> Subject: RE: [PATCH v5 5/5] thermal: renesas: rzg3e: add support for RZ/T2H and RZ/N2H
> 
> > From: Biju Das <biju.das.jz@...renesas.com>
> > Sent: Friday, January 9, 2026 11:06 AM
> >
> >
> > Hi Cosmin,
> >
> > > -----Original Message-----
> > > From: Cosmin-Gabriel Tanislav
> > > <cosmin-gabriel.tanislav.xa@...esas.com>
> > > Sent: 09 January 2026 08:51
> > > Subject: RE: [PATCH v5 5/5] thermal: renesas: rzg3e: add support for
> > > RZ/T2H and RZ/N2H
> > >
> > > > From: Biju Das <biju.das.jz@...renesas.com>
> > > > Sent: Friday, January 9, 2026 8:12 AM
> > > >
> > > > Hi Geert/Cosmin/John,
> > > >
> > > > > -----Original Message-----
> > > > > From: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@...esas.com>
> > > > > Sent: 08 January 2026 19:52
> > > > > Subject: [PATCH v5 5/5] thermal: renesas: rzg3e: add support for
> > > > > RZ/T2H and RZ/N2H
> > > > >
> > > > > The Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs
> > > > > expose the temperature calibration via
> > > > SMC
> > > > > SIP and do not have a reset for the TSU peripheral, and use
> > > > > different minimum and maximum
> > > > temperature
> > > > > values compared to the already supported RZ/G3E.
> > > > >
> > > > > Although the calibration data is stored in an OTP memory, the
> > > > > OTP itself is not memory-mapped,
> > > > access
> > > > > to it is done through an OTP controller.
> > > > >
> > > > > The OTP controller is only accessible from the secure world, but
> > > > > the temperature calibration data stored in the OTP is exposed via SMC.
> > > > >
> > > > > Add support for retrieving the calibration data using arm_smcc_smc().
> > > > >
> > > > > Add a compatible for RZ/T2H, RZ/N2H can use it as a fallback.
> > > > >
> > > > > Reviewed-by: John Madieu <john.madieu.xa@...renesas.com>
> > > > > Tested-by: John Madieu <john.madieu.xa@...renesas.com>
> > > > > Signed-off-by: Cosmin Tanislav
> > > > > <cosmin-gabriel.tanislav.xa@...esas.com>
> > > > > ---
> > > > >
> > > > > V5:
> > > > >  * add arm-smccc.h include
> > > > >
> > > > > V4:
> > > > >  * pick up John's Reviewed-by and Tested-by
> > > > >  * replace new macro TSU_TEMP_MASK usage with existing macro
> > > > >    TSU_CODE_MAX
> > > > >
> > > > > V3:
> > > > >  * no changes
> > > > >
> > > > > V2:
> > > > >  * no changes
> > > > >
> > > > >  drivers/thermal/renesas/rzg3e_thermal.c | 27
> > > > > +++++++++++++++++++++++++
> > > > >  1 file changed, 27 insertions(+)
> > > > >
> > > > > diff --git a/drivers/thermal/renesas/rzg3e_thermal.c
> > > > > b/drivers/thermal/renesas/rzg3e_thermal.c
> > > > > index 97c4053303e0..dde021e283b7 100644
> > > > > --- a/drivers/thermal/renesas/rzg3e_thermal.c
> > > > > +++ b/drivers/thermal/renesas/rzg3e_thermal.c
> > > > > @@ -4,6 +4,7 @@
> > > > >   *
> > > > >   * Copyright (C) 2025 Renesas Electronics Corporation
> > > > >   */
> > > > > +#include <linux/arm-smccc.h>
> > > > >  #include <linux/clk.h>
> > > > >  #include <linux/cleanup.h>
> > > > >  #include <linux/delay.h>
> > > > > @@ -70,6 +71,10 @@
> > > > >  #define TSU_POLL_DELAY_US	10	/* Polling interval */
> > > > >  #define TSU_MIN_CLOCK_RATE	24000000  /* TSU_PCLK minimum 24MHz */
> > > > >
> > > > > +#define RZ_SIP_SVC_GET_SYSTSU	0x82000022
> > > >
> > > > Maybe add a comment mentioning firmware should support this index
> > > > and the otp value is stored in
> > > > arm_smccc_res.a0
> > > >
> > >
> > > The fact that the calibration value is stored in .a0 is clear from
> > > the retrieval code, let's not add comments where the code is straightforward.
> >
> > If you have just a0, then driver expect a0 from firmware is either
> > error and OTP value.
> >
> > If you have a0 and a1
> >
> > Success case a0=0
> > Error case a0=SMC_UNK
> >
> > a1 will have the value from OTP.
> >
> >
> > >
> > > Regarding the firmware support, it's obvious that the firmware needs
> > > to support this and that the values don't just magically appear, no?
> >
> > How do you share this info to customers that they have their own firmware?
> >
> > Eg: Customer firmware is using different service ID and driver uses different one.
> >
> 
> If you think it will help customers, we can add a comment like below.
> 
> /*
>  * SMC function ID for reading TSU calibration values from OTP needs to
>  * be supported by the TF-A firmware. Calibration value must be returned
>  * in the a0 register.
>  */


OK.

> #define RZ_SIP_SVC_GET_SYSTSU	0x82000022
> #define OTP_TSU_REG_ADR_TEMPHI	0x01DC
> #define OTP_TSU_REG_ADR_TEMPLO	0x01DD
> 
> > >
> > > Let's see what Geert thinks.
> > >
> > > > > +#define OTP_TSU_REG_ADR_TEMPHI	0x01DC
> > > > > +#define OTP_TSU_REG_ADR_TEMPLO	0x01DD
> > > > > +
> > > > >  struct rzg3e_thermal_priv;
> > > > >
> > > > >  struct rzg3e_thermal_info {
> > > > > @@ -362,6 +367,21 @@ static int rzg3e_thermal_get_syscon_trim(struct rzg3e_thermal_priv *priv)
> > > > >  	return 0;
> > > > >  }
> > > > >
> > > > > +static int rzg3e_thermal_get_smc_trim(struct rzg3e_thermal_priv
> > > > > +*priv) {
> > > > > +	struct arm_smccc_res local_res;
> > > > > +
> > > > > +	arm_smccc_smc(RZ_SIP_SVC_GET_SYSTSU, OTP_TSU_REG_ADR_TEMPLO,
> > > > > +		      0, 0, 0, 0, 0, 0, &local_res);
> > > > > +	priv->trmval0 = local_res.a0 & TSU_CODE_MAX;
> > > >
> > > > Do you think it is worth to ask firmware team to return error
> > > > values in a0 and actual OTP value in a1.
> > > >
> > > > So that driver can check the error code and propagate to the caller.
> > > >
> > >
> > > If we do that, we will have one more variant to handle here, as we
> > > cannot make sure that the TF-A running on the board is always the latest.
> >
> > Mainline will use new variant, that can have both a0 and a1, if we take that route.
> >
> 
> Mainline code will be backported to CIP, and customers might try to use old firmware with CIP. Not
> adding another variant is the better way in my opinion.
> 
> We can wait for Geert's opinion.

OK.

> 
> > >
> > > Right now things are simple as it's either supported or not supported.
> > >
> > > If a0 is some error value, how would you distinguish between an
> > > error in the new variant and a
> > proper
> > > value in the old variant? Both cases would only populate a0.
> > >
> > > Also, I'm not sure how much use we can get out of a TF-A error value.
> > >
> > > The error that TF-A already returns in SMC_UNK = -1, or 0xFFFFFFFF
> > > in u32, it is pretty standard for SMC calls and the probe() function already checks against it.
> >
> > The OTP value can be 0xFFFFFFFF, if it is not programmed, if that is
> > case How do you distinguish error with respect actual otp value.
> >
> 
> From the kernel's standpoint both error case and an unprogrammed value stored in OTP have the same
> effect: missing calibration data, cannot use the TSU.

If a0 = -1
Error case could be missing SVC handler in TF_A, Wrong ID.

If a0=0 , a1 = -1
Unprogrammed value: missing calibration data, cannot use the TSU.

Cheers,
Biju

Powered by blists - more mailing lists