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.
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....
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
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
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...
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
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 
flashing....