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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b6f8f705-f661-46cf-9dda-6f18f8658622@kwiboo.se>
Date: Thu, 10 Jul 2025 14:11:00 +0200
From: Jonas Karlman <jonas@...boo.se>
To: Heiko Stuebner <heiko@...ech.de>, Chukun Pan <amadeus@....edu.cn>
Cc: Yao Zi <ziyao@...root.org>, Rob Herring <robh@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org
Subject: Re: [PATCH v2 1/1] arm64: dts: rockchip: rk3528: Add CPU frequency
 scaling support

Hi Heiko and Chukun,

On 7/10/2025 1:45 PM, Heiko Stuebner wrote:
> Am Freitag, 20. Juni 2025, 12:00:10 Mitteleuropäische Sommerzeit schrieb Chukun Pan:
>> By default, the CPUs on RK3528 operates at 1.5GHz. Add CPU frequency and
>> voltage mapping to the device tree to enable dynamic scaling via cpufreq.
>>
>> The OPP values come from downstream kernel[1]. Both 408MHz and 600MHz
>> frequencies use the normal PLL, so use the corresponding highest voltage.
>>
>> The voltage used for other frequencies can't be less than above (875mV).
>> Therefore, 816MHz to 1200MHz also uses the corresponding highest voltage.
> 
> There has often been the argument that selecting a frequency that has the
> same voltage as a faster frequency does not save any power.
> 
> Hence I remember that we dropped slower frequencies on other socs
> that share the same voltage with a higher frequency.

One possible difference here is that the actual CPU rate is controlled
by a PVTPLL where TF-A will configure a osc ring-length based on the
requested rate and Linux only configure the regulator voltage.

I have no idea if the configuration made by TF-A will have any affect on
power usage, but I suggest we keep all opp here because both TF-A and
Linux is involved in configuring the CPU rate.

The measured rate can typically be read from a PVTPLL status reg, it
will be different depending on the ring-length, voltage and silicon
quality for the rates >= 816 MHz.

> 
>>
>> The remaining 1416MHz to 2016MHz use a voltage close to actual frequency.
>>
>> [1] https://github.com/rockchip-linux/kernel/blob/develop-5.10/arch/arm64/boot/dts/rockchip/rk3528.dtsi
>>
>> Signed-off-by: Chukun Pan <amadeus@....edu.cn>
>> ---
>>  arch/arm64/boot/dts/rockchip/rk3528.dtsi | 64 ++++++++++++++++++++++++
>>  1 file changed, 64 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3528.dtsi b/arch/arm64/boot/dts/rockchip/rk3528.dtsi
>> index 829f980ea353..5cb7f10b79ed 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3528.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3528.dtsi
>> @@ -53,6 +53,7 @@ cpu0: cpu@0 {
>>  			device_type = "cpu";
>>  			enable-method = "psci";
>>  			clocks = <&scmi_clk SCMI_CLK_CPU>;
>> +			operating-points-v2 = <&cpu_opp_table>;
>>  		};
>>  
>>  		cpu1: cpu@1 {
>> @@ -61,6 +62,7 @@ cpu1: cpu@1 {
>>  			device_type = "cpu";
>>  			enable-method = "psci";
>>  			clocks = <&scmi_clk SCMI_CLK_CPU>;
>> +			operating-points-v2 = <&cpu_opp_table>;
>>  		};
>>  
>>  		cpu2: cpu@2 {
>> @@ -69,6 +71,7 @@ cpu2: cpu@2 {
>>  			device_type = "cpu";
>>  			enable-method = "psci";
>>  			clocks = <&scmi_clk SCMI_CLK_CPU>;
>> +			operating-points-v2 = <&cpu_opp_table>;
>>  		};
>>  
>>  		cpu3: cpu@3 {
>> @@ -77,6 +80,67 @@ cpu3: cpu@3 {
>>  			device_type = "cpu";
>>  			enable-method = "psci";
>>  			clocks = <&scmi_clk SCMI_CLK_CPU>;
>> +			operating-points-v2 = <&cpu_opp_table>;
>> +		};
>> +	};
>> +
>> +	cpu_opp_table: opp-table-cpu {

This node should be placed after the firmware node for the nodes to be
in alphabetical order.

Regards,
Jonas

>> +		compatible = "operating-points-v2";
>> +		opp-shared;
>> +
>> +		opp-408000000 {
>> +			opp-hz = /bits/ 64 <408000000>;
>> +			opp-microvolt = <875000 875000 1100000>;
>> +			clock-latency-ns = <40000>;
>> +			opp-suspend;
>> +		};
>> +
>> +		opp-600000000 {
>> +			opp-hz = /bits/ 64 <600000000>;
>> +			opp-microvolt = <875000 875000 1100000>;
>> +			clock-latency-ns = <40000>;
>> +		};
>> +
>> +		opp-816000000 {
>> +			opp-hz = /bits/ 64 <816000000>;
>> +			opp-microvolt = <875000 875000 1100000>;
>> +			clock-latency-ns = <40000>;
>> +		};
>> +
>> +		opp-1008000000 {
>> +			opp-hz = /bits/ 64 <1008000000>;
>> +			opp-microvolt = <875000 875000 1100000>;
>> +			clock-latency-ns = <40000>;
>> +		};
>> +
>> +		opp-1200000000 {
>> +			opp-hz = /bits/ 64 <1200000000>;
>> +			opp-microvolt = <900000 900000 1100000>;
>> +			clock-latency-ns = <40000>;
>> +		};
>> +
>> +		opp-1416000000 {
>> +			opp-hz = /bits/ 64 <1416000000>;
>> +			opp-microvolt = <925000 925000 1100000>;
>> +			clock-latency-ns = <40000>;
>> +		};
>> +
>> +		opp-1608000000 {
>> +			opp-hz = /bits/ 64 <1608000000>;
>> +			opp-microvolt = <975000 975000 1100000>;
>> +			clock-latency-ns = <40000>;
>> +		};
>> +
>> +		opp-1800000000 {
>> +			opp-hz = /bits/ 64 <1800000000>;
>> +			opp-microvolt = <1037500 1037500 1100000>;
>> +			clock-latency-ns = <40000>;
>> +		};
>> +
>> +		opp-2016000000 {
>> +			opp-hz = /bits/ 64 <2016000000>;
>> +			opp-microvolt = <1100000 1100000 1100000>;
>> +			clock-latency-ns = <40000>;
>>  		};
>>  	};
>>  
>>
> 
> 
> 
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