2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* File: pci-acpi.c
|
2005-03-23 21:16:03 +00:00
|
|
|
* Purpose: Provide PCI support in ACPI
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2005-03-18 23:53:36 +00:00
|
|
|
* Copyright (C) 2005 David Shaohua Li <shaohua.li@intel.com>
|
|
|
|
* Copyright (C) 2004 Tom Long Nguyen <tom.l.nguyen@intel.com>
|
|
|
|
* Copyright (C) 2004 Intel Corp.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/pci.h>
|
|
|
|
#include <linux/module.h>
|
2008-07-23 02:32:24 +00:00
|
|
|
#include <linux/pci-aspm.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <acpi/acpi.h>
|
|
|
|
#include <acpi/acpi_bus.h>
|
|
|
|
|
|
|
|
#include <linux/pci-acpi.h>
|
2010-02-17 22:44:09 +00:00
|
|
|
#include <linux/pm_runtime.h>
|
2012-10-24 00:08:38 +00:00
|
|
|
#include <linux/pm_qos.h>
|
2005-03-19 05:15:48 +00:00
|
|
|
#include "pci.h"
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-02-17 22:44:09 +00:00
|
|
|
/**
|
|
|
|
* pci_acpi_wake_bus - Wake-up notification handler for root buses.
|
|
|
|
* @handle: ACPI handle of a device the notification is for.
|
|
|
|
* @event: Type of the signaled event.
|
|
|
|
* @context: PCI root bus to wake up devices on.
|
|
|
|
*/
|
|
|
|
static void pci_acpi_wake_bus(acpi_handle handle, u32 event, void *context)
|
|
|
|
{
|
|
|
|
struct pci_bus *pci_bus = context;
|
|
|
|
|
|
|
|
if (event == ACPI_NOTIFY_DEVICE_WAKE && pci_bus)
|
|
|
|
pci_pme_wakeup_bus(pci_bus);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_acpi_wake_dev - Wake-up notification handler for PCI devices.
|
|
|
|
* @handle: ACPI handle of a device the notification is for.
|
|
|
|
* @event: Type of the signaled event.
|
|
|
|
* @context: PCI device object to wake up.
|
|
|
|
*/
|
|
|
|
static void pci_acpi_wake_dev(acpi_handle handle, u32 event, void *context)
|
|
|
|
{
|
|
|
|
struct pci_dev *pci_dev = context;
|
|
|
|
|
2011-11-06 21:21:46 +00:00
|
|
|
if (event != ACPI_NOTIFY_DEVICE_WAKE || !pci_dev)
|
|
|
|
return;
|
|
|
|
|
PCI/PM: add PCIe runtime D3cold support
This patch adds runtime D3cold support and corresponding ACPI platform
support. This patch only enables runtime D3cold support; it does not
enable D3cold support during system suspend/hibernate.
D3cold is the deepest power saving state for a PCIe device, where its main
power is removed. While it is in D3cold, you can't access the device at
all, not even its configuration space (which is still accessible in D3hot).
Therefore the PCI PM registers can not be used to transition into/out of
the D3cold state; that must be done by platform logic such as ACPI _PR3.
To support wakeup from D3cold, a system may provide auxiliary power, which
allows a device to request wakeup using a Beacon or the sideband WAKE#
signal. WAKE# is usually connected to platform logic such as ACPI GPE.
This is quite different from other power saving states, where devices
request wakeup via a PME message on the PCIe link.
Some devices, such as those in plug-in slots, have no direct platform
logic. For example, there is usually no ACPI _PR3 for them. D3cold
support for these devices can be done via the PCIe Downstream Port leading
to the device. When the PCIe port is powered on/off, the device is powered
on/off too. Wakeup events from the device will be notified to the
corresponding PCIe port.
For more information about PCIe D3cold and corresponding ACPI support,
please refer to:
- PCI Express Base Specification Revision 2.0
- Advanced Configuration and Power Interface Specification Revision 5.0
[bhelgaas: changelog]
Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
Originally-by: Zheng Yan <zheng.z.yan@intel.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-06-23 02:23:51 +00:00
|
|
|
if (pci_dev->current_state == PCI_D3cold) {
|
|
|
|
pci_wakeup_event(pci_dev);
|
|
|
|
pm_runtime_resume(&pci_dev->dev);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2011-11-06 21:21:46 +00:00
|
|
|
if (!pci_dev->pm_cap || !pci_dev->pme_support
|
|
|
|
|| pci_check_pme_status(pci_dev)) {
|
PCI / PM: Extend PME polling to all PCI devices
The land of PCI power management is a land of sorrow and ugliness,
especially in the area of signaling events by devices. There are
devices that set their PME Status bits, but don't really bother
to send a PME message or assert PME#. There are hardware vendors
who don't connect PME# lines to the system core logic (they know
who they are). There are PCI Express Root Ports that don't bother
to trigger interrupts when they receive PME messages from the devices
below. There are ACPI BIOSes that forget to provide _PRW methods for
devices capable of signaling wakeup. Finally, there are BIOSes that
do provide _PRW methods for such devices, but then don't bother to
call Notify() for those devices from the corresponding _Lxx/_Exx
GPE-handling methods. In all of these cases the kernel doesn't have
a chance to receive a proper notification that it should wake up a
device, so devices stay in low-power states forever. Worse yet, in
some cases they continuously send PME Messages that are silently
ignored, because the kernel simply doesn't know that it should clear
the device's PME Status bit.
This problem was first observed for "parallel" (non-Express) PCI
devices on add-on cards and Matthew Garrett addressed it by adding
code that polls PME Status bits of such devices, if they are enabled
to signal PME, to the kernel. Recently, however, it has turned out
that PCI Express devices are also affected by this issue and that it
is not limited to add-on devices, so it seems necessary to extend
the PME polling to all PCI devices, including PCI Express and planar
ones. Still, it would be wasteful to poll the PME Status bits of
devices that are known to receive proper PME notifications, so make
the kernel (1) poll the PME Status bits of all PCI and PCIe devices
enabled to signal PME and (2) disable the PME Status polling for
devices for which correct PME notifications are received.
Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2011-10-03 21:16:33 +00:00
|
|
|
if (pci_dev->pme_poll)
|
|
|
|
pci_dev->pme_poll = false;
|
|
|
|
|
2010-12-29 12:22:08 +00:00
|
|
|
pci_wakeup_event(pci_dev);
|
2010-02-17 22:44:09 +00:00
|
|
|
pm_runtime_resume(&pci_dev->dev);
|
|
|
|
}
|
2011-11-06 21:21:46 +00:00
|
|
|
|
|
|
|
if (pci_dev->subordinate)
|
|
|
|
pci_pme_wakeup_bus(pci_dev->subordinate);
|
2010-02-17 22:44:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_acpi_add_bus_pm_notifier - Register PM notifier for given PCI bus.
|
|
|
|
* @dev: ACPI device to add the notifier for.
|
|
|
|
* @pci_bus: PCI bus to walk checking for PME status if an event is signaled.
|
|
|
|
*/
|
|
|
|
acpi_status pci_acpi_add_bus_pm_notifier(struct acpi_device *dev,
|
|
|
|
struct pci_bus *pci_bus)
|
|
|
|
{
|
2012-11-02 00:40:09 +00:00
|
|
|
return acpi_add_pm_notifier(dev, pci_acpi_wake_bus, pci_bus);
|
2010-02-17 22:44:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_acpi_remove_bus_pm_notifier - Unregister PCI bus PM notifier.
|
|
|
|
* @dev: ACPI device to remove the notifier from.
|
|
|
|
*/
|
|
|
|
acpi_status pci_acpi_remove_bus_pm_notifier(struct acpi_device *dev)
|
|
|
|
{
|
2012-11-02 00:40:09 +00:00
|
|
|
return acpi_remove_pm_notifier(dev, pci_acpi_wake_bus);
|
2010-02-17 22:44:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_acpi_add_pm_notifier - Register PM notifier for given PCI device.
|
|
|
|
* @dev: ACPI device to add the notifier for.
|
|
|
|
* @pci_dev: PCI device to check for the PME status if an event is signaled.
|
|
|
|
*/
|
|
|
|
acpi_status pci_acpi_add_pm_notifier(struct acpi_device *dev,
|
|
|
|
struct pci_dev *pci_dev)
|
|
|
|
{
|
2012-11-02 00:40:09 +00:00
|
|
|
return acpi_add_pm_notifier(dev, pci_acpi_wake_dev, pci_dev);
|
2010-02-17 22:44:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_acpi_remove_pm_notifier - Unregister PCI device PM notifier.
|
|
|
|
* @dev: ACPI device to remove the notifier from.
|
|
|
|
*/
|
|
|
|
acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
|
|
|
|
{
|
2012-11-02 00:40:09 +00:00
|
|
|
return acpi_remove_pm_notifier(dev, pci_acpi_wake_dev);
|
2010-02-17 22:44:09 +00:00
|
|
|
}
|
|
|
|
|
2012-06-22 06:55:16 +00:00
|
|
|
phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle)
|
|
|
|
{
|
|
|
|
acpi_status status = AE_NOT_EXIST;
|
|
|
|
unsigned long long mcfg_addr;
|
|
|
|
|
|
|
|
if (handle)
|
|
|
|
status = acpi_evaluate_integer(handle, METHOD_NAME__CBA,
|
|
|
|
NULL, &mcfg_addr);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return (phys_addr_t)mcfg_addr;
|
|
|
|
}
|
|
|
|
|
2005-03-19 05:15:48 +00:00
|
|
|
/*
|
|
|
|
* _SxD returns the D-state with the highest power
|
|
|
|
* (lowest D-state number) supported in the S-state "x".
|
|
|
|
*
|
|
|
|
* If the devices does not have a _PRW
|
|
|
|
* (Power Resources for Wake) supporting system wakeup from "x"
|
|
|
|
* then the OS is free to choose a lower power (higher number
|
|
|
|
* D-state) than the return value from _SxD.
|
|
|
|
*
|
|
|
|
* But if _PRW is enabled at S-state "x", the OS
|
|
|
|
* must not choose a power lower than _SxD --
|
|
|
|
* unless the device has an _SxW method specifying
|
|
|
|
* the lowest power (highest D-state number) the device
|
|
|
|
* may enter while still able to wake the system.
|
|
|
|
*
|
|
|
|
* ie. depending on global OS policy:
|
|
|
|
*
|
|
|
|
* if (_PRW at S-state x)
|
|
|
|
* choose from highest power _SxD to lowest power _SxW
|
|
|
|
* else // no _PRW at S-state x
|
|
|
|
* choose highest power _SxD or any lower power
|
|
|
|
*/
|
|
|
|
|
2008-06-04 23:16:37 +00:00
|
|
|
static pci_power_t acpi_pci_choose_state(struct pci_dev *pdev)
|
2005-03-19 05:15:48 +00:00
|
|
|
{
|
PCI/PM: add PCIe runtime D3cold support
This patch adds runtime D3cold support and corresponding ACPI platform
support. This patch only enables runtime D3cold support; it does not
enable D3cold support during system suspend/hibernate.
D3cold is the deepest power saving state for a PCIe device, where its main
power is removed. While it is in D3cold, you can't access the device at
all, not even its configuration space (which is still accessible in D3hot).
Therefore the PCI PM registers can not be used to transition into/out of
the D3cold state; that must be done by platform logic such as ACPI _PR3.
To support wakeup from D3cold, a system may provide auxiliary power, which
allows a device to request wakeup using a Beacon or the sideband WAKE#
signal. WAKE# is usually connected to platform logic such as ACPI GPE.
This is quite different from other power saving states, where devices
request wakeup via a PME message on the PCIe link.
Some devices, such as those in plug-in slots, have no direct platform
logic. For example, there is usually no ACPI _PR3 for them. D3cold
support for these devices can be done via the PCIe Downstream Port leading
to the device. When the PCIe port is powered on/off, the device is powered
on/off too. Wakeup events from the device will be notified to the
corresponding PCIe port.
For more information about PCIe D3cold and corresponding ACPI support,
please refer to:
- PCI Express Base Specification Revision 2.0
- Advanced Configuration and Power Interface Specification Revision 5.0
[bhelgaas: changelog]
Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
Originally-by: Zheng Yan <zheng.z.yan@intel.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-06-23 02:23:51 +00:00
|
|
|
int acpi_state, d_max;
|
2005-03-19 05:15:48 +00:00
|
|
|
|
PCI/PM: add PCIe runtime D3cold support
This patch adds runtime D3cold support and corresponding ACPI platform
support. This patch only enables runtime D3cold support; it does not
enable D3cold support during system suspend/hibernate.
D3cold is the deepest power saving state for a PCIe device, where its main
power is removed. While it is in D3cold, you can't access the device at
all, not even its configuration space (which is still accessible in D3hot).
Therefore the PCI PM registers can not be used to transition into/out of
the D3cold state; that must be done by platform logic such as ACPI _PR3.
To support wakeup from D3cold, a system may provide auxiliary power, which
allows a device to request wakeup using a Beacon or the sideband WAKE#
signal. WAKE# is usually connected to platform logic such as ACPI GPE.
This is quite different from other power saving states, where devices
request wakeup via a PME message on the PCIe link.
Some devices, such as those in plug-in slots, have no direct platform
logic. For example, there is usually no ACPI _PR3 for them. D3cold
support for these devices can be done via the PCIe Downstream Port leading
to the device. When the PCIe port is powered on/off, the device is powered
on/off too. Wakeup events from the device will be notified to the
corresponding PCIe port.
For more information about PCIe D3cold and corresponding ACPI support,
please refer to:
- PCI Express Base Specification Revision 2.0
- Advanced Configuration and Power Interface Specification Revision 5.0
[bhelgaas: changelog]
Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
Originally-by: Zheng Yan <zheng.z.yan@intel.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-06-23 02:23:51 +00:00
|
|
|
if (pdev->no_d3cold)
|
|
|
|
d_max = ACPI_STATE_D3_HOT;
|
|
|
|
else
|
|
|
|
d_max = ACPI_STATE_D3_COLD;
|
|
|
|
acpi_state = acpi_pm_device_sleep_state(&pdev->dev, NULL, d_max);
|
2007-07-20 02:03:22 +00:00
|
|
|
if (acpi_state < 0)
|
|
|
|
return PCI_POWER_ERROR;
|
|
|
|
|
|
|
|
switch (acpi_state) {
|
|
|
|
case ACPI_STATE_D0:
|
|
|
|
return PCI_D0;
|
|
|
|
case ACPI_STATE_D1:
|
|
|
|
return PCI_D1;
|
|
|
|
case ACPI_STATE_D2:
|
|
|
|
return PCI_D2;
|
2012-04-23 01:03:49 +00:00
|
|
|
case ACPI_STATE_D3_HOT:
|
2007-07-20 02:03:22 +00:00
|
|
|
return PCI_D3hot;
|
2011-05-04 14:56:43 +00:00
|
|
|
case ACPI_STATE_D3_COLD:
|
|
|
|
return PCI_D3cold;
|
2007-07-20 02:03:22 +00:00
|
|
|
}
|
|
|
|
return PCI_POWER_ERROR;
|
2005-03-19 05:15:48 +00:00
|
|
|
}
|
2008-07-07 01:32:02 +00:00
|
|
|
|
|
|
|
static bool acpi_pci_power_manageable(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
acpi_handle handle = DEVICE_ACPI_HANDLE(&dev->dev);
|
|
|
|
|
|
|
|
return handle ? acpi_bus_power_manageable(handle) : false;
|
|
|
|
}
|
2005-03-19 05:15:48 +00:00
|
|
|
|
2005-03-19 05:16:18 +00:00
|
|
|
static int acpi_pci_set_power_state(struct pci_dev *dev, pci_power_t state)
|
|
|
|
{
|
|
|
|
acpi_handle handle = DEVICE_ACPI_HANDLE(&dev->dev);
|
2007-07-20 02:03:25 +00:00
|
|
|
acpi_handle tmp;
|
2008-02-23 05:41:51 +00:00
|
|
|
static const u8 state_conv[] = {
|
|
|
|
[PCI_D0] = ACPI_STATE_D0,
|
|
|
|
[PCI_D1] = ACPI_STATE_D1,
|
|
|
|
[PCI_D2] = ACPI_STATE_D2,
|
ACPI / PCI / PM: Fix device PM regression related to D3hot/D3cold
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 <rockorequin@hotmail.com>
Reported-by: Cristian Rodríguez <crrodriguez@opensuse.org>
Reported-and-tested-by: Peter <lekensteyn@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-05-17 22:39:35 +00:00
|
|
|
[PCI_D3hot] = ACPI_STATE_D3,
|
2008-02-23 05:41:51 +00:00
|
|
|
[PCI_D3cold] = ACPI_STATE_D3
|
2005-03-19 05:16:18 +00:00
|
|
|
};
|
2008-07-07 01:32:52 +00:00
|
|
|
int error = -EINVAL;
|
2005-03-19 05:16:18 +00:00
|
|
|
|
2007-07-20 02:03:25 +00:00
|
|
|
/* If the ACPI device has _EJ0, ignore the device */
|
2008-07-07 01:32:52 +00:00
|
|
|
if (!handle || ACPI_SUCCESS(acpi_get_handle(handle, "_EJ0", &tmp)))
|
|
|
|
return -ENODEV;
|
2008-02-23 05:41:51 +00:00
|
|
|
|
|
|
|
switch (state) {
|
2012-10-24 00:08:38 +00:00
|
|
|
case PCI_D3cold:
|
|
|
|
if (dev_pm_qos_flags(&dev->dev, PM_QOS_FLAG_NO_POWER_OFF) ==
|
|
|
|
PM_QOS_FLAGS_ALL) {
|
|
|
|
error = -EBUSY;
|
|
|
|
break;
|
|
|
|
}
|
2008-02-23 05:41:51 +00:00
|
|
|
case PCI_D0:
|
|
|
|
case PCI_D1:
|
|
|
|
case PCI_D2:
|
|
|
|
case PCI_D3hot:
|
2008-07-07 01:32:52 +00:00
|
|
|
error = acpi_bus_set_power(handle, state_conv[state]);
|
2008-02-23 05:41:51 +00:00
|
|
|
}
|
2008-07-07 01:32:52 +00:00
|
|
|
|
|
|
|
if (!error)
|
2012-08-04 21:27:32 +00:00
|
|
|
dev_info(&dev->dev, "power state changed by ACPI to %s\n",
|
|
|
|
pci_power_name(state));
|
2008-07-07 01:32:52 +00:00
|
|
|
|
|
|
|
return error;
|
2005-03-19 05:16:18 +00:00
|
|
|
}
|
|
|
|
|
2008-07-07 01:34:48 +00:00
|
|
|
static bool acpi_pci_can_wakeup(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
acpi_handle handle = DEVICE_ACPI_HANDLE(&dev->dev);
|
|
|
|
|
|
|
|
return handle ? acpi_bus_can_wakeup(handle) : false;
|
|
|
|
}
|
|
|
|
|
PCI / ACPI PM: Propagate wake-up enable for devices w/o ACPI support
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 <mjg59@srcf.ucam.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-09-08 21:16:24 +00:00
|
|
|
static void acpi_pci_propagate_wakeup_enable(struct pci_bus *bus, bool enable)
|
|
|
|
{
|
|
|
|
while (bus->parent) {
|
2009-11-29 15:35:54 +00:00
|
|
|
if (!acpi_pm_device_sleep_wake(&bus->self->dev, enable))
|
PCI / ACPI PM: Propagate wake-up enable for devices w/o ACPI support
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 <mjg59@srcf.ucam.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-09-08 21:16:24 +00:00
|
|
|
return;
|
|
|
|
bus = bus->parent;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We have reached the root bus. */
|
|
|
|
if (bus->bridge)
|
|
|
|
acpi_pm_device_sleep_wake(bus->bridge, enable);
|
|
|
|
}
|
|
|
|
|
2008-07-07 01:34:48 +00:00
|
|
|
static int acpi_pci_sleep_wake(struct pci_dev *dev, bool enable)
|
|
|
|
{
|
PCI / ACPI PM: Propagate wake-up enable for devices w/o ACPI support
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 <mjg59@srcf.ucam.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-09-08 21:16:24 +00:00
|
|
|
if (acpi_pci_can_wakeup(dev))
|
|
|
|
return acpi_pm_device_sleep_wake(&dev->dev, enable);
|
|
|
|
|
2009-11-29 15:35:54 +00:00
|
|
|
acpi_pci_propagate_wakeup_enable(dev->bus, enable);
|
PCI / ACPI PM: Propagate wake-up enable for devices w/o ACPI support
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 <mjg59@srcf.ucam.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-09-08 21:16:24 +00:00
|
|
|
return 0;
|
2008-07-07 01:34:48 +00:00
|
|
|
}
|
|
|
|
|
2010-02-17 22:44:09 +00:00
|
|
|
static void acpi_pci_propagate_run_wake(struct pci_bus *bus, bool enable)
|
|
|
|
{
|
|
|
|
while (bus->parent) {
|
|
|
|
struct pci_dev *bridge = bus->self;
|
|
|
|
|
|
|
|
if (bridge->pme_interrupt)
|
|
|
|
return;
|
2012-03-27 07:43:25 +00:00
|
|
|
if (!acpi_pm_device_run_wake(&bridge->dev, enable))
|
2010-02-17 22:44:09 +00:00
|
|
|
return;
|
|
|
|
bus = bus->parent;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We have reached the root bus. */
|
|
|
|
if (bus->bridge)
|
2012-03-27 07:43:25 +00:00
|
|
|
acpi_pm_device_run_wake(bus->bridge, enable);
|
2010-02-17 22:44:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_pci_run_wake(struct pci_dev *dev, bool enable)
|
|
|
|
{
|
PCI/PM: add PCIe runtime D3cold support
This patch adds runtime D3cold support and corresponding ACPI platform
support. This patch only enables runtime D3cold support; it does not
enable D3cold support during system suspend/hibernate.
D3cold is the deepest power saving state for a PCIe device, where its main
power is removed. While it is in D3cold, you can't access the device at
all, not even its configuration space (which is still accessible in D3hot).
Therefore the PCI PM registers can not be used to transition into/out of
the D3cold state; that must be done by platform logic such as ACPI _PR3.
To support wakeup from D3cold, a system may provide auxiliary power, which
allows a device to request wakeup using a Beacon or the sideband WAKE#
signal. WAKE# is usually connected to platform logic such as ACPI GPE.
This is quite different from other power saving states, where devices
request wakeup via a PME message on the PCIe link.
Some devices, such as those in plug-in slots, have no direct platform
logic. For example, there is usually no ACPI _PR3 for them. D3cold
support for these devices can be done via the PCIe Downstream Port leading
to the device. When the PCIe port is powered on/off, the device is powered
on/off too. Wakeup events from the device will be notified to the
corresponding PCIe port.
For more information about PCIe D3cold and corresponding ACPI support,
please refer to:
- PCI Express Base Specification Revision 2.0
- Advanced Configuration and Power Interface Specification Revision 5.0
[bhelgaas: changelog]
Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
Originally-by: Zheng Yan <zheng.z.yan@intel.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-06-23 02:23:51 +00:00
|
|
|
/*
|
|
|
|
* Per PCI Express Base Specification Revision 2.0 section
|
|
|
|
* 5.3.3.2 Link Wakeup, platform support is needed for D3cold
|
|
|
|
* waking up to power on the main link even if there is PME
|
|
|
|
* support for D3cold
|
|
|
|
*/
|
|
|
|
if (dev->pme_interrupt && !dev->runtime_d3cold)
|
2010-02-17 22:44:09 +00:00
|
|
|
return 0;
|
|
|
|
|
2012-03-27 07:43:25 +00:00
|
|
|
if (!acpi_pm_device_run_wake(&dev->dev, enable))
|
2010-02-17 22:44:09 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
acpi_pci_propagate_run_wake(dev->bus, enable);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-07-07 01:32:02 +00:00
|
|
|
static struct pci_platform_pm_ops acpi_pci_platform_pm = {
|
|
|
|
.is_manageable = acpi_pci_power_manageable,
|
|
|
|
.set_state = acpi_pci_set_power_state,
|
|
|
|
.choose_state = acpi_pci_choose_state,
|
2008-07-07 01:34:48 +00:00
|
|
|
.can_wakeup = acpi_pci_can_wakeup,
|
|
|
|
.sleep_wake = acpi_pci_sleep_wake,
|
2010-02-17 22:44:09 +00:00
|
|
|
.run_wake = acpi_pci_run_wake,
|
2008-07-07 01:32:02 +00:00
|
|
|
};
|
2005-03-19 05:16:18 +00:00
|
|
|
|
2005-03-18 23:53:36 +00:00
|
|
|
/* ACPI bus type */
|
2006-04-28 07:42:21 +00:00
|
|
|
static int acpi_pci_find_device(struct device *dev, acpi_handle *handle)
|
2005-03-18 23:53:36 +00:00
|
|
|
{
|
|
|
|
struct pci_dev * pci_dev;
|
2010-01-28 02:53:19 +00:00
|
|
|
u64 addr;
|
2005-03-18 23:53:36 +00:00
|
|
|
|
|
|
|
pci_dev = to_pci_dev(dev);
|
|
|
|
/* Please ref to ACPI spec for the syntax of _ADR */
|
|
|
|
addr = (PCI_SLOT(pci_dev->devfn) << 16) | PCI_FUNC(pci_dev->devfn);
|
|
|
|
*handle = acpi_get_child(DEVICE_ACPI_HANDLE(dev->parent), addr);
|
|
|
|
if (!*handle)
|
|
|
|
return -ENODEV;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-04-28 07:42:21 +00:00
|
|
|
static int acpi_pci_find_root_bridge(struct device *dev, acpi_handle *handle)
|
2005-03-18 23:53:36 +00:00
|
|
|
{
|
|
|
|
int num;
|
|
|
|
unsigned int seg, bus;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The string should be the same as root bridge's name
|
|
|
|
* Please look at 'pci_scan_bus_parented'
|
|
|
|
*/
|
2008-10-30 01:17:49 +00:00
|
|
|
num = sscanf(dev_name(dev), "pci%04x:%02x", &seg, &bus);
|
2005-03-18 23:53:36 +00:00
|
|
|
if (num != 2)
|
|
|
|
return -ENODEV;
|
|
|
|
*handle = acpi_get_pci_rootbridge_handle(seg, bus);
|
|
|
|
if (!*handle)
|
|
|
|
return -ENODEV;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2006-04-28 07:42:21 +00:00
|
|
|
static struct acpi_bus_type acpi_pci_bus = {
|
2005-03-18 23:53:36 +00:00
|
|
|
.bus = &pci_bus_type,
|
2006-04-28 07:42:21 +00:00
|
|
|
.find_device = acpi_pci_find_device,
|
|
|
|
.find_bridge = acpi_pci_find_root_bridge,
|
2005-03-18 23:53:36 +00:00
|
|
|
};
|
|
|
|
|
2006-04-28 07:42:21 +00:00
|
|
|
static int __init acpi_pci_init(void)
|
2005-03-18 23:53:36 +00:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2009-02-03 07:14:33 +00:00
|
|
|
if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) {
|
2007-04-25 03:05:12 +00:00
|
|
|
printk(KERN_INFO"ACPI FADT declares the system doesn't support MSI, so disable it\n");
|
|
|
|
pci_no_msi();
|
|
|
|
}
|
2008-07-23 02:32:24 +00:00
|
|
|
|
2009-02-03 07:14:33 +00:00
|
|
|
if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_ASPM) {
|
2008-07-23 02:32:24 +00:00
|
|
|
printk(KERN_INFO"ACPI FADT declares the system doesn't support PCIe ASPM, so disable it\n");
|
|
|
|
pcie_no_aspm();
|
|
|
|
}
|
|
|
|
|
2006-04-28 07:42:21 +00:00
|
|
|
ret = register_acpi_bus_type(&acpi_pci_bus);
|
2005-03-18 23:53:36 +00:00
|
|
|
if (ret)
|
|
|
|
return 0;
|
2008-07-07 01:32:02 +00:00
|
|
|
pci_set_platform_pm(&acpi_pci_platform_pm);
|
2005-03-18 23:53:36 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2006-04-28 07:42:21 +00:00
|
|
|
arch_initcall(acpi_pci_init);
|