Temperature sensor and CPU freq scaling broken in 4.9.x and 4.10.x kernels for RPi3/aarch64

[graysky2]

I'm using a RPi3 booted into either Arch ARM's armv8/aarch64 kernel (4.10.5 currently) or openSUSE-Tumbleweed's aarch64 kernel (4.9.6) and neither allows me to read the CPU temperature or query the CPU frequency/adjust it. If I boot into openSUSE-Leap42.2 which runs the older 4.4.49 aarch64 kernel, both temperature and cpu frequency are visible. I am unsure how to troubleshoot further.

Under Leap42.2 (4.4.49):

# lscpu
Architecture:          aarch64

# cat /sys/devices/virtual/thermal/thermal_zone0/temp
42932

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

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand

Under Arch ARM (4.10.5) or Tumbleweed (4.9.6):

# lscpu
Architecture:          aarch64

# cat /sys/devices/virtual/thermal/thermal_zone0/temp
cat: /sys/devices/virtual/thermal/thermal_zone0/temp: No such file or directory

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
cat: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory

[Electron752]

I don't know which tree those kernels are built on or if they are even based on this tree at all.

I know Eric Annolt has been working on an upstream CPU temperature driver. I understand it's been getting a bad wrap due to DT nodes and such. Perhaps you should contact him so that they can use the upstream drivers once they are ready.

Or perhaps contact whoever you got the kernel from.

[graysky2]

I do not know about the openSUSE kernels but the Arch ARM kernel is build off upstream's 4.10.5 kernel... I thought I understood that much of the code in this repo was merged upstream (#1915). Is this incorrect?

[Electron752]

Almost all of it is. The temperature driver is one of last pieces that need to go upstream. Like I said, Eric Annolt has been workings on an upstream version because the version here is still firmware based and doesn't really fit well in with the DT node structure that upstream requires.

[graysky2]

That's good to hear. Does eric have a github account? Do an @eric's_handle to get him to see this.

[PeterPablo]

@anholt, for your information. Am 26.03.2017 13:58 schrieb "graysky" <notifications@github.com>: That's good to hear. Does eric have a github account? Do an @eric <https://github.com/eric>'s_handle to get him to see this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1918 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEI6K5IBBHW00AUcaJB2yTQLUxHib07Qks5rplMCgaJpZM4MpYYX> .

[graysky2]

Thanks, Peter. So that might explain the temperature sensor, but what about the cpu freq control and missing governor?

[lategoodbye]

Currently there is no thermal (not merged yet) or CPU frequency (no plans AFAIK) driver for bcm2835 in Linux mainline. Please report those issues / feature wishes to your distribution.

[eric]

Wrong eric.

[graysky2]

I guess the best next step would be to identify some openSUSE developers/packagers to answer the question @Electron752 posed:

I don't know which tree those kernels are built on or if they are even based on this tree at all.

[JamesH65]

This appears unrelated to the Raspberry Pi kernel, so closing.

[dblueman]

Just of note here, I still find no cpufreq scaling with Linux 4.16.0 aarch64.

In aarch64 mode, adding 'force_turbo=1' to /boot/firmware/config.txt gives the same performance as the Raspbian armv7 OS with the performance governor (actually 4% faster in my Fortran N-Queens benchmark); I am running with a larger heatsink to prevent hitting the thermal envelope limits.

[dblueman]

Forgot to mention, without 'force_turbo=1', we see ~50% performance.

[pelwell]

Are you using a downstream (rpi-4.16.y) branch or a pure upstream tree?

[dblueman]

I'm using pure upstream (kernel.org) 4.16.0.