kernel/git/stable/linux.git/drivers/acpi/bus.c, branch linux-3.8.y

ACPI / PM: Add check preventing transitioning to non-D0 state from D3.

2012-11-16T01:46:28+00:00

No power transitioning from D3 state up to a non-D0 state is allowed so make acpi_device_set_power() fail and complain if such a transition is attempted. Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPI / PM: Provide device PM functions operating on struct acpi_device

2012-11-14T23:15:18+00:00

If the caller of acpi_bus_set_power() already has a pointer to the struct acpi_device object corresponding to the device in question, it doesn't make sense for it to go through acpi_bus_get_device(), which may be costly, because it involves acquiring the global ACPI namespace mutex. For this reason, export the function operating on struct acpi_device objects used internally by acpi_bus_set_power(), so that it may be called instead of acpi_bus_set_power() in the above case, and change its name to acpi_device_set_power(). Additionally, introduce two inline wrappers for checking ACPI PM capabilities of devices represented by struct acpi_device objects. Signed-off-by: Rafael J. Wysocki

ACPI: run _OSC after ACPI_FULL_INITIALIZATION

2012-09-25T04:15:07+00:00

The _OSC method may exist in module level code, so it must be called after ACPI_FULL_INITIALIZATION On some new platforms with Zero-Power-Optical-Disk-Drive (ZPODD) support, this fix is necessary to save power. Signed-off-by: Lin Ming Tested-by: Aaron Lu Signed-off-by: Len Brown Cc: stable@vger.kernel.org

ACPI / PM: Infer parent power state from child if unknown, v2

2012-09-13T22:26:24+00:00

It turns out that there are ACPI BIOSes defining device objects with _PSx and without either _PSC or _PRx. For devices corresponding to those ACPI objetcs __acpi_bus_get_power() returns ACPI_STATE_UNKNOWN and their initial power states are regarded as unknown as a result. If such a device is a parent of another power-manageable device, the child cannot be put into a low-power state through ACPI, because __acpi_bus_set_power() refuses to change power states of devices whose parents' power states are unknown. To work around this problem, observe that the ACPI power state of a device cannot be higher-power (lower-number) than the power state of its parent. Thus, if the device's _PSC method or the configuration of its power resources indicates that the device is in D0, the device's parent has to be in D0 as well. Consequently, if the parent's power state is unknown when we've just learned that its child's power state is D0, we can safely set the parent's power.state field to ACPI_STATE_D0. Tested-by: Aaron Lu Cc: stable@vger.kernel.org Signed-off-by: Rafael J. Wysocki

Merge branches 'acpi_pad', 'acpica', 'apei-bugzilla-43282', 'battery', 'cpuidle-coupled', 'cpuidle-tweaks', 'intel_idle-ivb', 'ost', 'red-hat-bz-772730', 'thermal', 'thermal-spear' and 'turbostat-v2' into release

2012-07-26T04:03:58+00:00

ACPI: Set hotplug _OST support bit to _OSC

2012-06-04T05:09:23+00:00

When ACPI_HOTPLUG_OST is defined, set hotplug _OST support bit OSC_SB_HOTPLUG_OST_SUPPORT to indicate that the OS supports hotplug _OST by calling the platform-wide ACPI Operating System Capabilities (_OSC). Signed-off-by: Toshi Kani Signed-off-by: Len Brown

ACPI / PM: Make __acpi_bus_get_power() cover D3cold correctly

2012-05-29T19:20:24+00:00

After recent changes of the ACPI device power states definitions, if power resources are not used for the device's power management, the state returned by __acpi_bus_get_power() cannot exceed D3hot, because the return values of _PSC are 0 through 3. However, if the _PR3 method is not present for the device and _PS3 returns 3, we have to assume that the device is in D3cold, so the value returned by __acpi_bus_get_power() in that case should be 4. Similarly, acpi_power_get_inferred_state() should take the power resources for the D3hot state into account in general, so that it can return 3 if those resources are "on" or 4 (D3cold) otherwise. Fix the the above two issues and make sure that if both _PSC and _PR3 are present for the device, the power resources listed by _PR3 will be used to determine if the number 3 returned by _PSC is meant to represent D3cold or D3hot. Signed-off-by: Rafael J. Wysocki

ACPI / PM: Fix error messages in drivers/acpi/bus.c

2012-05-29T19:20:23+00:00

After recent changes of the ACPI device low-power states definitions kernel messages in drivers/acpi/bus.c need to be updated so that they include the correct names of the states in question (currently is "D3" for D3hot and "D4" for D3cold, which is incorrect). Signed-off-by: Rafael J. Wysocki

ACPI / PCI / PM: Fix device PM regression related to D3hot/D3cold

2012-05-17T23:16:16+00:00

Commit 1cc0c998fdf2 ("ACPI: Fix D3hot v D3cold confusion") introduced a bug in __acpi_bus_set_power() and changed the behavior of acpi_pci_set_power_state() in such a way that it generally doesn't work as expected if PCI_D3hot is passed to it as the second argument. First off, if ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) is passed to __acpi_bus_set_power() and the explicit_set flag is set for the D3cold state, the function will try to execute AML method called "_PS4", which doesn't exist. Fix this by adding a check to ensure that the name of the AML method to execute for transitions to ACPI_STATE_D3_COLD is correct in __acpi_bus_set_power(). Also make sure that the explicit_set flag for ACPI_STATE_D3_COLD will be set if _PS3 is present and modify acpi_power_transition() to avoid accessing power resources for ACPI_STATE_D3_COLD, because they don't exist. Second, if PCI_D3hot is passed to acpi_pci_set_power_state() as the target state, the function will request a transition to ACPI_STATE_D3_HOT instead of ACPI_STATE_D3. However, ACPI_STATE_D3_HOT is now only marked as supported if the _PR3 AML method is defined for the given device, which is rare. This causes problems to happen on systems where devices were successfully put into ACPI D3 by pci_set_power_state(PCI_D3hot) which doesn't work now. In particular, some unused graphics adapters are not turned off as a result. To fix this issue restore the old behavior of acpi_pci_set_power_state(), which is to request a transition to ACPI_STATE_D3 (equal to ACPI_STATE_D3_COLD) if either PCI_D3hot or PCI_D3cold is passed to it as the argument. This approach is not ideal, because generally power should not be removed from devices if PCI_D3hot is the target power state, but since this behavior is relied on, we have no choice but to restore it at the moment and spend more time on designing a better solution in the future. References: https://bugzilla.kernel.org/show_bug.cgi?id=43228 Reported-by: rocko Reported-by: Cristian Rodríguez Reported-and-tested-by: Peter Signed-off-by: Rafael J. Wysocki Signed-off-by: Linus Torvalds

ACPI: export acpi_kobj

2012-03-30T08:09:05+00:00

Drivers may wish to add entries to /sys/firmware/acpi, so export acpi_kobj in order to let them do that. Signed-off-by: Matthew Garrett Signed-off-by: Len Brown