R7500v2 kernel 4.19 test

umm, the comment at the top of linux-4.19.53/drivers/cpuidle/cpuidle-arm.c says this file is the driver, and it is present. However,

root@OpenWrt:~# cat /sys/devices/system/cpu/cpuidle/current_driver 
none

and from my build log:

*
* ARM CPU Idle Drivers
*
Generic ARM/ARM64 CPU idle Driver (ARM_CPUIDLE) [N/y/?] (NEW)  

which looks like it didn't get selected.

EDIT: but that's no different than my last 4.14 compile and I don't know what current_driver gives for 4.14 so I'm back to clueless

from more research i think that cpuidle-qcom got ""meged"" to cpuidle-arm

can you test if cpuidle worked in 4.14? (if cat /sys/devices/system/cpu/cpuidle/current_driver gives different output... )

sure, but the router is in use so I'll have to wait a bit.

1 Like

In the mean time, I have a guess as to why I see the error on 4.19 but not 4.14.

between 4.14 and 4.19 the cpuidle-arm.c driver was changed. In 4.14, the driver was registered and then initialized (initialization is the point at which the error msg I see is generated).

In 4.19, the driver registration code was moved to below the the initialization code.

Since the initialization code is executed at least once before the driver is registered the error pops up. After that first time, the driver gets registered (I never see the error msg "Failed to register cpuidle driver", the initialization code probably gets called again later but this time the driver is registered so no more cpuidle error msgs. i.e. the cpuidle driver is present and working on 4.19

so we should do some magic in the dts like we do for usb....

1 Like

no, don't think so. Now the patch I saw (and edited out of) my earlier post is starting to make more sense (as well as the follow on patch. It seems the authors intent is to print the error msg.

Since I'm not entirely sure I know the authors intent yet, I wouldn't propose "fixing" anything just now. I would like to know why current_driver is "none" on 4.19 and what it reports on 4.14.

got to be domestic for a time... bbl

cat /sys/devices/system/cpu/cpuidle/current_driver
arm_idle

from trunk R7800 4.14

1 Like

@nmrh i think this is our answer...
https://lkml.org/lkml/2019/2/28/519

or not.........

ok, so maybe there is something to fix here.

there is a default cpuidle driver if all others fail (documented in kernel 5.0 here but I think this still is in 4.19). sysfs.c (which provides the output to

/sys/devices/system/cpu/cpuidle/current_driver

has

	drv = cpuidle_get_driver();
	if (drv)
		ret = sprintf(buf, "%s\n", drv->name);
	else
		ret = sprintf(buf, "none\n");

which I interpret as "none" means the kernel is using the default driver and not arm_idle

This commit message refers to the cpuidle 4.19 code as a regression so I can try to edit what's in openwrt ipq1806x 4.19 to look like what is now in the linux kernel master and see if behaves as expected.

I'm not sure I see the error - perhaps with the dev stuff and goto statements that all got removed in the commit.

I'll definitely look over what @ansuel just posted as well

will backport this and try to compile

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/cpuidle/cpuidle-arm.c?id=dbb3c26034fa5336de45e667e2faf80a78531cd0

let's hope they didn't made massive changes between 4.19 and 5.0 to the cpuidle stock driver

I think you'll need to hand edit, I dont think the commit will apply cleanly.

yhea... but the real problem will be make it compile...

idk, maybe not - i'd just stick to the cpuidle-arm.c code to start and see if it complies and gives something different in current_driver

BTW what do you see in current_driver for r7800 kernel 4.19?

for cpu_idle i have none in 4.19

anyway the patch applies cleanly .... compiling a test build wait 5 minutes and i will try it...

1 Like

i'll wait...

no luck still same error

we can confirm that problems is here

ret = arm_cpuidle_init(cpu);

We can really try to swap the inizialization and the registration...

But i would really like to find what actually fix that commit.... They could have made that change based on the logic that something needs to first be inizialized and then registred?

k, well it'll take some more effort then, more than likely there are some other changes to be made. Also at this point it might be good to ask around - I think this issues been solved. Just not by us...

you can compile, flash and test that fast? it would take me half a day...

i'm the only one using the router so.... compiles times are not that bad so if you have something to try... just link me and i will


Well... solved... the driver i have now is mailine kernel so.... i really think we have something wrong in the dtsi or we should investigate the arm_cpuidle_init function

1 Like

I was thinking to edit the error message and have it return the error code...

pr_err("CPU %d failed to init idle CPU ops\n", cpu);

include "ret" in that if its possible

doing it right now :wink:

flashing....