pftf
CPPC support
Given a thermal zone, it would be helpful if the OS can adjust, or at a minimum read, the passive power states sufficiently to report the current cpu clock freq. Frankly, I'm not sure how to wedge this into the RPI at the moment, but its worth considering.
[root@rpi4-f33 linux]# cpupower frequency-info
analyzing CPU 0:
driver: cppc_cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3
CPUs which need to have their frequency coordinated by software: 0 1 2 3
maximum transition latency: Cannot determine or is not supported.
hardware limits: 600 MHz - 1.50 GHz
available cpufreq governors: conservative ondemand userspace powersave performance schedutil
current policy: frequency should be within 600 MHz and 1.50 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency: 0.97 GHz (asserted by call to hardware)
Turns out, I've implemented a lot of uneeded code, and in the process found a heaping pile of linux bugs.
So, there is a really easy way to do this that doesn't involve a lot of complex PCC channel mailbox handshaking/etc. The rpi4 has some (apparently?) unused mailboxes that can carry values in them. Tied directly as a Register(SystemMemory,,,,) to the requested cpu freq, and some adjustments to atf+_PSD(), etc and bam. 4 core locked frequencies under control of the linux cpufreq governor.
Final line count is trivial, couple lines in atf, couple lines in AML, a a few lines of linux bugfixes.
So I have "turbo" working, as well as tweaked the current cpu frequency logic so that it works in linux. In both those cases there are issues in the linux kernel around CPPC support. Actually there are three primary issues with linux's CPPC, 1: HW_ALL is not supported, 2: the error handling in ReferencePerformaceCounterRegister/DeliveredPerformaceCounterRegister results in a lot of those ".97Ghz" reports as seen above. 3: basically the turbo/boost logic is busted in any case that doesn't have the hardware boosting over the DesiredPerformaceRegister requests on its own.
A couple weeks ago, I re-enabled the PCC channel for the APERF/RPERF registers. This "fixes" the hardware reported counters linux uses to estimate the current frequency. Since the patches are a little stale, I will link them here:
https://github.com/jlinton/arm-trusted-firmware (branch rpi4 cppc) and https://github.com/jlinton/edk2-platforms (branch rpi_fix_temp)
For those patches to work properly the config.txt needs the arm_freq set at 1700 (and likely the voltage setting as well).
Thats because they patches have hardcoded the arm frequencies in the AML, 600->1500 is the normal frequency range, with 1700 set as the max turbo. With the linux CPPC code the kernel will never request anything over 1500 unless "boost" is set in sysfs/cpupower.
The two remaining work items are getting the ATF bits merged, and fixing those hardcoded frequency ranges. Given that i'm using the DTB address for the PCC channel that might raise some eyebrows and require a more formal memory region as well.