no freq scaling on archlinuxarm's kernel 5.4

[zertyz]

Hello.

I'm here to report that the new 5.4.? kernels (ArchLinux version) don't allow the CPU & friends to scale up either on rPi 1 and rPi 2.

On rPi2 the issue is silent, but on rPi1, I get the following on dmesg, early on boot:

[ 9.512249] WARNING: CPU: 0 PID: 1 at drivers/cpufreq/cpufreq-dt.c:69 find_supply_name+0x84/0xa0
[ 9.517444] Modules linked in:
(...)
-- currently I am on 5.4.42-1-ARCH, but this also happened on 5.4.40.

and the rPi1 stays at:
[root@PinkPi ~]# /opt/vc/bin/vcgencmd measure_clock core
frequency(1)=250000000
[root@PinkPi ~]# /opt/vc/bin/vcgencmd measure_clock arm
frequency(48)=700074000

no metter what is the load -- despite my config.txt is:

# maximum turbo for rPi1
arm_freq=1000
gpu_freq=500
sdram_freq=600
over_voltage=6
over_voltage_sdram=6
initial_turbo=60

NOTE: this config works fine on kernels 4.19.x on rPi1 (and a similar one also works on rPi2).

I'll attach the relevant files for rPi1.

[zertyz]

dmesg.txt
config.gz

[Titaniumtown]

(Kinda plugging my own repo here)
I have builds for all kernel branches on my repo (for raspberry pi 4 aarch64), I build whenever a new commit is pushed, can you reproduce the same issue on those versions too and on a raspberry pi 4 (if you have one)? (btw, the packages name are linux-raspberrypi4-4.19.y for 4.19, linux-raspberrypi4-5.4.y for 5.4, etc)

My repo:
[raspi_aarch64]
SigLevel = Optional TrustAll
Server = http://www.gardling.com/my_repo/aarch64

[popcornmix]

Arch build their own kernels with different config options so you really should report issues there.
If you see the same issue with raspbian and 5.4 kernel (available from rpi-update) then let us know and we'll investigate.

On raspbian for me:

pi@pi2:~ $ uname -a
Linux domnfs 5.4.42-v7+ #1319 SMP Wed May 20 14:06:11 BST 2020 armv7l GNU/Linux
pi@pi2:~ $ vcgencmd measure_clock arm
frequency(48)=600000000
pi@pi2:~ $ vcgencmd measure_clock arm
frequency(48)=900000000

I'm seeing the arm bump up and down in frequency.

[gearhead]

Can we get a bit of guidance, here? I'm building my kernel locally and want to be able to build one that scales, properly. I did some comparison between the Raspbian and Arch kernel configs and saw this as a difference:

Arch Config                             Rpi official
CONFIG_CPU_FREQ=y                       CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_ATTR_SET=y          CONFIG_CPU_FREQ_GOV_ATTR_SET=y
CONFIG_CPU_FREQ_GOV_COMMON=y            CONFIG_CPU_FREQ_GOV_COMMON=y
CONFIG_CPU_FREQ_STAT=y                  CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMA  # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMA
NCE is not set                          NCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAV  CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE=
E is not set                            y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPAC  # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPAC
E is not set                            E is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y  # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
                                         is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVA  # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVA
TIVE is not set                         TIVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTI
L is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y       CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y         CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y         CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y          CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y      CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y

#                                       #
# CPU frequency scaling drivers         # CPU frequency scaling drivers
#                                       #
CONFIG_CPUFREQ_DT=y                     # CONFIG_CPUFREQ_DT is not set
CONFIG_CPUFREQ_DT_PLATDEV=y
# CONFIG_ARM_BIG_LITTLE_CPUFREQ is not  # CONFIG_ARM_RASPBERRYPI_CPUFREQ is no
 set                                    t set
CONFIG_ARM_RASPBERRYPI_CPUFREQ=y
CONFIG_ARM_BCM2835_CPUFREQ=y            CONFIG_ARM_BCM2835_CPUFREQ=y
# CONFIG_QORIQ_CPUFREQ is not set       # CONFIG_QORIQ_CPUFREQ is not set
# end of CPU Frequency scaling          # end of CPU Frequency scaling

I re-built it with 2 changes and no longer get the dmesg error, but want to know what these flags do.
CONFIG_CPUFREQ_DT and CONFIG_CPUFREQ_DT_PLATDEV and if these are what could be causing the error at boot and the failure to scale.

[Titaniumtown]

With my kernel builds sometimes it gets stuck at 666mhz and never goes up, and I have to reboot it. I even tried setting it to performance mode manually.

[popcornmix]

Have a look at: #3604
Basically if you enable CONFIG_CPUFREQ_DT then you also need a device tree node.
One without the other is not going to work.

[pelwell]

It would help to know which platforms you are building for, as the RPi defconfigs differ in their cpufreq handling,

[Titaniumtown]

In my case, raspberry pi 4.

[gearhead]

For me, I am building for armv6l, armv7l and aarch64. All on Arch Linux. I noted the dmesg notification at boot for the armv6l and hoped it would be resolved at some point by the Arch Kernel maintainers, but it has not yet, so I am trying to figure it out. @popcornmix Do you have any idea why we get the notification and any instruction on how we can resolve it? I get that this is not 'official RPi' stuff, but it has worked in the past on Arch Arm and I just want to get it back working.

