Message-ID:
 <TYRPR01MB156190E553ED0745039A7719C8582A@TYRPR01MB15619.jpnprd01.prod.outlook.com>
Date: Fri, 9 Jan 2026 11:14:49 +0000
From: Cosmin-Gabriel Tanislav <cosmin-gabriel.tanislav.xa@...esas.com>
To: Geert Uytterhoeven <geert+renesas@...der.be>, Biju Das
	<biju.das.jz@...renesas.com>, John Madieu <john.madieu.xa@...renesas.com>
CC: "conor+dt@...nel.org" <conor+dt@...nel.org>, "daniel.lezcano@...aro.org"
	<daniel.lezcano@...aro.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
	"lukasz.luba@....com" <lukasz.luba@....com>, magnus.damm
	<magnus.damm@...il.com>, "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
	"rafael@...nel.org" <rafael@...nel.org>, "robh@...nel.org" <robh@...nel.org>,
	"rui.zhang@...el.com" <rui.zhang@...el.com>
Subject: RE: [PATCH v5 5/5] thermal: renesas: rzg3e: add support for RZ/T2H
 and RZ/N2H

> From: Geert Uytterhoeven <geert+renesas@...der.be>
> Sent: Friday, January 9, 2026 12:00 PM
> 
> Hi Biju, Cosmin, John,
> 
> On Fri, 9 Jan 2026 at 10:06, Biju Das <biju.das.jz@...renesas.com> wrote:
> > > From: Cosmin-Gabriel Tanislav <cosmin-gabriel.tanislav.xa@...esas.com>
> > > > From: Biju Das <biju.das.jz@...renesas.com>
> > > > > From: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@...esas.com>
> > > > > 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>
> 
> > > > > --- 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.
> 
> Agreed.
> 
> > 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.
> 
> Specify the service ID in DT?
> 

We can do that in a separate series if / when needed, and use the
RZ_SIP_SVC_GET_SYSTSU value by default if the device tree does not
contain a SMC id for the TSU.

> > > > > +#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.
> >
> > > Right now things are simple as it's either supported or not supported.
> 
> Agreed.
> 
> > > 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.
> 
> What is the expected behavior when the firmware interface is not
> available, or the OTP is not programmed?
> Currently the thermal driver fails to probe, which is IMHO suboptimal.
> An alternative would be to fallback to default calibration values,
> as done on R-Car Gen3.  To handle that, rzg3e_thermal_get_smc_trim()
> should store the unmasked values in trmval[01], so the probe code can
> detect this case.
> 
> BTW, what are the default values of the trim registers on RZ/G3E, when
> the device is not trimmed? Or is this always done, unlike programming
> the OTP on RZ/T2H?
> 

Only early silicon should be missing the calibration values on RZ/T2H
and RZ/N2H.

For RZ/T2H, I have:
rzg3e_thermal 80086000.thermal: Calibration: b=0x33a (826), c=0xcd7 (3287)

And for RZ/N2H:
rzg3e_thermal 80086000.thermal: Calibration: b=0x30b (779), c=0xccf (3279)

I asked my colleagues for their calibration values and we have the following.

RZ/G3E:
rzg3e_thermal 14002000.thermal: Calibration: b=0x2c6 (710), c=0xcd5 (3285)

RZ/V2H (has two TSUs):
rzg3e_thermal 11000000.thermal: Calibration: b=0x319 (793), c=0xcbe (3262)
rzg3e_thermal 14002000.thermal: Calibration: b=0x333 (819), c=0xcc8 (3272)

RZ/V2N (Ovidiu is adding support for it as a separate series which depends
on this one):
rzg3e_thermal 11000000.thermal: Calibration: b=0x304 (772), c=0xc91 (3217)
rzg3e_thermal 14002000.thermal: Calibration: b=0x307 (775), c=0xc87 (3207)


We can use the average of these samples as default values, they seem
close enough.

In a future series, of course.

What do you think?

> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Powered by blists - more mailing lists