linux-kernel - Re: [PATCH 1/1] arm64: dts: rockchip: rk3528: Add CPU frequency scaling support

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] [day] [month] [year] [list]
Message-ID: <bcedff66-26e4-4630-88cd-6ab9fbcf5598@kwiboo.se>
Date: Sun, 23 Mar 2025 22:49:04 +0100
From: Jonas Karlman <jonas@...boo.se>
To: Chukun Pan <amadeus@....edu.cn>, Heiko Stuebner <heiko@...ech.de>,
 Dragan Simic <dsimic@...jaro.org>
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
Subject: Re: [PATCH 1/1] arm64: dts: rockchip: rk3528: Add CPU frequency
 scaling support

Hi Chukun,

On 2025-03-20 11:00, Chukun Pan wrote:
> 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], and voltage is chosen from
> the one that makes the actual frequency close to the displayed 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 621fc19ac0b3..9dae18c3c770 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3528.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3528.dtsi
> @@ -61,6 +61,7 @@ cpu0: cpu@0 {
>  			device_type = "cpu";
>  			enable-method = "psci";
>  			clocks = <&scmi_clk SCMI_CLK_CPU>;
> +			operating-points-v2 = <&cpu0_opp_table>;
>  		};
>  
>  		cpu1: cpu@1 {
> @@ -69,6 +70,7 @@ cpu1: cpu@1 {
>  			device_type = "cpu";
>  			enable-method = "psci";
>  			clocks = <&scmi_clk SCMI_CLK_CPU>;
> +			operating-points-v2 = <&cpu0_opp_table>;
>  		};
>  
>  		cpu2: cpu@2 {
> @@ -77,6 +79,7 @@ cpu2: cpu@2 {
>  			device_type = "cpu";
>  			enable-method = "psci";
>  			clocks = <&scmi_clk SCMI_CLK_CPU>;
> +			operating-points-v2 = <&cpu0_opp_table>;
>  		};
>  
>  		cpu3: cpu@3 {
> @@ -85,6 +88,7 @@ cpu3: cpu@3 {
>  			device_type = "cpu";
>  			enable-method = "psci";
>  			clocks = <&scmi_clk SCMI_CLK_CPU>;
> +			operating-points-v2 = <&cpu0_opp_table>;
>  		};
>  	};
>  
> @@ -103,6 +107,66 @@ scmi_clk: protocol@14 {
>  		};
>  	};
>  
> +	cpu0_opp_table: opp-table-0 {

nitpick:

There is only one cpu cluster on this SoC, I suggest we name this node
opp-table-cpu with a cpu_opp_table label.

For a forthcoming GPU series I named the node opp-table-gpu with a
gpu_opp_table label.

> +		compatible = "operating-points-v2";
> +		opp-shared;
> +
> +		opp-408000000 {
> +			opp-hz = /bits/ 64 <408000000>;
> +			opp-microvolt = <825000 825000 1100000>;
> +			clock-latency-ns = <40000>;
> +			opp-suspend;
> +		};
> +
> +		opp-600000000 {
> +			opp-hz = /bits/ 64 <600000000>;
> +			opp-microvolt = <825000 825000 1100000>;
> +			clock-latency-ns = <40000>;
> +		};

Both 408 and 600 MHz freq will use a normal PLL and based on the vendor
opp-table there are chip variants that presumably require 875000
microvolt.

Because of this 875000 is the lowest microvolt we should use in the
entire table, to ensure all chip variants can run stable.

Dragan is working on a chip binning project to help improve opp voltage
selection based on chip quality. Hopefully that project will result in
something that can also be used for RK3528 in the future.

> +
> +		opp-816000000 {
> +			opp-hz = /bits/ 64 <816000000>;
> +			opp-microvolt = <825000 825000 1100000>;
> +			clock-latency-ns = <40000>;
> +		};
> +
> +		opp-1008000000 {
> +			opp-hz = /bits/ 64 <1008000000>;
> +			opp-microvolt = <850000 850000 1100000>;
> +			clock-latency-ns = <40000>;
> +		};
> +
> +		opp-1200000000 {
> +			opp-hz = /bits/ 64 <1200000000>;
> +			opp-microvolt = <850000 850000 1100000>;

For remaining freq TF-A will use PVTPLL and configure an osc ring length,
then the voltage supplied in opp and chip quality will determine/limit
the real cpu clock speed.

This means that the voltage used is less important when it comes to
stability. However, we should keep 875000 as the lowest microvolt for
all opp above.

The voltage for remaining opp does not matter, historically mainline
picks the highest voltage from vendor tree to ensure stability. With the
use of PVTPLL that should not really be an issue, and we could pick
voltages that will give closest speed for majority of users.

> +			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>;

This looks good, we should not go above the highest voltage used in
vendor tree.

A DT overlay can be used if a user wants to use board optimized voltages.

Regards,
Jonas

> +			clock-latency-ns = <40000>;
> +		};
> +	};
> +
>  	psci {
>  		compatible = "arm,psci-1.0", "arm,psci-0.2";
>  		method = "smc";