[PATCH v2 0/1] arm64: dts: rockchip: rk3528: Add CPU frequency scaling support

[PATCH v2 0/1] arm64: dts: rockchip: rk3528: Add CPU frequency scaling support

[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 5.10 kernel. 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.

The remaining 1416MHz to 2016MHz use a voltage close to actual frequency.

If we want the actual frequency to reach 2016MHz, the voltage
needs to reach 1.13V (+0.03V), not sure if it is safe.
The maximum opp-table voltage of downstream kernel is 1.1V.

Here are the test results using mhz [1] on Radxa E20C:

--------------------------------------
display frequency |  actual frequency
      408MHz      |       395MHz
      600MHz      |       593MHz
      816MHz      |       956MHz
     1008MHz      |      1152MHz
     1200MHz      |      1366MHz
     1416MHz      |      1430MHz
     1608MHz      |      1640MHz
     1800MHz      |      1802MHz
     2016MHz      |      1946MHz
--------------------------------------

[1] https://github.com/wtarreau/mhz.git

Chukun Pan (1):
  arm64: dts: rockchip: rk3528: Add CPU frequency scaling support

 arch/arm64/boot/dts/rockchip/rk3528.dtsi | 64 ++++++++++++++++++++++++
 1 file changed, 64 insertions(+)

Changed from v2:
  Rename label opp-table-0 to opp-table-cpu
  Adjust the voltage used for 408MHz to 1200MHz

-- 
2.25.1

[PATCH v2 1/1] arm64: dts: rockchip: rk3528: Add CPU frequency scaling support

[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.

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@jmu.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 {
+		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>;
 		};
 	};
 
-- 
2.25.1

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

[Heiko Stuebner]

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.

> 
> 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@jmu.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 {
> +		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>;
>  		};
>  	};
>  
> 

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

[Jonas Karlman]

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@jmu.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>;
>>  		};
>>  	};
>>  
>>
> 
> 
> 
> 

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

[Alexey Charkov]

On Thu, Jul 10, 2025 at 7:09 PM Jonas Karlman <jonas@kwiboo.se> wrote:
>
> 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.

It seems that PVTPLL usage shouldn't change the equation here. As long
as the voltage stays the same, it should always be preferable to run
the core faster (i.e. at a shorter osc-ring length) so that it can go
to idle sooner, given that idle states are less power-hungry than any
of the active states.

What DOES change the equation is the different voltage that downstream
DTs define for different OTP programmed leakage values, as they make
different top frequencies correspond to a given voltage for cores with
different leakage values.

> 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@jmu.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>;
> >> +            };

I.e. here the mainline kernel will always choose opp-1008000000 as
long as the regulator voltage is 875000 uV, unless explicitly
prevented from doing so by userspace. Whereas the BSP kernel [1] would
request different frequencies for different silicon, e.g.
opp-1200000000 for a silicon specimen with a leakage value of L4 and
opp-1416000000 for a silicon specimen with a leakage value of L8 - all
for the same regulator voltage of 875000 uV.

So my 2 cents would be: no added benefit in having "lower frequency,
same voltage" OPPs defined here until we implement an OPP driver
reading the NVMEM programmed leakage values and selecting different
*-L* voltages for each OPP depending on those. Once there is this
support in the drivers, those OPPs can be added together with
leakage-specific voltages (opp-microvolt-L0..11).

Right now OPP values with frequencies lower than 1008000000 won't be
selected by any of the energy-aware cpufreq governors anyway, because
their voltages are the same. Exercise for the reader: try to convince
e.g. the "schedutil" governor to select anything below 1008000000
without touching
/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq :) This may
change if OPP tuning logic is implemented such as in [2]: that will
try and find the _voltage_ resulting in PVTPLL providing a frequency
closest to what cpufreq requested, and use that for the in-memory OPP
table instead of what was provided by the DTS.

[1] https://github.com/rockchip-linux/kernel/blob/develop-5.10/arch/arm64/boot/dts/rockchip/rk3528.dtsi
[2] https://github.com/rockchip-linux/kernel/blob/develop-6.1/drivers/soc/rockchip/rockchip_opp_select.c#L842-L994

