Hello Quentin,
On 2024-05-08 11:12, Quentin Schulz wrote:
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.
Good point. We should remove the OPPs for both clusters that aren't
supported by all RK3588(s) binnings, to be on the safe side.
I'll hopefully dive into supporting different Rockchip binnings rather
soon. There's even more about that, and not just with the RK3588(s),
which I think I'll get all covered.
