Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this page for instructions on how to get full permissions. Sorry for the inconvenience.
I noticed that cpufreq almost never gets the cpu into lower frequency states (even when idle). Do you consider this related or should we use a different issue.
The solution (workaround) here will involve Linux and ATF. To update here what I plan to do (sometime until the 25th of june hopefully): Test the latest upstream RFC patches that are being discussed. Prepared the forks/branches:
Also, I created the Librem5/trusted-firmware-a repo for us to use and put possible out-of-tree changes in (librem5 branch).
Up until now it's not clear that cpuidle on imx8mq will be supported by mainline linux. That shouldn't be a big deal, at least as long as it's actively discussed ( https://lists.infradead.org/pipermail/linux-arm-kernel/2019-June/658494.html ). Worst case will be that any serious imx8mq user will need an out-of-tree change anyways.
Worst case will be that any serious imx8mq user will need an out-of-tree change anyways.
Which would be pretty bad since lots of people expect to run mainline. We should join the upstream discussion once we know if there's a reliable way to wake up (which doesn't seem to be clear yet).
I'm happy for hints for how to better test here! I look at interrupts and what powertop says, but powertop doesn't really work for arm and I'm not even sure if we are supposed to see real "CPU wake" interrupts with Abel's workarounds.
So there's one solution posted by Abel from March, and one from June. The older one I have "tested" too, but that's not pushed into my trees. But what I notice is the same for both versions:
of course, "powertop" then has a cpuidle driver and tries to tell "WFI" stats: cpu-sleep: 0%, WFI: 99+%. But again, I'm not sure if that is accurate... temperature recording don't really show a difference.
the heating-curve of the workaround:
looks exactly the same as without it:
(30s units on the x axis, different amount of samples, the details don't matter)
So to the code path: arch/arm64/kernel/process.c's cpu_do_idle() is called constantly:
With the workaround ca. once every 1ms
Without it ca. every 100us
And we use __cpu_do_idle() which goes straight to the "wait for interrupt" assembler instruction.
Without the workaround, is the WFI call simply not implemented and just returns?
So while we don't see any difference, and even more interrupts (arch_timer, see above), can it be that this workaround actually does what it should do but we simply constantly interrupt all cpus (due to other bugs or missing things)?
Appearently, Anson is still working on this, and TIMER_IMX_SYS_CTR needs to be configured-in see https://lkml.org/lkml/2019/6/21/55 plus the necessary support added, see https://lkml.org/lkml/2019/6/21/103 But simply grabbing these, I don't have a cooler SoC yet, but there might be (a clock definition?) missing still...
We won't see a difference in the heating-curve (according to Abel, see https://lkml.org/lkml/2019/6/28/237 ). What I tried to do now (don't laugh :) this should be more of a side-note): is to use powertop on my Laptop, with the devkit connected, and compare power-consumption -.-:
I do see a slight difference (but really, these are still not hard numbers you can read anything into): with the workaround I increase ca. 4,4 W. Without it (using our Librem5/linux-next, consumption increases ca. 5,1 W. Although I did a few iterations, there were iterations in when I also saw ca. 5 W increase with the workaround. But on average, it seems to consume less power, if I can trust my battery and all.
I asked Abel about "arch_timer" and showed him our idlestat numbers; I hope he can quickly confirm that this makes sense to him.
but "cpu-sleep" is never used, see idlestat output above. Actually, it is, but only during startup, about up until DCSS/DRM loading:
[ 0.922674] dcss-core 32e00000.dcss: dcss_submodules_init 178.: ret: 0 [ 0.923621] cpu_pm_enter [ 0.923638] cpu_pm_enter [ 0.923643] cpu_pm_enter return val: 0 [ 0.923646] arm_cpuidle_suspend index 1 cpu 1 [ 0.929480] cpu_pm_enter return val: 0 [ 0.929483] arm_cpuidle_suspend index 1 cpu 2 [ 0.929531] Registering platform device 'imx-dcss-crtc.0'. Parent at 32e000000.dcss [ 0.929535] device: 'imx-dcss-crtc.0': device_add [ 0.929546] bus: 'platform': add device imx-dcss-crtc.0 [ 0.929573] PM: Adding info for platform:imx-dcss-crtc.0
The irq-imx-gpcv2 driver is loaded correctly.
(only until ca. that point during startup) arch/arm64/kernel/cpuidle.c's
arm_cpuidle_suspend() is called via kernel/cpu_pm.c's cpu_pm_enter(). Never again afterwards.
My guess right now would be that we mess things up somewhere in our out-of-tree (drm) changes.
given that we don't even have busfreq and the dcss driver will look totally different in mainline anyway (it's basically the last part of the display stack we copied mostly verbatim from nxp) it'd say it's o.k. to disable.