Best regards,
Alexey

> >> +            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>;
> >>              };
> >>      };
> >>
> >>
> >
> >
> >
> >
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

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

[Chukun Pan]

Hi,

> > 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.

Sorry, but soc.dtsi on rockchip doesn't seem to have dropped slower
frequencies with the same voltage?

rk3562.dtsi: CPU 408MHz -  816MHz 825mV | GPU 300MHz - 600MHz 825mV
rk3566.dtsi: CPU 408MHz -  816MHz 850mV | GPU 200MHz - 400MHz 850mV
rk3576.dtsi: CPU 408MHz - 1200MHz 700mV | GPU 300MHz - 600MHz 700mV

> I.e. here the mainline kernel will always choose opp-1008000000 as
> long as the regulator voltage is 875000 uV, unless explicitly
> prevented from doing so by userspace. Whereas the BSP kernel [1] would
> request different frequencies for different silicon, e.g.
> opp-1200000000 for a silicon specimen with a leakage value of L4 and
> opp-1416000000 for a silicon specimen with a leakage value of L8 - all
> for the same regulator voltage of 875000 uV.
>
> So my 2 cents would be: no added benefit in having "lower frequency,
> same voltage" OPPs defined here until we implement an OPP driver
> reading the NVMEM programmed leakage values and selecting different
> *-L* voltages for each OPP depending on those. Once there is this
> support in the drivers, those OPPs can be added together with
> leakage-specific voltages (opp-microvolt-L0..11).

I assume this has nothing to do with the NVMEM driver?

From [1], we can see that the voltage used by the same board from
408MHz to 1008MHz is the same. The actual test is also like this:

The first  board: CPU 408MHz - 1008MHz both 850mV | 1200MHz 862mV
The second board: CPU 408MHz - 1008MHz both 875mV | 1200MHz 875mV

[1] https://github.com/rockchip-linux/kernel/blob/develop-5.10/arch/arm64/boot/dts/rockchip/rk3528.dtsi#L227-L271

> Right now OPP values with frequencies lower than 1008000000 won't be
> selected by any of the energy-aware cpufreq governors anyway, because
> their voltages are the same. Exercise for the reader: try to convince
> e.g. the "schedutil" governor to select anything below 1008000000
> without touching
> /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq :) This may
> change if OPP tuning logic is implemented such as in [2]: that will
> try and find the _voltage_ resulting in PVTPLL providing a frequency
> closest to what cpufreq requested, and use that for the in-memory OPP
> table instead of what was provided by the DTS.

Thanks for the clarification, so should we remove 408MHz, 600MHz and
816MHz from the opp-table? Is this also the case with GPU's opp-table?

Thanks,
Chukun

--
2.25.1

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

[Alexey Charkov]

On Wed, Jul 16, 2025 at 6:30 PM Chukun Pan <amadeus@jmu.edu.cn> wrote:
>
> Hi,
>
> > > 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.
>
> Sorry, but soc.dtsi on rockchip doesn't seem to have dropped slower
> frequencies with the same voltage?
>
> rk3562.dtsi: CPU 408MHz -  816MHz 825mV | GPU 300MHz - 600MHz 825mV
> rk3566.dtsi: CPU 408MHz -  816MHz 850mV | GPU 200MHz - 400MHz 850mV
> rk3576.dtsi: CPU 408MHz - 1200MHz 700mV | GPU 300MHz - 600MHz 700mV

They were dropped for RK3588 when merging the CPU OPPs that I
submitted, after respective feedback from Daniel Lezcano [1]. GPU OPPs
for RK3588 were merged before that discussion, so they still carry
"lower frequency, same voltage" entries.

[1] https://lore.kernel.org/all/731aac66-f698-4a1e-b9ee-46a7f24ecae5@linaro.org/

