From c4a001b1ea32e09f7556178249b8885418858b5c Mon Sep 17 00:00:00 2001 From: Dominik Brodowski Date: Sat, 24 Jun 2006 19:37:00 -0400 Subject: ACPI: C-States: only demote on current bus mastering activity Only if bus master activity is going on at the present, we should avoid entering C3-type sleep, as it might be a faulty transition. As long as the bm_activity bitmask was based on the number of calls to the ACPI idle function, looking at previous moments made sense. Now, with it being based on what happened this jiffy, looking at this jiffy should be sufficient. Signed-off-by: Dominik Brodowski Signed-off-by: Andrew Morton Signed-off-by: Len Brown --- drivers/acpi/processor_idle.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'drivers/acpi/processor_idle.c') diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c index af9f2afd72da..f8d2b2f47fd4 100644 --- a/drivers/acpi/processor_idle.c +++ b/drivers/acpi/processor_idle.c @@ -287,10 +287,10 @@ static void acpi_processor_idle(void) pr->power.bm_check_timestamp = jiffies; /* - * Apply bus mastering demotion policy. Automatically demote + * If bus mastering is or was active this jiffy, demote * to avoid a faulty transition. Note that the processor * won't enter a low-power state during this call (to this - * funciton) but should upon the next. + * function) but should upon the next. * * TBD: A better policy might be to fallback to the demotion * state (use it for this quantum only) istead of @@ -298,7 +298,8 @@ static void acpi_processor_idle(void) * qualification. This may, however, introduce DMA * issues (e.g. floppy DMA transfer overrun/underrun). */ - if (pr->power.bm_activity & cx->demotion.threshold.bm) { + if ((pr->power.bm_activity & 0x1) && + cx->demotion.threshold.bm) { local_irq_enable(); next_state = cx->demotion.state; goto end; -- cgit v1.2.1