Len, sorry for answering late. Your mail got into the wrong folder after I had to restructure my procmail crap due to a dead server disk. :( On Thu, 4 Oct 2007, Len Brown wrote: > From: Len Brown <len.brown@xxxxxxxxx> > > Some timers stop during C2 and C3, and so there are various > generations of timer broadcast workarounds to deal with that. > But that (already complex) code gets confused during suspend. > > As it is unlikely that deep C-states would save much power > during the actual suspend/resume process anyway, deep C-states > were disabled via the addition of .suspend/.resume hooks > in to the ACPI processor driver. > > Here that workaround is ported to the cpuidle version of > the ACPI idle loop. Technically, ACPI could un-register > itself from cpuidle on .suspend, but that code path > is currently quite cumbersome. So instead, > we simply invoke C1 from the C2 and C3 handlers > for the duration of .suspend/.resume. That's basically what I did in my -hrt patch set. I just wonder whether this decision should be moved into the cpuidle code. > Signed-off-by: Len Brown <len.brown@xxxxxxxxx> Reviewed-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > --- > processor_idle.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c > index d924aa3..3b62632 100644 > --- a/drivers/acpi/processor_idle.c > +++ b/drivers/acpi/processor_idle.c > @@ -1373,6 +1373,10 @@ static int acpi_idle_enter_simple(struct cpuidle_device *dev, > if (unlikely(!pr)) > return 0; > > + if (acpi_idle_suspend) > + return(acpi_idle_enter_c1(dev, state)); > + > + > local_irq_disable(); > current_thread_info()->status &= ~TS_POLLING; > /* > @@ -1431,6 +1435,9 @@ static int acpi_idle_enter_bm(struct cpuidle_device *dev, > if (unlikely(!pr)) > return 0; > > + if (acpi_idle_suspend) > + return(acpi_idle_enter_c1(dev, state)); > + > local_irq_disable(); > current_thread_info()->status &= ~TS_POLLING; > /* > - 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