> > I.e. here the mainline kernel will always choose opp-1008000000 as
> > long as the regulator voltage is 875000 uV, unless explicitly
> > prevented from doing so by userspace. Whereas the BSP kernel [1] would
> > request different frequencies for different silicon, e.g.
> > opp-1200000000 for a silicon specimen with a leakage value of L4 and
> > opp-1416000000 for a silicon specimen with a leakage value of L8 - all
> > for the same regulator voltage of 875000 uV.
> >
> > So my 2 cents would be: no added benefit in having "lower frequency,
> > same voltage" OPPs defined here until we implement an OPP driver
> > reading the NVMEM programmed leakage values and selecting different
> > *-L* voltages for each OPP depending on those. Once there is this
> > support in the drivers, those OPPs can be added together with
> > leakage-specific voltages (opp-microvolt-L0..11).
>
> I assume this has nothing to do with the NVMEM driver?

There is an OPP driver in BSP code (for v6 BSP kernels) or a custom
cpufreq driver (for v5 BSP kernels) which read factory determined
leakage values for the particular silicon specimen from an OTP (NVMEM)
cell and select different initial voltage values for each OPP based on
that. Those voltages come from opp-microvolt-L0..11 DT properties,
where -L0..11 represent different leakage values. Default is no -L*
suffix.

These are then further tuned in the BSP code by stepping over adjacent
regulator voltages until the PVTPLL provides a frequency closest to
what the OPP defines. The kernel then uses this calibrated voltage for
the particular OPP instead of the original DT provided one, as it
better suits the particular silicon specimen and operating conditions
(PVTPLL = process, voltage and temperature adjusting PLL).

The calibration process can result in varying voltages for PVTPLL
based OPPs, even if the DT listed the same voltage for each, so it
might make sense to list those once OPP calibration support gets
included in mainline driver code. Before then they won't be used by
any of the energy aware governors and would thus only add bloat.

> From [1], we can see that the voltage used by the same board from
> 408MHz to 1008MHz is the same. The actual test is also like this:
>
> The first  board: CPU 408MHz - 1008MHz both 850mV | 1200MHz 862mV
> The second board: CPU 408MHz - 1008MHz both 875mV | 1200MHz 875mV
>
> [1] https://github.com/rockchip-linux/kernel/blob/develop-5.10/arch/arm64/boot/dts/rockchip/rk3528.dtsi#L227-L271
>
> > Right now OPP values with frequencies lower than 1008000000 won't be
> > selected by any of the energy-aware cpufreq governors anyway, because
> > their voltages are the same. Exercise for the reader: try to convince
> > e.g. the "schedutil" governor to select anything below 1008000000
> > without touching
> > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq :) This may
> > change if OPP tuning logic is implemented such as in [2]: that will
> > try and find the _voltage_ resulting in PVTPLL providing a frequency
> > closest to what cpufreq requested, and use that for the in-memory OPP
> > table instead of what was provided by the DTS.
>
> Thanks for the clarification, so should we remove 408MHz, 600MHz and
> 816MHz from the opp-table? Is this also the case with GPU's opp-table?

I would say yes, drop for now and add them later when the need arises
(i.e. once we have driver support for OPP calibration using
PVTM/PVTPLL feedback).

They do not hurt per se, but they result in something unused right now
becoming part of the device tree ABI, thus limiting options to rethink
stuff later.

Best regards,
Alexey

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

[Chukun Pan]

Hi Jonas,

> 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.

Alexey suggested that we remove 408MHz, 600MHz and 816MHz from the
opp-table. Do you think it is acceptable to use 850mV for 1008MHz?

Thanks,
Chukun

--
2.25.1

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

[Alexey Charkov]

On Thu, Jul 17, 2025 at 11:01 AM Chukun Pan <amadeus@jmu.edu.cn> wrote:
>
> Hi Jonas,
>
> > 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.
>
> Alexey suggested that we remove 408MHz, 600MHz and 816MHz from the
> opp-table. Do you think it is acceptable to use 850mV for 1008MHz?

But why 850 mV? Vendor .dtsi [1] implies that chips with leakage
values of L0..L4 might be unstable at this frequency with a 850 mV
supply and need 875 mV instead.

