From: Dragan Simic <dsimic@manjaro.org>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
linux-kernel@vger.kernel.org,
Diederik de Haas <didi.debian@cknow.org>,
Jonas Karlman <jonas@kwiboo.se>
Subject: Re: [PATCH] arm64: dts: rockchip: Add optional GPU OPP voltage ranges to RK356x SoC dtsi
Date: Sat, 29 Jun 2024 17:25:12 +0200 [thread overview]
Message-ID: <f10d5a3c425c2c4312512c20bd35073c@manjaro.org> (raw)
In-Reply-To: <7679413.EvYhyI6sBW@diego>
Hello Heiko,
On 2024-06-29 17:10, Heiko Stübner wrote:
> Am Samstag, 29. Juni 2024, 07:11:24 CEST schrieb Dragan Simic:
>
>> +#ifndef RK356X_GPU_NPU_SHARED_REGULATOR
>
> is there some reason for this duplicating of opps?
>
> The regulator framework should pick the lowest supported voltage
> anyway, so it seems you're just extending them upwards a bit.
>
> So I really don't so why we'd need to sets here.
The reason is improved strictness. Having the exact GPU OPP voltages
required for the boards whose GPU regulators can provide those exact
voltages makes it possible to detect misconfigurations much easier,
just like it was the case with the board dts misconfiguration that
resulted in the recent DCDC_REG2 patch. [1]
If we had GPU OPP voltage ranges in place instead, the aforementioned
issue would probably remain undetected for some time. It wouldn't be
the end of the world, :) of course, but the resulting increased power
consumption isn't one of the desired outcomes.
[1]
https://lore.kernel.org/linux-rockchip/e70742ea2df432bf57b3f7de542d81ca22b0da2f.1716225483.git.dsimic@manjaro.org/
> Also the voltage-range thing makes sense for non-gpu-npu-sharing
> boards, when the supplying regulator does not fully support the
> direct single-value voltage.
>
> (rk3399-puma was such a case if I remember correctly)
>
> So I really see no reason for this duplication.
Perhaps we could rename the RK356X_GPU_NPU_SHARED_REGULATOR macro
accordingly in the v2, to RK356X_GPU_OPP_VOLTAGE_RANGES, for example,
with some additional explanations in the patch description and the
RK356x SoC dtsi file itself.
>> opp-200000000 {
>> opp-hz = /bits/ 64 <200000000>;
>> opp-microvolt = <825000>;
>> @@ -222,6 +229,37 @@ opp-800000000 {
>> opp-hz = /bits/ 64 <800000000>;
>> opp-microvolt = <1000000>;
>> };
>> +#else
>> + opp-200000000 {
>> + opp-hz = /bits/ 64 <200000000>;
>> + opp-microvolt = <825000 825000 1000000>;
>> + };
>> +
>> + opp-300000000 {
>> + opp-hz = /bits/ 64 <300000000>;
>> + opp-microvolt = <825000 825000 1000000>;
>> + };
>> +
>> + opp-400000000 {
>> + opp-hz = /bits/ 64 <400000000>;
>> + opp-microvolt = <825000 825000 1000000>;
>> + };
>> +
>> + opp-600000000 {
>> + opp-hz = /bits/ 64 <600000000>;
>> + opp-microvolt = <825000 825000 1000000>;
>> + };
>> +
>> + opp-700000000 {
>> + opp-hz = /bits/ 64 <700000000>;
>> + opp-microvolt = <900000 900000 1000000>;
>> + };
>> +
>> + opp-800000000 {
>> + opp-hz = /bits/ 64 <800000000>;
>> + opp-microvolt = <1000000 1000000 1000000>;
>> + };
>> +#endif /* RK356X_GPU_NPU_SHARED_REGULATOR */
>> };
>>
>> hdmi_sound: hdmi-sound {
>>
>
>
>
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2024-06-29 15:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-29 5:11 [PATCH] arm64: dts: rockchip: Add optional GPU OPP voltage ranges to RK356x SoC dtsi Dragan Simic
2024-06-29 15:10 ` Heiko Stübner
2024-06-29 15:25 ` Dragan Simic [this message]
2024-06-29 15:39 ` Dragan Simic
2024-06-29 16:18 ` Heiko Stübner
2024-06-29 16:22 ` 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=f10d5a3c425c2c4312512c20bd35073c@manjaro.org \
--to=dsimic@manjaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=didi.debian@cknow.org \
--cc=heiko@sntech.de \
--cc=jonas@kwiboo.se \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=robh@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