linux-kernel - Re: [PATCH v2 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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250716143016.620430-1-amadeus@jmu.edu.cn>
Date: Wed, 16 Jul 2025 22:30:16 +0800
From: Chukun Pan <amadeus@....edu.cn>
To: alchark@...il.com
Cc: amadeus@....edu.cn,
	conor+dt@...nel.org,
	devicetree@...r.kernel.org,
	heiko@...ech.de,
	jonas@...boo.se,
	krzk+dt@...nel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	linux-rockchip@...ts.infradead.org,
	ziyao@...root.org
Subject: Re: [PATCH v2 1/1] arm64: dts: rockchip: rk3528: Add CPU frequency scaling support

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