As long as we don't read out OTP leakage values, we should pick a
voltage for each OPP that is sufficient for all possible chip
characteristics, meaning the maximum of all opp-microvolt* given in
each OPP. This will result in higher -L* chips burning more power than
they have to, but at least they will be stable.

[1] https://github.com/rockchip-linux/kernel/blob/792a7d4273a59e80dafca48ba11438f43a6d8bda/arch/arm64/boot/dts/rockchip/rk3528.dtsi#L268

Best regards,
Alexey

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

[Chukun Pan]

Hi,

> > Alexey suggested that we remove 408MHz, 600MHz and 816MHz from the
> > opp-table. Do you think it is acceptable to use 850mV for 1008MHz?
>
> But why 850 mV? Vendor .dtsi [1] implies that chips with leakage
> values of L0..L4 might be unstable at this frequency with a 850 mV
> supply and need 875 mV instead.

Because the actual frequency generated by 850mV is closer to 1008MHz.
Since we removed frequencies below 1GHz, all remaining frequencies are
generated by PVTPLL. I think it may not be necessary to use the maximum
values of opp-microvolt* ?

Thanks,
Chukun

--
2.25.1

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

[Alexey Charkov]

On Fri, Jul 18, 2025 at 6:01 PM Chukun Pan <amadeus@jmu.edu.cn> wrote:
>
> Hi,
>
> > > Alexey suggested that we remove 408MHz, 600MHz and 816MHz from the
> > > opp-table. Do you think it is acceptable to use 850mV for 1008MHz?
> >
> > But why 850 mV? Vendor .dtsi [1] implies that chips with leakage
> > values of L0..L4 might be unstable at this frequency with a 850 mV
> > supply and need 875 mV instead.
>
> Because the actual frequency generated by 850mV is closer to 1008MHz.

Which likely means that you have an -L5 chip. It will be different on
other chips - it's a lottery of silicon quality.

> Since we removed frequencies below 1GHz, all remaining frequencies are
> generated by PVTPLL. I think it may not be necessary to use the maximum
> values of opp-microvolt* ?

Only if we deliberately ignore the unlucky users who got lower quality
silicon (-L0 to -L4). They might have problems if we run 1008 MHz at
850 mV, which PVTPLL may or may not be able to make up for (depends on
which ring length gets applied for this frequency by bl31). If those
chips didn't need higher voltage to run stable at 1008 MHz then I
doubt Rockchip engineers would have put 875 mV in their .dtsi

Best regards,
Alexey

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

[Chukun Pan]

Hi,

> > Because the actual frequency generated by 850mV is closer to 1008MHz.
>
> Which likely means that you have an -L5 chip. It will be different on
> other chips - it's a lottery of silicon quality.

The rk3528 board I have has -L3 and -L5 levels.
-L3 level tested at 850mV (mainline kernel) actual frequency is 1055MHz.

Frankly speaking, I have always doubted whether the voltage value of BSP
is correct. The voltage of BSP kernel at 1800MHz and 2016MHz is too low,
and no board can reach the corresponding actual frequency.
For example, if we set the CPU frequency to 2016MHz when running the BSP
kernel, the actual frequency can only reach 1800MHz.

Thanks,
Chukun

--
2.25.1

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

[Willy Tarreau]

Hello,

On Sun, Jul 20, 2025 at 10:00:10PM +0800, Chukun Pan wrote:
> Hi,
> 
> > > Because the actual frequency generated by 850mV is closer to 1008MHz.
> >
> > Which likely means that you have an -L5 chip. It will be different on
> > other chips - it's a lottery of silicon quality.
> 
> The rk3528 board I have has -L3 and -L5 levels.
> -L3 level tested at 850mV (mainline kernel) actual frequency is 1055MHz.
> 
> Frankly speaking, I have always doubted whether the voltage value of BSP
> is correct. The voltage of BSP kernel at 1800MHz and 2016MHz is too low,
> and no board can reach the corresponding actual frequency.
> For example, if we set the CPU frequency to 2016MHz when running the BSP
> kernel, the actual frequency can only reach 1800MHz.

