Hi Alexey, On Wed, 8 May 2024 at 18:52, Alexey Charkov <alchark@xxxxxxxxx> wrote: > > On Wed, May 8, 2024 at 4:51 PM Anand Moon <linux.amoon@xxxxxxxxx> wrote: > > > > Hi Dragan, Alexey, > > > > On Wed, 8 May 2024 at 18:08, Dragan Simic <dsimic@xxxxxxxxxxx> wrote: > > > > > > Hello Alexey, > > > > > > On 2024-05-08 14:30, Alexey Charkov wrote: > > > > On Wed, May 8, 2024 at 3:46 PM Dragan Simic <dsimic@xxxxxxxxxxx> wrote: > > > >> On 2024-05-08 13:40, Anand Moon wrote: > > > >> > On Mon, 6 May 2024 at 18:24, Alexey Charkov <alchark@xxxxxxxxx> wrote: > > > >> >> On Mon, May 6, 2024 at 4:29 PM Diederik de Haas > > > >> >> <didi.debian@xxxxxxxxx> wrote: > > > >> >> > On Monday, 6 May 2024 11:36:33 CEST Alexey Charkov wrote: > > > >> >> > > This enables the on-chip thermal monitoring sensor (TSADC) on all > > > >> >> > > RK3588(s) boards that don't have it enabled yet. It provides temperature > > > >> >> > > monitoring for the SoC and emergency thermal shutdowns, and is thus > > > >> >> > > important to have in place before CPU DVFS is enabled, as high CPU > > > >> >> > > operating performance points can overheat the chip quickly in the > > > >> >> > > absence of thermal management. > > > >> >> > > > > > >> >> > > Signed-off-by: Alexey Charkov <alchark@xxxxxxxxx> > > > >> >> > > --- > > > >> >> > > arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts | 4 ++++ > > > >> >> > > 8 files changed, 32 insertions(+) > > > >> >> > > > > > >> >> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts > > > >> >> > > b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts index > > > >> >> > > b8e15b76a8a6..21e96c212dd8 100644 > > > >> >> > > --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts > > > >> >> > > +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts > > > >> >> > > @@ -742,6 +742,10 @@ regulator-state-mem { > > > >> >> > > }; > > > >> >> > > }; > > > >> >> > > > > > >> >> > > +&tsadc { > > > >> >> > > + status = "okay"; > > > >> >> > > +}; > > > >> >> > > + > > > >> >> > > &uart2 { > > > >> >> > > pinctrl-0 = <&uart2m0_xfer>; > > > >> >> > > status = "okay"; > > > >> >> > > > > >> >> > I built a kernel with v3 of your patch set and someone tested it on a ROCK 5B > > > >> >> > 'for me' and it had the following line in dmesg: > > > >> >> > > > > >> >> > rockchip-thermal fec00000.tsadc: Missing rockchip,grf property > > > >> >> > > > > >> >> > I'm guessing that turned up due to enabling tsadc, but (also) in v4 I didn't > > > >> >> > see a change wrt "rockchip,grf". > > > >> >> > Should that be done? (asking; I don't know) > > > >> >> > > > >> >> I'm getting the same. Neither the mainline TSADC driver [1], nor the > > > >> >> downstream one [2] seems to use the grf pointer on RK3588 at all. It > > > >> >> still works in spite of that warning, although I can't see how (or if) > > > >> >> it configures the reset mechanism without those GRF registers. > > > >> >> > > > >> >> Best regards, > > > >> >> Alexey > > > >> >> > > > >> >> [1] > > > >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/thermal/rockchip_thermal.c#n818 > > > >> >> [2] > > > >> >> https://github.com/radxa/kernel/blob/stable-5.10-rock5/drivers/thermal/rockchip_thermal.c#L961 > > > >> >> > > > >> > > > > >> > If the following changes fix the warning. > > > >> > > > > >> > Checking the Rockchip RK3588 TRM V1.0-Part1-20220309.pdf > > > >> > PMU1GRF_SOC_CON3 which has tsadc_shut_reset_trigger_en bit > > > >> > to control the Enable TSADC shut reset trigger for DDR fail safe. > > > >> > > > > >> > diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi > > > >> > b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi > > > >> > index 85c25d5efdad..5490a44e093e 100644 > > > >> > --- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi > > > >> > +++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi > > > >> > @@ -2662,6 +2662,7 @@ tsadc: tsadc@fec00000 { > > > >> > rockchip,hw-tshut-temp = <120000>; > > > >> > rockchip,hw-tshut-mode = <0>; /* tshut mode 0:CRU > > > >> > 1:GPIO */ > > > >> > rockchip,hw-tshut-polarity = <0>; /* tshut polarity > > > >> > 0:LOW 1:HIGH */ > > > >> > + rockchip,pmu = <&pmu1grf>; > > > >> > pinctrl-0 = <&tsadc_gpio_func>; > > > >> > pinctrl-1 = <&tsadc_shut>; > > > >> > pinctrl-names = "gpio", "otpout"; > > > >> > > > >> Basically, the rockchip_thermal driver doesn't use GRF at all on > > > >> the RK3588(s), so virtually any value specified as "rockchip,pmu" > > > >> can eliminate the warning. > > > > > > > > To me, specifying an arbitrary GRF in the device tree just to silence > > > > a warning that the current driver emits sounds bad. If the GRF is not > > > > needed for TSADC initialization on RK3588, then it should not be in > > > > the device tree (and it looks like the case here) - otherwise the > > > > device tree ceases to be a truthful description of the hardware. > > > > > > After thinking a bit more about it, I think you're right. If the > > > rockchip_thermal driver ever gets changed to require use of GRF on > > > the RK3588(s), only then adding that property to the DT would be > > > the right thing to do. > > > > > > > I'm not sure if we need that "DDR fail safe" logic mentioned in the > > > > TRM that Anand quoted, given that neither Rockchip downstream nor > > > > current mainline driver implement it, and furthermore none of the > > > > other SoC revisions supported by the driver mention it. If we do in > > > > fact need it, we should probably first test it along with respective > > > > driver code before committing to an upstream DT and thus making it > > > > part of the ABI. > > > > > > > > IMO this is more of a driver issue than a device tree issue: maybe a > > > > small patch to demote this warning to an info message would be better? > > > > It's harmless anyway. > > > > > > After having second thoughts, I'll see to improve the rockchip_thermal > > > driver to emit that warning only when having "rockchip,grf" specified > > > is actually needed for the particular Rockchip SoC. That's how it > > > should > > > behave, yelling about the wrong hardware description only when that's > > > actually the case. > > > > We need to handle the GRF TSADC for rk3588 tmu driver. > > > > For rk3568 we control the GRF TSADC which seems to be missing in rk3588 > > Please note that for RK3568 the GRF registers are used to actually > enable the thermal sensing (as can be seen by the link you posted), > which doesn't seem to be necessary on RK3588 as it works just fine > without it. Furthermore, RK3568 has a nearly identical GRF register in > PMU_GRF_SOC_CON3 (see RK3568 TRM part1 page 206) to the one you > proposed referencing in the DT for RK3588, but that register is not > used in the TSADC driver either. It only uses the TSADC_CON register > within SYS_GRF (offset 0x600) on RK3568. > I feel there is no PMUGRF configuration for TS-ADC on RK3588 SoC as per the TRM. So we can ignore the warning. > The TRM for RK3588 doesn't document any TSADC_CON register, even > though there is a #define in the current upstream driver that mentions > an offset of 0x100 to that register within the GRF. I'm not sure it > means 0x100 within PMU1_GRF as you mentioned - do you have any > pointers to support that? > Yes, you can drop them as there is no RK3588_GRF0_TSADC_CON register to support such settings. Thanks -Anand