linux/drivers/acpi, branch v2.6.35.4

acpi: fix bogus preemption logic

2010-08-26T23:45:43Z

commit 0a7992c90828a65281c3c9cf180be3b432d277b2 upstream. The ACPI_PREEMPTION_POINT() logic was introduced in commit 8bd108d (ACPICA: add preemption point after each opcode parse). The follow up commits abe1dfab6, 138d15692, c084ca70 tried to fix the preemption logic back and forth, but nobody noticed that the usage of in_atomic_preempt_off() in that context is wrong. The check which guards the call of cond_resched() is: if (!in_atomic_preempt_off() && !irqs_disabled()) in_atomic_preempt_off() is not intended for general use as the comment above the macro definition clearly says: * Check whether we were atomic before we did preempt_disable(): * (used by the scheduler, *after* releasing the kernel lock) On a CONFIG_PREEMPT=n kernel the usage of in_atomic_preempt_off() works by accident, but with CONFIG_PREEMPT=y it's just broken. The whole purpose of the ACPI_PREEMPTION_POINT() is to reduce the latency on a CONFIG_PREEMPT=n kernel, so make ACPI_PREEMPTION_POINT() depend on CONFIG_PREEMPT=n and remove the in_atomic_preempt_off() check. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16210 [akpm@linux-foundation.org: fix build] Signed-off-by: Thomas Gleixner Cc: Len Brown Cc: Francois Valenduc Cc: Lin Ming Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

Merge branch 'bugzilla-16396' into release

2010-07-25T03:26:22Z

ACPI / Sleep: Allow the NVS saving to be skipped during suspend to RAM

2010-07-25T03:26:09Z

Commit 2a6b69765ad794389f2fc3e14a0afa1a995221c2 (ACPI: Store NVS state even when entering suspend to RAM) caused the ACPI suspend code save the NVS area during suspend and restore it during resume unconditionally, although it is known that some systems need to use acpi_sleep=s4_nonvs for hibernation to work. To allow the affected systems to avoid saving and restoring the NVS area during suspend to RAM and resume, introduce kernel command line option acpi_sleep=nonvs and make acpi_sleep=s4_nonvs work as its alias temporarily (add acpi_sleep=s4_nonvs to the feature removal file). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16396 . Signed-off-by: Rafael J. Wysocki Reported-and-tested-by: tomas m Signed-off-by: Len Brown

Merge branch 'misc' into release

2010-07-22T22:19:12Z

Merge branch 'bugzilla-15886' into release

2010-07-22T22:18:28Z

Merge branch 'bugzilla-102904-workaround' into release

2010-07-22T22:18:18Z

Merge branch 'bugzilla-16244' into release

2010-07-22T22:18:05Z

Merge branch 'bugzilla-16271' into release

2010-07-22T22:17:39Z

ACPI: create "processor.bm_check_disable" boot param

2010-07-22T21:23:10Z

processor.bm_check_disable=1" prevents Linux from checking BM_STS before entering C3-type cpu power states. This may be useful for a system running acpi_idle where the BIOS exports FADT C-states, _CST IO C-states, or _CST FFH C-states with the BM_STS bit set; while configuring the chipset to set BM_STS more frequently than perhaps is optimal. Note that such systems may have been developed using a tickful OS that would quickly clear BM_STS, rather than a tickless OS that may go for some time between checking and clearing BM_STS. Note also that an alternative for newer systems is to use the intel_idle driver, which always ignores BM_STS, relying Linux device drivers to register constraints explicitly via PM_QOS. https://bugzilla.kernel.org/show_bug.cgi?id=15886 Signed-off-by: Len Brown

ACPI: skip checking BM_STS if the BIOS doesn't ask for it

2010-07-22T20:54:27Z

It turns out that there is a bit in the _CST for Intel FFH C3 that tells the OS if we should be checking BM_STS or not. Linux has been unconditionally checking BM_STS. If the chip-set is configured to enable BM_STS, it can retard or completely prevent entry into deep C-states -- as illustrated by turbostat: http://userweb.kernel.org/~lenb/acpi/utils/pmtools/turbostat/ ref: Intel Processor Vendor-Specific ACPI Interface Specification table 4 "_CST FFH GAS Field Encoding" Bit 1: Set to 1 if OSPM should use Bus Master avoidance for this C-state https://bugzilla.kernel.org/show_bug.cgi?id=15886 Signed-off-by: Len Brown