linux-toradex.git/drivers/acpi, branch v3.0.26

ACPI / PM: Do not save/restore NVS on Asus K54C/K54HR

2012-03-12T17:32:57+00:00

commit 5a50a7c32d630d6cdb13d69afabb0cc81b2f379c upstream.

The models do not resume correctly without acpi_sleep=nonvs.

Signed-off-by: Keng-Yu Lin 
Signed-off-by: Rafael J. Wysocki 
Cc: Tim Gardner 
Signed-off-by: Greg Kroah-Hartman

PCI: Rework ASPM disable code

2012-02-06T17:24:01+00:00

commit 3c076351c4027a56d5005a39a0b518a4ba393ce2 upstream.

Right now we forcibly clear ASPM state on all devices if the BIOS indicates
that the feature isn't supported. Based on the Microsoft presentation
"PCI Express In Depth for Windows Vista and Beyond", I'm starting to think
that this may be an error. The implication is that unless the platform
grants full control via _OSC, Windows will not touch any PCIe features -
including ASPM. In that case clearing ASPM state would be an error unless
the platform has granted us that control.

This patch reworks the ASPM disabling code such that the actual clearing
of state is triggered by a successful handoff of PCIe control to the OS.
The general ASPM code undergoes some changes in order to ensure that the
ability to clear the bits isn't overridden by ASPM having already been
disabled. Further, this theoretically now allows for situations where
only a subset of PCIe roots hand over control, leaving the others in the
BIOS state.

It's difficult to know for sure that this is the right thing to do -
there's zero public documentation on the interaction between all of these
components. But enough vendors enable ASPM on platforms and then set this
bit that it seems likely that they're expecting the OS to leave them alone.

Measured to save around 5W on an idle Thinkpad X220.

Signed-off-by: Matthew Garrett 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

ACPI: processor: fix acpi_get_cpuid for UP processor

2012-01-26T01:24:59+00:00

commit d640113fe80e45ebd4a5b420b220d3f6bf37f682 upstream.

For UP processor, it is likely that no _MAT method or MADT table defined.
So currently acpi_get_cpuid(...) always return -1 for UP processor.
This is wrong. It should return valid value for CPU0.

In the other hand, BIOS may define multiple CPU handles even for UP
processor, for example

        Scope (_PR)
        {
            Processor (CPU0, 0x00, 0x00000410, 0x06) {}
            Processor (CPU1, 0x01, 0x00000410, 0x06) {}
            Processor (CPU2, 0x02, 0x00000410, 0x06) {}
            Processor (CPU3, 0x03, 0x00000410, 0x06) {}
        }

We should only return valid value for CPU0's acpi handle.
And return invalid value for others.

http://marc.info/?t=132329819900003&r=1&w=2

Reported-and-tested-by: wallak@free.fr
Signed-off-by: Lin Ming 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

ACPICA: Put back the call to acpi_os_validate_address

2012-01-26T01:24:58+00:00

commit da4d8b287abe783d30e968155614531a0937d090 upstream.

The call to acpi_os_validate_address in acpi_ds_get_region_arguments was
removed by mistake in commit 9ad19ac(ACPICA: Split large dsopcode and
dsload.c files).

Put it back.

Reported-and-bisected-by: Luca Tettamanti 
Signed-off-by: Lin Ming 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

ACPI: Store SRAT table revision

2012-01-26T01:24:57+00:00

commit 8df0eb7c9d96f9e82f233ee8b74e0f0c8471f868 upstream.

In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
32bits for these. The new fields were reserved before.
According to the ACPI spec, the OS must disregrard reserved fields.
In order to know whether or not, we must know what version the SRAT
table has.

This patch stores the SRAT table revision for later consumption
by arch specific __init functions.

Signed-off-by: Kurt Garloff 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

ACPI atomicio: Convert width in bits to bytes in __acpi_ioremap_fast()

2011-11-11T17:37:11+00:00

commit 3bf3f8b19d2bfccc40f13c456bf339fd8f535ebc upstream.

Callers to __acpi_ioremap_fast() pass the bit_width that they found in the
acpi_generic_address structure. Convert from bits to bytes when passing to
__acpi_find_iomap() - as it wants to see bytes, not bits.

Signed-off-by: Tony Luck 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

acpica: ACPI_MAX_SLEEP should be 2 sec, not 20

2011-10-03T18:40:25+00:00

commit b33c25d6a62ac253caabda2b5f43258abff451c0 upstream.

This limit is a workaround for AML that sleeps too long,
but the workaround didn't work b/c of a typo.

https://bugzilla.kernel.org/show_bug.cgi?id=13195

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

ACPICA: Do not repair _TSS return package if _PSS is present

2011-10-03T18:40:21+00:00

commit 8f9c91273e36e5762c617c23e4fd48d5172e0dac upstream.

We can only sort the _TSS return package if there is no _PSS
in the same scope. This is because if _PSS is present, the ACPI
specification dictates that the _TSS Power Dissipation field is
to be ignored, and therefore some BIOSs leave garbage values in
the _TSS Power field(s).  In this case, it is best to just return
the _TSS package as-is.

Reported-by: Fenghua Yu 
Signed-off-by: Fenghua Yu 
Signed-off-by: Bob Moore 
Signed-off-by: Lin Ming 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

Merge branches 'd3cold', 'bugzilla-37412' and 'bugzilla-38152' into release

2011-07-14T04:16:38+00:00

ACPI, APEI, HEST, Detect duplicated hardware error source ID

2011-07-14T03:27:56+00:00

The firmware on some machine will report duplicated hardware error
source ID in HEST.  This is considered a firmware bug.  To provide
better warning message, this patch adds duplicated hardware error
source ID detecting and corresponding printk.

This patch fixes #37412 on kernel bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=37412

Reported-by: marconifabio@ubuntu-it.org
Signed-off-by: Huang Ying 
Tested-by: Mathias 
Signed-off-by: Len Brown