I've tried the patch on my E20C and am seeing a frequency drop compared
to cpufreq disabled (2016 MHz stock frequency). By default, without the
OPP, my CPU cores are showing the following frequencies:

  # ncpu=$(nproc);for ((i=0; i<ncpu;i ++)); do echo -n "$(taskset -c $i ./mhz -c -i) " ;done;echo
  2008 2011 2012 2010 

There's always the same distribution with core 0 being slightly lower,
then core 3, then 1 and 2, very likely due to leakage and PVTM adjustments.

In idle it's consuming 906 mW. After enabling the OPP, I've tried again
and this time I'm seeing this:

  # ncpu=$(nproc);for ((i=0; i<ncpu;i ++)); do echo -n "$(taskset -c $i ./mhz -c -i) " ;done;echo
  1891 1895 1894 1893 

It's missing ~120 MHz as if we were not using the correct multiples. The
power draw is also lower, at 864 mW.

I've tested each of the OPP in turn and measured the idle power consumption
and the effective frequency (measured on core 1):

    OPP     MHz    mW
   408000   394   795
   600000   593   797
   816000   908   800
  1008000  1100   801
  1200000  1306   808
  1416000  1372   812
  1608000  1576   818
  1800000  1744   836
  2016000  1896   856

It's interesting to note that 816, 1008 and 1200 MHz result in a higher
frequency than configured, but upper ones result in slightly smaller
frequencies (~2%, might just be a measurement error), particularly for
the last one which is 6% lower.

I noticed a missing entry for 2 GHz in clk-rk3528.c so I've added it,
expecting that it would solve the problem:

--- a/drivers/clk/rockchip/clk-rk3528.c
+++ b/drivers/clk/rockchip/clk-rk3528.c
@@ -25,6 +25,7 @@ enum rk3528_plls {
 };
 
 static struct rockchip_pll_rate_table rk3528_pll_rates[] = {
+       RK3036_PLL_RATE(2016000000, 1, 84, 1, 1, 1, 0),
        RK3036_PLL_RATE(1896000000, 1, 79, 1, 1, 1, 0),
        RK3036_PLL_RATE(1800000000, 1, 75, 1, 1, 1, 0),
        RK3036_PLL_RATE(1704000000, 1, 71, 1, 1, 1, 0),

But it had no effect at all, the frequency remains limited to 1896 MHz.

One thing I'm noticing is that with the OPP patches applied, my CPU
voltage measures 1.094V. Without it, it's 100mV above, at 1.194V. So
I tried to change the opp-microvolts in the DTS, setting them to 1.2V,
and I reverted the change above since it had no effect.

And indeed, this unlocked the upper OPP, but now the CPU is running at
2.1 GHz, and at 900mW idle:

  $ ncpu=$(nproc);for ((i=0; i<ncpu;i ++)); do echo -n "$(taskset -c $i ./mhz -c -i) " ;done;echo
  2091 2094 2094 2092 

So it's clear that something in the hardware is having fun with our
settings, and adjusting the frequency also based on the delivered
voltage.

I tried other voltages without changing the frequency and here's what 
I'm measuring (configured mhz, measured mhz, configured voltage,
measured voltage):

  Opp-MHz  MHz  Opp-mV  mV
   stock  2012  stock  1194
    2016  1896   1100  1094
    2016  1944   1125  1117
    2016  1998   1150  1144
    2016  2040   1175  1167
    2016  2094   1200  1194

At least the configured voltage is always respected. So I'm wondering
what's done in the stock settings. Maybe it's set to a higher voltage
to ensure stability even on low-quality bins, and configures a lower
frequency ? Applying a ratio above would indicate that the stock OPP at
1194 mV above is in fact 2012*2016/2094=1944 MHz. It indeed corresponds
to a multiple of 24 MHz.

And bingo, trying to set it in opp-hz gives me the stock frequency and
voltage on this device:

  2009 2012 2013 2011

