linux-kernel - Re: [PATCH v4 6/6] arm64: dts: rockchip: Add OPP data for CPU cores on RK3588

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e220061e-0bb5-4fa4-9a91-aefd81e6636c@cherry.de>
Date: Wed, 8 May 2024 11:12:43 +0200
From: Quentin Schulz <quentin.schulz@...rry.de>
To: Alexey Charkov <alchark@...il.com>, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>
Cc: Daniel Lezcano <daniel.lezcano@...aro.org>,
 Dragan Simic <dsimic@...jaro.org>, Viresh Kumar <viresh.kumar@...aro.org>,
 Chen-Yu Tsai <wens@...nel.org>, Diederik de Haas <didi.debian@...ow.org>,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
 Kever Yang <kever.yang@...k-chips.com>
Subject: Re: [PATCH v4 6/6] arm64: dts: rockchip: Add OPP data for CPU cores
 on RK3588

Hi Alexey,

On 5/6/24 11:36 AM, Alexey Charkov wrote:
> By default the CPUs on RK3588 start up in a conservative performance
> mode. Add frequency and voltage mappings to the device tree to enable
> dynamic scaling via cpufreq.
> 
> OPP values are adapted from Radxa's downstream kernel for Rock 5B [1],
> stripping them down to the minimum frequency and voltage combinations
> as expected by the generic upstream cpufreq-dt driver, and also dropping
> those OPPs that don't differ in voltage but only in frequency (keeping
> the top frequency OPP in each case).
> 
> Note that this patch ignores voltage scaling for the CPU memory
> interface which the downstream kernel does through a custom cpufreq
> driver, and which is why the downstream version has two sets of voltage
> values for each OPP (the second one being meant for the memory
> interface supply regulator). This is done instead via regulator
> coupling between CPU and memory interface supplies on affected boards.
> 

I'm not sure this is everything we need though.

For the LITTLE cores cluster, all OPPs up to 1.416GHz are using the same 
opp-supported-hw, however the ones above, aren't.

1.608GHz, 1.704GHz and 1.8GHz are all using different opp-supported-hw.

Similarly, for the big cores clusters, all OPPs up to 1.608GHz are using 
the same opp-supported-hw, but not the ones above.

1.8GHz and 2.016GHz, 2.208GHz, 2.256GHz, 2.304GHz, 2.352GHz and 2.4GHz 
all have a different opp-supported-hw.

The values in that array are coming from cpu leakage (different for 
LITTLE, big0 and big1 clusters) and "specification serial number" 
(whatever that means), those are coming from the SoC OTP. In the 
downstream kernel from Rockchip, the former value is called "SoC 
Version" and the latter "Speed Grade".

I think this may have something to do with "binning" and I would see the 
ones above the "common" OPPs as "overclocking". Not all CPUs would 
support them and some may not run stable at some lower frequency than 
their stable max. Adding Kever from Rockchip in Cc to have some input on 
the need to support those.

Cheers,
Quentin