linux-toradex.git/drivers/acpi, branch v2.6.32.22

ACPI: Fix regression where _PPC is not read at boot even when ignore_ppc=0

2010-08-13T20:20:17+00:00

commit 455c0d71d46e86b0b7ff2c9dcfc19bc162302ee9 upstream.

Earlier, Ingo Molnar posted a patch to make it so that the kernel would avoid
reading _PPC on his broken T60.  Unfortunately, it seems that with Thomas
Renninger's patch last July to eliminate _PPC evaluations when the processor
driver loads, the kernel never actually reads _PPC at all!  This is problematic
if you happen to boot your non-T60 computer in a state where the BIOS _wants_
_PPC to be something other than zero.

So, put the _PPC evaluation back into acpi_processor_get_performance_info if
ignore_ppc isn't 1.

Signed-off-by: Darrick J. Wong 
Signed-off-by: Len Brown 
Acked-by: Jeff Mahoney 
Signed-off-by: Greg Kroah-Hartman

ACPI: Unconditionally set SCI_EN on resume

2010-08-02T17:21:25+00:00

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: skip checking BM_STS if the BIOS doesn't ask for it

2010-08-02T17:21:24+00:00

commit 718be4aaf3613cf7c2d097f925abc3d3553c0605 upstream.

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 
Signed-off-by: Greg Kroah-Hartman

ACPI: video: fix acpi_backlight=video

2010-07-05T18:10:33+00:00

commit eeb4bcb4771679d7b3446c0293334faee11b090a upstream.

Make "acpi_backlight=video" param enable ACPI_VIDEO_BACKLIGHT_FORCE_VIDEO
as intended, instead of incorrectly enabling video output switching.

BugLink: http://bugs.launchpad.net/bugs/573120

Signed-off-by: Kamal Mostafa 
Acked-by: Zhang Rui 
Cc: Bjorn Helgaas 
Cc: Jiri Kosina 
Acked-by: Thomas Renninger 
Signed-off-by: Andrew Morton 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

ACPI: sleep: eliminate duplicate entries in acpisleep_dmi_table[]

2010-05-26T21:29:14+00:00

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-12T21:57:15+00:00

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

power_meter: acpi_device_class "power_meter_resource" too long

2010-05-12T21:57:15+00:00

commit 18262714ca0fb65c290b8ea1807b2b02bb52d0e3 upstream.

acpi_device_class can only be 19 characters and a NULL terminator.

The current code has a buffer overflow in acpi_power_meter_add():
       strcpy(acpi_device_class(device), ACPI_POWER_METER_CLASS);

Signed-off-by: Dan Carpenter 
Cc: Len Brown 
Cc: "Darrick J. Wong" 
Signed-off-by: Andrew Morton 
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-12T21:57:15+00:00

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

2010-05-12T21:57:11+00:00

commit d7f0eea9e431e1b8b0742a74db1a9490730b2a25 upstream.

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 
Signed-off-by: Greg Kroah-Hartman

ACPI: EC: Limit burst to 64 bits

2010-04-26T14:41:34+00:00

commit 2060c44576c79086ff24718878d7edaa7384a985 upstream.

access_bit_width field is u8 in ACPICA, thus 256 value written to it
becomes 0, causing divide by zero later.

Proper fix would be to remove access_bit_width at all, just because
we already have access_byte_width, which is access_bit_width / 8.
Limit access width to 64 bit for now.

https://bugzilla.kernel.org/show_bug.cgi?id=15749
fixes regression caused by the fix for:
https://bugzilla.kernel.org/show_bug.cgi?id=14667

Signed-off-by: Alexey Starikovskiy 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman