On Fri, 2009-07-10 at 19:46 -0400, Dave Jones wrote: > The fail part comes from the fact that interrupts get reenabled. > And that's something that can easily happen out of our control if > we call into acpi_cpufreq's ->get method for example, so powernow-k8 isn't > the sole reason. > > > I'm happy instead of #ifdef's however to push the logic into the ppc > > driver, or use a flag that the ppc driver sets to enable that logic. So I'm not too familiar with what other platforms expect here, but would it be ok to do something like bailing our early in cpufreq_suspend() if there's no cpufreq_driver->suspend method ? We would need to do the same on resume, though I do wonder whether there could be a problem with even x86 here.. do we know for sure that we come back from suspend with the same policy we had before suspending ? IE. We should probably always do that check on resume, but we can't do it too early due to irqs being off... It's all because cpufreq is a sysdev which was imho a mistake in the first place :-) Maybe at this stage the best option is to add suspend_prepare and resume_finish callbacks to sysdevs that are called while IRQs are still on, and move cpufreq to use these instead ? That probably means we also need to keep track that we have started suspend in the cpufreq core and forbid attempts at changing policy etc... from either userspace of on-demand governor while suspended, so that's more work, but could be the best approach in the long run, what do you think ? Otherwise I'm happy to just submit a patch that makes cpufreq_suspend/resume bail out early if driver->suspend/resume are NULL (or do you prefer a driver flag ?) Cheers, Ben. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