So what should we conclude from this ? Is the 1.1V configured in the OPP
the official maximum ? If so, given that the E20C runs at 1.2V stock, how
can we be sure it will not fail on devices that work fine at 1.2V at stock
frequency and are not necessarily well tested at 1.1 ? Shouldn't we raise
the max voltage a little bit to match what vendors do ? Similarly, if we'd
set 1.2V with the 2016MHz OPP, it would result in a higher frequency on
some devices like mine, possibly resulting in instabilities on some
devices. On the other hand, the trouble caused by that PVTM stuff is also
the one that adjusts our frequency based on the voltage and requested one,
presumably in order to work reliably at that voltage.

Or maybe we could simply raise the voltage a little bit. The table above
shows that at 1.15V we're close to the configured OPP and still below the
stock voltage. This is not critical, but I find it a bit annoying that
enabling cpufreq results in lower performance than without!

Another observation is that I thought it was the boot loader that was
presetting the voltage and frequency, and that's not even the case: under
u-boot, I'm measuring 944mV. So it's just linux that sets it when booting.
Maybe it instead indicates that one voltage regulator driver's default
setting is a bit high for this chip and should not set the CPU voltage
to 1.2V, hence not make the device run at this frequency to start with ?

I can run more tests next weekend if needed.

Cheers,
Willy

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

[Chukun Pan]

Hi,

> It's interesting to note that 816, 1008 and 1200 MHz result in a higher
> frequency than configured, but upper ones result in slightly smaller
> frequencies (~2%, might just be a measurement error), particularly for
> the last one which is 6% lower.

Please refer to the description of this series:
https://lore.kernel.org/lkml/20250320100002.332720-1-amadeus@jmu.edu.cn/

During the discussion, it was considered that the minimum voltage should
be 875mV to maintain stability, so there is a deviation in the frequency
between 816MHz and 1200MHz.

> I noticed a missing entry for 2 GHz in clk-rk3528.c so I've added it,
> expecting that it would solve the problem:
>
> +       RK3036_PLL_RATE(2016000000, 1, 84, 1, 1, 1, 0),
>
> But it had no effect at all, the frequency remains limited to 1896 MHz.

There is a comment in the bsp kernel:
https://github.com/rockchip-linux/kernel/blob/develop-5.10/drivers/clk/rockchip/clk-rk3528.c#L101

Only 408MHz and 600MHz are generated by normal PLL, the rest of the
CPU frequency is controlled by TF-A via SCMI.

> Or maybe we could simply raise the voltage a little bit. The table above
> shows that at 1.15V we're close to the configured OPP and still below the
> stock voltage. This is not critical, but I find it a bit annoying that
> enabling cpufreq results in lower performance than without!

I also mentioned this in the cover letter. The actual frequency of 2016MHz
requires 1.13V ~ 1.15V. Not sure if this is safe for the rk3528 SoC.

Thanks,
Chukun

--
2.25.1

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

[Willy Tarreau]

Hi!

On Wed, Jul 30, 2025 at 03:00:26PM +0800, Chukun Pan wrote:
> Hi,
> 
> > It's interesting to note that 816, 1008 and 1200 MHz result in a higher
> > frequency than configured, but upper ones result in slightly smaller
> > frequencies (~2%, might just be a measurement error), particularly for
> > the last one which is 6% lower.
> 
> Please refer to the description of this series:
> https://lore.kernel.org/lkml/20250320100002.332720-1-amadeus@jmu.edu.cn/

Yes I had read this one. I'm just getting higher differences on my
device here.

> During the discussion, it was considered that the minimum voltage should
> be 875mV to maintain stability, so there is a deviation in the frequency
> between 816MHz and 1200MHz.

I tend to agree, especially on low voltages, where the gain in stability
is important while the difference in consumptionis barely noticeable.

> > I noticed a missing entry for 2 GHz in clk-rk3528.c so I've added it,
> > expecting that it would solve the problem:
> >
> > +       RK3036_PLL_RATE(2016000000, 1, 84, 1, 1, 1, 0),
> >
> > But it had no effect at all, the frequency remains limited to 1896 MHz.
> 
> There is a comment in the bsp kernel:
> https://github.com/rockchip-linux/kernel/blob/develop-5.10/drivers/clk/rockchip/clk-rk3528.c#L101
> 
> Only 408MHz and 600MHz are generated by normal PLL, the rest of the
> CPU frequency is controlled by TF-A via SCMI.