It looks like Arch_Arm enables CONFIG_ARM_RASPBERRYPI_CPUFREQ whereas the official RPI kernel does not. Does this conflict with CONFIG_ARM_BCM2835_CPUFREQ?
The error, though, mentions cpufreq-dt.c:69 which leads me to look at the CPUFREQ_DT configs? CONFIG_CPUFREQ_DT and CONFIG_CPUFREQ_DT_PLATDEV are enabled by Arch but RPi does not. I can shotgun this, but was asking here for guidance in case someone here has a better understanding of what is going on.

[popcornmix]

Sorry, this really needs to be asked at arch linux. We provide a set of device config files and device trees that work on a range of Pi's using raspbian. You can easily break things by changing them.

The WARN you have from cpufreq-dt.c looks like there is a missing device tree node, and as I linked to earlier if you add CONFIG_CPUFREQ_DT config option you need to add a corresponding DT node (but I don't even know how or if Arch are modifying DT).

If you just want your own self-built kernels to work, then making the CPUFREQ config options map ours is probably the easiest solution. If you want Arch kernels to work in the future you should be talking to their devs,

[gearhead]

@popcornmix Thanks. I spent a bit of time and rebuilt the latest? kernel (5.4.58) with the official RPi config for armv6 and it works as expected. I also took the RPI config and only changed this bit and get the error. Can you point out which of these config options break the cpu scaling for armv6? Arch uses the same config for both armv6 and armv7 and there is not a problem with cpu freq scaling (nor is there an error message at boot) on armv7.
(edit) there are no modofications to any of the DT files. The make command we use is:
make ${MAKEFLAGS} zImage modules dtbs and there is nothing defined for the MAKEFLAGS variable
This is the only bit that is changed between the config generated for the armv6 kernel:

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_ATTR_SET=y
CONFIG_CPU_FREQ_GOV_COMMON=y
CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y

#
# CPU frequency scaling drivers
#
CONFIG_CPUFREQ_DT=y
CONFIG_CPUFREQ_DT_PLATDEV=y
# CONFIG_ARM_BIG_LITTLE_CPUFREQ is not set
CONFIG_ARM_RASPBERRYPI_CPUFREQ=y
CONFIG_ARM_BCM2835_CPUFREQ=y
# CONFIG_QORIQ_CPUFREQ is not set
# end of CPU Frequency scaling

[popcornmix]

I'll repeat my earlier comment:

Have a look at: #3604
Basically if you enable CONFIG_CPUFREQ_DT then you also need a device tree node.
One without the other is not going to work.

[popcornmix]

I had a look at this. The DT issue you see in log seems to be a missing cpus node.
Removing this line:

linux/arch/arm/boot/dts/bcm2708.dtsi

Line 5 in 423495b

/delete-node/ cpus;

avoids this.
@pelwell see:

linux/drivers/cpufreq/cpufreq-dt.c

Line 66 in 423495b

np = of_node_get(dev->of_node);

- is not deleting the cpus node okay?

It still doesn't work as due to limits in clocks/plls on pi4 the kernel cpufreq driver only allows a limited set of frequencies (integer divisors of the initial pll - typically twice arm_clock) which means both arm_freq_min (700) and arm_freq (say, 1000) get forced to the same 1000MH value.

Reverting f44019c does seem to make CONFIG_CPUFREQ_DT work on a Pi1.

There is work in progress to remove the clock/pll limit on Pi4 which should mean that revert can be done soon to the main kernel tree.

[pelwell]

With no config changes, restoring the cpus node doesn't seem to have any effect.

Reverting f44019c and changing the config to match the other platforms like this:

diff --git a/arch/arm/configs/bcmrpi_defconfig b/arch/arm/configs/bcmrpi_defconfig
index 8e157f06a9f4..e6dd3d96cf39 100644
--- a/arch/arm/configs/bcmrpi_defconfig
+++ b/arch/arm/configs/bcmrpi_defconfig
@@ -46,6 +46,9 @@ CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
 CONFIG_CPU_FREQ_GOV_USERSPACE=y
 CONFIG_CPU_FREQ_GOV_ONDEMAND=y
 CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
+CONFIG_CPUFREQ_DT=y
+CONFIG_ARM_RASPBERRYPI_CPUFREQ=y
+# CONFIG_ARM_BCM2835_CPUFREQ is not set
 CONFIG_VFP=y
 # CONFIG_SUSPEND is not set
 CONFIG_PM=y

seemed to work as well.

I'll merge the DT change now, then we can patch up the config when the other issues are fixed.

[pelwell]

See a5c01be.

[popcornmix]

Latest rpi-update kernel uses CONFIG_CPUFREQ_DT on Pi1.
If Arch updates to latest kernel tree then I suspect this issue will be resolved.

[gearhead]

@popcornmix Thanks for looking into this!

[gearhead]

Looke like it is 'fixed. Thanks! I used the latest commit: 0be0e08 and built using the current Arch config and it builds. At boot, the error is no longer present. If I set the governor to 'ondemand' then check:

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
700000

Make the Pi do something then check again:

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1000000

Woo Hoo!

[popcornmix]

@zertyz are you happy with this now? Feel free to close if you are.