[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdXw4XDkwBOqM47TKa8d_jHBMTM1ZGhK9qm5KQWDfGjGSw@mail.gmail.com>
Date: Tue, 5 Aug 2025 11:35:19 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: John Madieu <john.madieu.xa@...renesas.com>
Cc: "conor+dt@...nel.org" <conor+dt@...nel.org>,
"daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
"rafael@...nel.org" <rafael@...nel.org>, Biju Das <biju.das.jz@...renesas.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"john.madieu@...il.com" <john.madieu@...il.com>,
"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>,
"robh@...nel.org" <robh@...nel.org>, "rui.zhang@...el.com" <rui.zhang@...el.com>,
"sboyd@...nel.org" <sboyd@...nel.org>,
"niklas.soderlund+renesas@...natech.se" <niklas.soderlund+renesas@...natech.se>
Subject: Re: [PATCH v6 3/5] thermal: renesas: rzg3e: Add thermal driver for
the Renesas RZ/G3E SoC
Hi John,
On Tue, 5 Aug 2025 at 11:22, John Madieu <john.madieu.xa@...renesas.com> wrote:
> > From: Geert Uytterhoeven <geert@...ux-m68k.org>
> > On Tue, 5 Aug 2025 at 10:27, John Madieu <john.madieu.xa@...renesas.com>
> > wrote:
> > > > From: Geert Uytterhoeven <geert@...ux-m68k.org> On Thu, 22 May 2025
> > > > at 20:23, John Madieu <john.madieu.xa@...renesas.com>
> > > > wrote:
> > > > > The RZ/G3E SoC integrates a Temperature Sensor Unit (TSU) block
> > > > > designed to monitor the chip's junction temperature. This sensor
> > > > > is connected to channel 1 of the APB port clock/reset and provides
> > > > temperature measurements.
> > > >
> > > > RZ/V2H and RZ/V2N have a second set of trim values for the second
> > > > TSU instance. So I guess you want to specify the offset in DT instead.
> > >
> > > What do you think of 'renesas,tsu-channel' property or alike Property
> > > to specify the channel being used ?
> >
> > While I agree instance IDs canbe useful (sometimes), the DT maintainers do
> > not like them very much, cfr. commit 6a57cf210711c068 ("docs: dt:
> > writing-bindings: Document discouraged instance IDs"), which prefers
> > cell/phandle arguments.
> >
> > For this particular case:
> > 1. The instance ID for the single TSU on RZ/G3E would be one, not zero
> > (oh, the SYS_LSI_OTPTSU1TRMVAL[01] register names do contain "TSU1"),
> > 2. It will break the moment a new SoC is released that stores trim
> > values at different offsets in the SYSC block.
> >
> > Hence a property containing a SYSC phandle and register offset sounds
> > better to me.
>
> This sounds good to me. I see something like:
>
> renesas,tsu-channel1 = <&sysc off1>;
> renesas,tsu-channel2 = <&sysc off2>; /* Optional, for V2H */
>
> /* or */
>
> renesas,tsu-channel-map = <&sysc off1 off2>;
>
> I would go for the first option to make it easier for V2H
> (while adding support for it later) so it can choose using
> either, or both, regardless of the index.
>
> What do you think ?
As the property would be part of the TSU node, it would always
refer to that specific channel/instance, so e.g.
renesas,tsu-trim = <&sysc 0x320>;
for the first TSU instance, and
renesas,tsu-trim = <&sysc 0x330>;
for the second instance.
P.S. Please don't write "V2H" on its own, as both R-Car V2H and RZ/V2H
exist in the Renesas SoC portfolio ;-)
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