OK!

> > Or maybe we could simply raise the voltage a little bit. The table above
> > shows that at 1.15V we're close to the configured OPP and still below the
> > stock voltage. This is not critical, but I find it a bit annoying that
> > enabling cpufreq results in lower performance than without!
> 
> I also mentioned this in the cover letter. The actual frequency of 2016MHz
> requires 1.13V ~ 1.15V. Not sure if this is safe for the rk3528 SoC.

My point is that if you disable cpufreq, the CPU is running at 1.2V, which
is even higher. I don't know why it's running at this voltage, maybe as
the result of initializing some regulators, but that's what we're getting.
So the question about safety of running between 1.13-1.15 resolves to
"it's at least safer than running without cpufreq" in the current state.

And as I mentioned it's clearly linux and not u-boot that is setting 1.2V,
because under u-boot and during kernel selection and image loading, my
board is at 0.95V. It's only once the kernel starts to boot that it bumps
to 1.2V.

So there's something to fix somewhere, either by lowering the default
setting or by increasing the voltages in OPP, but as it is right now the
situation is inconsistent.

Regards,
Willy

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

[Chukun Pan]

Hi,

> My point is that if you disable cpufreq, the CPU is running at 1.2V, which
> is even higher. I don't know why it's running at this voltage, maybe as
> the result of initializing some regulators, but that's what we're getting.
> So the question about safety of running between 1.13-1.15 resolves to
> "it's at least safer than running without cpufreq" in the current state.
>
> And as I mentioned it's clearly linux and not u-boot that is setting 1.2V,
> because under u-boot and during kernel selection and image loading, my
> board is at 0.95V. It's only once the kernel starts to boot that it bumps
> to 1.2V.

If opp-table is not configured, kernel will initialize the pwm-regulator
to maximum microvolts. This can be solved by configuring the pwm-regulator
in U-Boot (waiting for U-Boot to synchronize the DT of kernel 6.16):

```
&vdd_arm {
	regulator-init-microvolt = <953000>;
};

&vdd_logic {
	regulator-init-microvolt = <900000>;
};
```

Thanks,
Chukun

--
2.25.1

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

[Willy Tarreau]

Hi,

On Wed, Jul 30, 2025 at 09:20:26PM +0800, Chukun Pan wrote:
> Hi,
> 
> > My point is that if you disable cpufreq, the CPU is running at 1.2V, which
> > is even higher. I don't know why it's running at this voltage, maybe as
> > the result of initializing some regulators, but that's what we're getting.
> > So the question about safety of running between 1.13-1.15 resolves to
> > "it's at least safer than running without cpufreq" in the current state.
> >
> > And as I mentioned it's clearly linux and not u-boot that is setting 1.2V,
> > because under u-boot and during kernel selection and image loading, my
> > board is at 0.95V. It's only once the kernel starts to boot that it bumps
> > to 1.2V.
> 
> If opp-table is not configured, kernel will initialize the pwm-regulator
> to maximum microvolts. This can be solved by configuring the pwm-regulator
> in U-Boot (waiting for U-Boot to synchronize the DT of kernel 6.16):
> 
> ```
> &vdd_arm {
> 	regulator-init-microvolt = <953000>;
> };

OK thanks for the explanation, but will be stable at highest frequency, or
do we expect the TF-A or PVTM mechanism to automatically reduce the
frequency enough to keep everything stable ? I'm asking because right now
I'm booting at 2 GHz, and I don't imagine 2 GHz to work fine at 953mV.

Also, if we'd set this to a low enough voltage that it results in throttling
the CPU, it could significantly slow down the boot for no reason. If we
consider that the configured max-microvolt is valid, then better continue
to use it. And if it's not valid, then maybe just fix it without going
full throttle to a lower value either. Just my two cents.

Willy