> > What is next: > > > > handle c1e_idle() vs default_idle() > > run-time check for AMD workaround enable as part of default_idle? > > give xen_arch_setup default_idle() w/o having it touch pm_idle > > perhaps it can simply set a flag to disable cpuidle... > > which is what would run if the xen kernel were > > booted on raw iron. Or can we handle this > > at compile time? > > I guess it may be good to have a method to override cpuidle and > force it to call default_idle from inside cpuidle_idle_call(). This > could be useful for users other than xen in future. Ofcourse this override > should not touch pm_idle (which would be removed anyway). Actually what I was thinking was the ability to disable cpuidle altogether via cmdline. ie a run-time equivalent of CONFIG_CPU_IDLE=n. eg. "cpuidle=0" In that case cpu_idle_call() would return error and we'd have: cpu_idle() if (cpu_idle_call()) default_idle() This is also a clean way for CONFIG_CPU_IDLE=n to work. > Provision is already there to call default_idle from inside > cpuidle_idle_call(); we can use that after checking a flag?? Can > we use something like boot_option_idle_override? Or set/unset > flag through an API? I think it is strange for cpuidle to turn around and call back to default_idle(). I'd like to see if we can keep knowledge of default_idle() inside process.c. If cpuidle can't do better than default_idle() then it sholdn't be running... > > delete pm_idle > > x86 will then use default_idle or cpuidle > > allow cpuidle to use default_idle to handle the period > > where it polls because cpus have not yet registered > > If we remove pm_idle and directly call cpuidle, the > check already exists to call default_idle until a cpuidle > driver (and cpus) is registered. it isn't working. If it were, then we'd not see any polling in the cpuidle stats. cheers, -Len _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
