kernel.git/drivers/acpi/sleep.c, branch linux-2.6.33.y

ACPI: Unconditionally set SCI_EN on resume

2010-08-02T17:26:45Z

commit b6dacf63e9fb2e7a1369843d6cef332f76fca6a3 upstream. The ACPI spec tells us that the firmware will reenable SCI_EN on resume. Reality disagrees in some cases. The ACPI spec tells us that the only way to set SCI_EN is via an SMM call. https://bugzilla.kernel.org/show_bug.cgi?id=13745 shows us that doing so may break machines. Tracing the ACPI calls made by Windows shows that it unconditionally sets SCI_EN on resume with a direct register write, and therefore the overwhelming probability is that everything is fine with this behaviour. Signed-off-by: Matthew Garrett Tested-by: Rafael J. Wysocki Signed-off-by: Len Brown Cc: Kamal Mostafa Signed-off-by: Greg Kroah-Hartman

ACPI: sleep: eliminate duplicate entries in acpisleep_dmi_table[]

2010-05-26T21:32:05Z

commit 7d6fb7bd1919517937ec390f6ca2d7bcf4f89fb6 upstream. Duplicate entries ended up acpisleep_dmi_table[] by accident. They don't hurt functionality, but they are ugly, so let's get rid of them. Signed-off-by: Alex Chiang Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

ACPI: sleep: init_set_sci_en_on_resume for Dell Studio 155x

2010-05-12T22:03:10Z

commit ea5bc73f4f56449b2d450068d492bcd17a675d7a upstream. Add Dell Studio models (1558, 1557, 1555) to the 'set_sci_en_on_resume' list to fix hang on resume. BugLink: http://bugs.launchpad.net/bugs/553498 Signed-off-by: Kamal Mostafa Acked-by: Alex Chiang Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

ACPI: DMI init_set_sci_en_on_resume for multiple Lenovo ThinkPads

2010-05-12T22:03:09Z

commit 07bedca29b0973f36a6b6db36936deed367164ed upstream. Multiple Lenovo ThinkPad models with Intel Core i5/i7 CPUs can successfully suspend/resume once, and then hang on the second s/r cycle. We got confirmation that this was due to a BIOS defect. The BIOS did not properly set SCI_EN coming out of S3. The BIOS guys hinted that The Other Leading OS ignores the fact that hardware owns the bit and sets it manually. In any case, an existing DMI table exists for machines where this defect is a known problem. Lenovo promise to fix their BIOS, but for folks who either won't or can't upgrade their BIOS, allow Linux to workaround the issue. https://bugzilla.kernel.org/show_bug.cgi?id=15407 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/532374 Confirmed by numerous testers in the launchpad bug that using acpi_sleep=sci_force_enable fixes the issue. We add the machines to acpisleep_dmi_table[] to automatically enable this workaround. Cc: Colin King Signed-off-by: Alex Chiang Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

ACPI: introduce kernel parameter acpi_sleep=sci_force_enable

2009-12-30T23:32:01Z

Introduce kernel parameter acpi_sleep=sci_force_enable some laptop requires SCI_EN being set directly on resume, or else they hung somewhere in the resume code path. We already have a blacklist for these laptops but we still need this option, especially when debugging some suspend/resume problems, in case there are systems that need this workaround and are not yet in the blacklist. Signed-off-by: Zhang Rui Acked-by: Rafael J. Wysocki Signed-off-by: Len Brown

ACPI: DMI init_set_sci_en_on_resume for HP-Compaq C700

2009-11-23T16:44:12Z

...else ACPI thermal controls fail after resume. http://bugzilla.kernel.org/show_bug.cgi?id=13745 Signed-off-by: Len Brown

ACPI: sleep: another HP/Compaq DMI entries for init_set_sci_en_on_resume

2009-11-06T04:13:36Z

http://bugzilla.kernel.org/show_bug.cgi?id=13745 Signed-off-by: Len Brown

ACPI: add DMI entry for SCI_EN resume quirk on HP dv4

2009-11-06T04:04:32Z

Fixes the missing battery on sleep problem for yet another HP laptop ("HP Pavilion dv4"). Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=13449 Signed-off-by: Gustavo Maciel Dias Vieira Signed-off-by: Len Brown

Merge branch 'linus' into release

2009-09-19T04:06:59Z

PCI / ACPI PM: Propagate wake-up enable for devices w/o ACPI support

2009-09-09T21:19:24Z

Some PCI devices (not PCI Express), like PCI add-on cards, can generate PME#, but they don't have any special platform wake-up support. For this reason, even if they generate PME# to wake up the system from a sleep state, wake-up events are not generated by the platform. It turns out that, at least on some systems, PCI bridges and the PCI host bridge have ACPI GPEs associated with them that, if enabled to generate wake-up events, allow the system to wake up if one of the add-on devices asserts PME# while the system is in a sleep state. Following this observation, if a PCI device without direct ACPI wake-up support is prepared to wake up the system during a transition into a sleep state (eg. suspend to RAM), try to configure the bridges on the path from the device to the root bridge to wake-up the system. Reviewed-by: Matthew Garrett Signed-off-by: Rafael J. Wysocki Signed-off-by: Jesse Barnes