linux-kernel - Re: [PATCH] arm64: dts: rockchip: Add optional GPU OPP voltage ranges to RK356x SoC dtsi

Open Source and information security mailing list archives

Message-ID: <f10d5a3c425c2c4312512c20bd35073c@manjaro.org>
Date: Sat, 29 Jun 2024 17:25:12 +0200
From: Dragan Simic <dsimic@...jaro.org>
To: Heiko Stübner <heiko@...ech.de>
Cc: linux-rockchip@...ts.infradead.org,
 linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
 robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
 linux-kernel@...r.kernel.org, Diederik de Haas <didi.debian@...ow.org>,
 Jonas Karlman <jonas@...boo.se>
Subject: Re: [PATCH] arm64: dts: rockchip: Add optional GPU OPP voltage ranges
 to RK356x SoC dtsi

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@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives