From: Dragan Simic <dsimic@manjaro.org>
To: Heiko Stuebner <heiko@sntech.de>
Cc: Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Alexey Charkov <alchark@gmail.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Chen-Yu Tsai <wens@kernel.org>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/5] arm64: dts: rockchip: enable built-in thermal monitoring on RK3588
Date: Sat, 02 Mar 2024 19:38:14 +0100 [thread overview]
Message-ID: <3f73d847fbe9d7f6dd05802eb7e47d49@manjaro.org> (raw)
In-Reply-To: <6279836.31r3eYUQgx@phil>
Hello Heiko,
On 2024-03-02 12:25, Heiko Stuebner wrote:
> Am Donnerstag, 29. Februar 2024, 20:26:32 CET schrieb Alexey Charkov:
>> Include thermal zones information in device tree for RK3588 variants.
>>
>> This also enables the TSADC controller unconditionally on all boards
>> to ensure that thermal protections are in place via throttling and
>> emergency reset, once OPPs are added to enable CPU DVFS.
>>
>> The default settings (using CRU as the emergency reset mechanism)
>> should work on all boards regardless of their wiring, as CRU resets
>> do not depend on any external components. Boards that have the TSHUT
>> signal wired to the reset line of the PMIC may opt to switch to GPIO
>> tshut mode instead (rockchip,hw-tshut-mode = <1>;)
>>
>> It seems though that downstream kernels don't use that, even for
>> those boards where the wiring allows for GPIO based tshut, such as
>> Radxa Rock 5B [1], [2], [3]
>>
>> [1]
>> https://github.com/radxa/kernel/blob/stable-5.10-rock5/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts#L540
>> [2]
>> https://github.com/radxa/kernel/blob/stable-5.10-rock5/arch/arm64/boot/dts/rockchip/rk3588s.dtsi#L5433
>> [3] https://dl.radxa.com/rock5/5b/docs/hw/radxa_rock_5b_v1423_sch.pdf
>> page 11 (TSADC_SHUT_H)
>>
>> Signed-off-by: Alexey Charkov <alchark@gmail.com>
>> ---
>> arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 176
>> +++++++++++++++++++++++++++++-
>> 1 file changed, 175 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
>> b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
>> index 36b1b7acfe6a..9bf197358642 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
>> @@ -10,6 +10,7 @@
>> #include <dt-bindings/reset/rockchip,rk3588-cru.h>
>> #include <dt-bindings/phy/phy.h>
>> #include <dt-bindings/ata/ahci.h>
>> +#include <dt-bindings/thermal/thermal.h>
>>
>> / {
>> compatible = "rockchip,rk3588";
>> @@ -2225,7 +2226,180 @@ tsadc: tsadc@fec00000 {
>> pinctrl-1 = <&tsadc_shut>;
>> pinctrl-names = "gpio", "otpout";
>> #thermal-sensor-cells = <1>;
>> - status = "disabled";
>> + status = "okay";
>> + };
>
> so I've skimmed over the general discussion, though don't have a hard
> opinion in either direction yet. Still there are some low-hanging
> fruit:
>
> - having the thermal-zones addition in a separate patch would allow to
> merge the obvious stuff, while this discussion is still ongoing
Very good suggestion.
> - status=okay in a soc dtsi is wrong, because okay is the default
> status
> so if anything the status property should be removed
>
> In general I'm not that much of a fan of things just working
> implicitly.
> So somehow, when someone submits a board devicetree, I expect them to
> having ensured stuff is enabled somewhat ok. So even seeing a simple
>
> &tsadc {
> status = "okay"
> };
>
> suggests that they have at least noticed the existence of thermal
> stuff.
I agree that having such additional "signed-off markers", so to speak,
in
a board dts is quite assuring. I mean, someone implementing a new dts
file
for a new board should simply know what needs to be done there, and
there
should be no excuses for not checking the thermal throttling stuff.
next prev parent reply other threads:[~2024-03-02 18:38 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-29 19:26 [PATCH v3 0/5] RK3588 and Rock 5B dts additions: thermal, OPP and fan Alexey Charkov
2024-02-29 19:26 ` [PATCH v3 1/5] arm64: dts: rockchip: enable built-in thermal monitoring on RK3588 Alexey Charkov
2024-02-29 20:21 ` Dragan Simic
2024-03-01 5:12 ` Alexey Charkov
2024-03-01 5:51 ` Dragan Simic
2024-03-01 8:25 ` Alexey Charkov
2024-03-01 8:52 ` Dragan Simic
2024-03-01 9:24 ` Dragan Simic
2024-03-01 11:10 ` Alexey Charkov
2024-03-01 12:02 ` Chen-Yu Tsai
2024-03-01 13:11 ` Dragan Simic
2024-03-01 12:34 ` Dragan Simic
2024-02-29 21:11 ` Dragan Simic
2024-03-01 5:20 ` Alexey Charkov
2024-03-01 6:14 ` Dragan Simic
2024-03-01 7:51 ` Alexey Charkov
2024-03-01 8:21 ` Dragan Simic
2024-03-02 11:25 ` Heiko Stuebner
2024-03-02 18:38 ` Dragan Simic [this message]
2024-02-29 19:26 ` [PATCH v3 2/5] arm64: dts: rockchip: enable automatic active cooling on Rock 5B Alexey Charkov
2024-02-29 21:25 ` Dragan Simic
2024-03-01 5:21 ` Alexey Charkov
2024-03-01 6:17 ` Dragan Simic
2024-03-01 8:25 ` Dragan Simic
2024-03-01 8:30 ` Alexey Charkov
2024-03-01 9:32 ` Dragan Simic
2024-02-29 19:26 ` [PATCH v3 3/5] arm64: dts: rockchip: Add CPU/memory regulator coupling for RK3588 Alexey Charkov
2024-03-01 8:13 ` Dragan Simic
2024-03-11 10:24 ` Dragan Simic
2024-02-29 19:26 ` [PATCH v3 4/5] arm64: dts: rockchip: Add OPP data for CPU cores on RK3588 Alexey Charkov
2024-03-01 6:31 ` Dragan Simic
2024-02-29 19:26 ` [PATCH v3 5/5] arm64: dts: rockchip: Add further granularity in RK3588 CPU OPPs Alexey Charkov
2024-03-01 6:36 ` Dragan Simic
2024-03-04 17:50 ` [PATCH v3 0/5] RK3588 and Rock 5B dts additions: thermal, OPP and fan Sebastian Reichel
2024-03-05 8:06 ` Alexey Charkov
2024-03-07 12:38 ` Alexey Charkov
2024-03-07 14:21 ` Dragan Simic
2024-03-11 7:08 ` Dragan Simic
2024-03-07 22:16 ` Sebastian Reichel
2024-03-13 16:39 ` Sebastian Reichel
2024-03-13 16:44 ` Dragan Simic
2024-04-10 9:19 ` Diederik de Haas
2024-04-10 9:28 ` Dragan Simic
2024-04-20 17:53 ` Diederik de Haas
2024-04-21 16:07 ` Dragan Simic
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=3f73d847fbe9d7f6dd05802eb7e47d49@manjaro.org \
--to=dsimic@manjaro.org \
--cc=alchark@gmail.com \
--cc=conor+dt@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=robh+dt@kernel.org \
--cc=viresh.kumar@linaro.org \
--cc=wens@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).