On Sat, 2009-07-04 at 14:29 -0700, Rafael J. Wysocki wrote: > On Saturday 04 July 2009, Michael Witten wrote: > > On Tue, 16 Jun 2009 23:39:59 +0200, Rafael J. Wysocki wrote > > (http://www.spinics.net/lists/linux-acpi/msg22661.html): > > > > > In fact, we need to do this entire thing differently. > > > > > > The basic problem is that cpufreq_suspend() is a sysdev thing, so it will > > > always be called with iterrupts off and *only* for CPU0. So, it looks like > > > the majority of things we do there is just unnecessary (at least). > > > > What's the status? This bug is driving me nuts. > > Unfortunately, still unresolved. Looked at this a bit more from acpi cpufreq angle. But, I feel the patch that Johannes had here http://lkml.indiana.edu/hypermail/linux/kernel/0906.2/00335.html is the right fix as we do the same saving and restoring of flags on SMP when cpu==this_cpu. This change will make code in UP same as that in SMP with 1 CPU active. We can avoid the driver->get call from cpufreq_suspend for the drivers that do not do any freq changes in their suspend methods. But, then we will hit this same problem in cpufreq_resume() path and there we do want to check for adjust_jiffies for all drivers as long as CONSTANT_LOOPS is not set. Thanks, Venki -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
