2005-04-17 02:20:36 +04:00
|
|
|
/*
|
|
|
|
* File: pci-acpi.c
|
2005-03-24 00:16:03 +03:00
|
|
|
* Purpose: Provide PCI support in ACPI
|
2005-04-17 02:20:36 +04:00
|
|
|
*
|
2005-03-19 02:53:36 +03: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-17 02:20:36 +04:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/pci.h>
|
2014-09-13 01:23:14 +04:00
|
|
|
#include <linux/pci_hotplug.h>
|
2005-04-17 02:20:36 +04:00
|
|
|
#include <linux/module.h>
|
2008-07-23 06:32:24 +04:00
|
|
|
#include <linux/pci-aspm.h>
|
2005-04-17 02:20:36 +04:00
|
|
|
#include <linux/pci-acpi.h>
|
2010-02-18 01:44:09 +03:00
|
|
|
#include <linux/pm_runtime.h>
|
2012-10-24 04:08:38 +04:00
|
|
|
#include <linux/pm_qos.h>
|
2005-03-19 08:15:48 +03:00
|
|
|
#include "pci.h"
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2012-06-22 10:55:16 +04: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;
|
|
|
|
}
|
|
|
|
|
2014-09-13 01:29:55 +04:00
|
|
|
static acpi_status decode_type0_hpx_record(union acpi_object *record,
|
|
|
|
struct hotplug_params *hpx)
|
2014-09-13 01:23:14 +04:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
union acpi_object *fields = record->package.elements;
|
|
|
|
u32 revision = fields[1].integer.value;
|
|
|
|
|
|
|
|
switch (revision) {
|
|
|
|
case 1:
|
|
|
|
if (record->package.count != 6)
|
|
|
|
return AE_ERROR;
|
|
|
|
for (i = 2; i < 6; i++)
|
|
|
|
if (fields[i].type != ACPI_TYPE_INTEGER)
|
|
|
|
return AE_ERROR;
|
|
|
|
hpx->t0 = &hpx->type0_data;
|
|
|
|
hpx->t0->revision = revision;
|
|
|
|
hpx->t0->cache_line_size = fields[2].integer.value;
|
|
|
|
hpx->t0->latency_timer = fields[3].integer.value;
|
|
|
|
hpx->t0->enable_serr = fields[4].integer.value;
|
|
|
|
hpx->t0->enable_perr = fields[5].integer.value;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
printk(KERN_WARNING
|
|
|
|
"%s: Type 0 Revision %d record not supported\n",
|
|
|
|
__func__, revision);
|
|
|
|
return AE_ERROR;
|
|
|
|
}
|
|
|
|
return AE_OK;
|
|
|
|
}
|
|
|
|
|
2014-09-13 01:29:55 +04:00
|
|
|
static acpi_status decode_type1_hpx_record(union acpi_object *record,
|
|
|
|
struct hotplug_params *hpx)
|
2014-09-13 01:23:14 +04:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
union acpi_object *fields = record->package.elements;
|
|
|
|
u32 revision = fields[1].integer.value;
|
|
|
|
|
|
|
|
switch (revision) {
|
|
|
|
case 1:
|
|
|
|
if (record->package.count != 5)
|
|
|
|
return AE_ERROR;
|
|
|
|
for (i = 2; i < 5; i++)
|
|
|
|
if (fields[i].type != ACPI_TYPE_INTEGER)
|
|
|
|
return AE_ERROR;
|
|
|
|
hpx->t1 = &hpx->type1_data;
|
|
|
|
hpx->t1->revision = revision;
|
|
|
|
hpx->t1->max_mem_read = fields[2].integer.value;
|
|
|
|
hpx->t1->avg_max_split = fields[3].integer.value;
|
|
|
|
hpx->t1->tot_max_split = fields[4].integer.value;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
printk(KERN_WARNING
|
|
|
|
"%s: Type 1 Revision %d record not supported\n",
|
|
|
|
__func__, revision);
|
|
|
|
return AE_ERROR;
|
|
|
|
}
|
|
|
|
return AE_OK;
|
|
|
|
}
|
|
|
|
|
2014-09-13 01:29:55 +04:00
|
|
|
static acpi_status decode_type2_hpx_record(union acpi_object *record,
|
|
|
|
struct hotplug_params *hpx)
|
2014-09-13 01:23:14 +04:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
union acpi_object *fields = record->package.elements;
|
|
|
|
u32 revision = fields[1].integer.value;
|
|
|
|
|
|
|
|
switch (revision) {
|
|
|
|
case 1:
|
|
|
|
if (record->package.count != 18)
|
|
|
|
return AE_ERROR;
|
|
|
|
for (i = 2; i < 18; i++)
|
|
|
|
if (fields[i].type != ACPI_TYPE_INTEGER)
|
|
|
|
return AE_ERROR;
|
|
|
|
hpx->t2 = &hpx->type2_data;
|
|
|
|
hpx->t2->revision = revision;
|
|
|
|
hpx->t2->unc_err_mask_and = fields[2].integer.value;
|
|
|
|
hpx->t2->unc_err_mask_or = fields[3].integer.value;
|
|
|
|
hpx->t2->unc_err_sever_and = fields[4].integer.value;
|
|
|
|
hpx->t2->unc_err_sever_or = fields[5].integer.value;
|
|
|
|
hpx->t2->cor_err_mask_and = fields[6].integer.value;
|
|
|
|
hpx->t2->cor_err_mask_or = fields[7].integer.value;
|
|
|
|
hpx->t2->adv_err_cap_and = fields[8].integer.value;
|
|
|
|
hpx->t2->adv_err_cap_or = fields[9].integer.value;
|
|
|
|
hpx->t2->pci_exp_devctl_and = fields[10].integer.value;
|
|
|
|
hpx->t2->pci_exp_devctl_or = fields[11].integer.value;
|
|
|
|
hpx->t2->pci_exp_lnkctl_and = fields[12].integer.value;
|
|
|
|
hpx->t2->pci_exp_lnkctl_or = fields[13].integer.value;
|
|
|
|
hpx->t2->sec_unc_err_sever_and = fields[14].integer.value;
|
|
|
|
hpx->t2->sec_unc_err_sever_or = fields[15].integer.value;
|
|
|
|
hpx->t2->sec_unc_err_mask_and = fields[16].integer.value;
|
|
|
|
hpx->t2->sec_unc_err_mask_or = fields[17].integer.value;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
printk(KERN_WARNING
|
|
|
|
"%s: Type 2 Revision %d record not supported\n",
|
|
|
|
__func__, revision);
|
|
|
|
return AE_ERROR;
|
|
|
|
}
|
|
|
|
return AE_OK;
|
|
|
|
}
|
|
|
|
|
2014-09-13 01:29:55 +04:00
|
|
|
static acpi_status acpi_run_hpx(acpi_handle handle, struct hotplug_params *hpx)
|
2014-09-13 01:23:14 +04:00
|
|
|
{
|
|
|
|
acpi_status status;
|
|
|
|
struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
|
|
|
|
union acpi_object *package, *record, *fields;
|
|
|
|
u32 type;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* Clear the return buffer with zeros */
|
|
|
|
memset(hpx, 0, sizeof(struct hotplug_params));
|
|
|
|
|
|
|
|
status = acpi_evaluate_object(handle, "_HPX", NULL, &buffer);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return status;
|
|
|
|
|
|
|
|
package = (union acpi_object *)buffer.pointer;
|
|
|
|
if (package->type != ACPI_TYPE_PACKAGE) {
|
|
|
|
status = AE_ERROR;
|
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < package->package.count; i++) {
|
|
|
|
record = &package->package.elements[i];
|
|
|
|
if (record->type != ACPI_TYPE_PACKAGE) {
|
|
|
|
status = AE_ERROR;
|
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
fields = record->package.elements;
|
|
|
|
if (fields[0].type != ACPI_TYPE_INTEGER ||
|
|
|
|
fields[1].type != ACPI_TYPE_INTEGER) {
|
|
|
|
status = AE_ERROR;
|
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
type = fields[0].integer.value;
|
|
|
|
switch (type) {
|
|
|
|
case 0:
|
|
|
|
status = decode_type0_hpx_record(record, hpx);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
goto exit;
|
|
|
|
break;
|
|
|
|
case 1:
|
|
|
|
status = decode_type1_hpx_record(record, hpx);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
goto exit;
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
status = decode_type2_hpx_record(record, hpx);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
goto exit;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
printk(KERN_ERR "%s: Type %d record not supported\n",
|
|
|
|
__func__, type);
|
|
|
|
status = AE_ERROR;
|
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
exit:
|
|
|
|
kfree(buffer.pointer);
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2014-09-13 01:29:55 +04:00
|
|
|
static acpi_status acpi_run_hpp(acpi_handle handle, struct hotplug_params *hpp)
|
2014-09-13 01:23:14 +04:00
|
|
|
{
|
|
|
|
acpi_status status;
|
|
|
|
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
|
|
|
|
union acpi_object *package, *fields;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
memset(hpp, 0, sizeof(struct hotplug_params));
|
|
|
|
|
|
|
|
status = acpi_evaluate_object(handle, "_HPP", NULL, &buffer);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return status;
|
|
|
|
|
|
|
|
package = (union acpi_object *) buffer.pointer;
|
|
|
|
if (package->type != ACPI_TYPE_PACKAGE ||
|
|
|
|
package->package.count != 4) {
|
|
|
|
status = AE_ERROR;
|
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
fields = package->package.elements;
|
|
|
|
for (i = 0; i < 4; i++) {
|
|
|
|
if (fields[i].type != ACPI_TYPE_INTEGER) {
|
|
|
|
status = AE_ERROR;
|
|
|
|
goto exit;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
hpp->t0 = &hpp->type0_data;
|
|
|
|
hpp->t0->revision = 1;
|
|
|
|
hpp->t0->cache_line_size = fields[0].integer.value;
|
|
|
|
hpp->t0->latency_timer = fields[1].integer.value;
|
|
|
|
hpp->t0->enable_serr = fields[2].integer.value;
|
|
|
|
hpp->t0->enable_perr = fields[3].integer.value;
|
|
|
|
|
|
|
|
exit:
|
|
|
|
kfree(buffer.pointer);
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* pci_get_hp_params
|
|
|
|
*
|
|
|
|
* @dev - the pci_dev for which we want parameters
|
|
|
|
* @hpp - allocated by the caller
|
|
|
|
*/
|
|
|
|
int pci_get_hp_params(struct pci_dev *dev, struct hotplug_params *hpp)
|
|
|
|
{
|
|
|
|
acpi_status status;
|
|
|
|
acpi_handle handle, phandle;
|
|
|
|
struct pci_bus *pbus;
|
|
|
|
|
|
|
|
handle = NULL;
|
|
|
|
for (pbus = dev->bus; pbus; pbus = pbus->parent) {
|
|
|
|
handle = acpi_pci_get_bridge_handle(pbus);
|
|
|
|
if (handle)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* _HPP settings apply to all child buses, until another _HPP is
|
|
|
|
* encountered. If we don't find an _HPP for the input pci dev,
|
|
|
|
* look for it in the parent device scope since that would apply to
|
|
|
|
* this pci dev.
|
|
|
|
*/
|
|
|
|
while (handle) {
|
|
|
|
status = acpi_run_hpx(handle, hpp);
|
|
|
|
if (ACPI_SUCCESS(status))
|
|
|
|
return 0;
|
|
|
|
status = acpi_run_hpp(handle, hpp);
|
|
|
|
if (ACPI_SUCCESS(status))
|
|
|
|
return 0;
|
|
|
|
if (acpi_is_root_bridge(handle))
|
|
|
|
break;
|
|
|
|
status = acpi_get_parent(handle, &phandle);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
break;
|
|
|
|
handle = phandle;
|
|
|
|
}
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pci_get_hp_params);
|
|
|
|
|
2014-09-13 01:36:29 +04:00
|
|
|
/**
|
|
|
|
* pci_acpi_wake_bus - Root bus wakeup notification fork function.
|
|
|
|
* @work: Work item to handle.
|
|
|
|
*/
|
|
|
|
static void pci_acpi_wake_bus(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev;
|
|
|
|
struct acpi_pci_root *root;
|
|
|
|
|
|
|
|
adev = container_of(work, struct acpi_device, wakeup.context.work);
|
|
|
|
root = acpi_driver_data(adev);
|
|
|
|
pci_pme_wakeup_bus(root->bus);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_acpi_wake_dev - PCI device wakeup notification work function.
|
|
|
|
* @handle: ACPI handle of a device the notification is for.
|
|
|
|
* @work: Work item to handle.
|
|
|
|
*/
|
|
|
|
static void pci_acpi_wake_dev(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct acpi_device_wakeup_context *context;
|
|
|
|
struct pci_dev *pci_dev;
|
|
|
|
|
|
|
|
context = container_of(work, struct acpi_device_wakeup_context, work);
|
|
|
|
pci_dev = to_pci_dev(context->dev);
|
|
|
|
|
|
|
|
if (pci_dev->pme_poll)
|
|
|
|
pci_dev->pme_poll = false;
|
|
|
|
|
|
|
|
if (pci_dev->current_state == PCI_D3cold) {
|
|
|
|
pci_wakeup_event(pci_dev);
|
|
|
|
pm_runtime_resume(&pci_dev->dev);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Clear PME Status if set. */
|
|
|
|
if (pci_dev->pme_support)
|
|
|
|
pci_check_pme_status(pci_dev);
|
|
|
|
|
|
|
|
pci_wakeup_event(pci_dev);
|
|
|
|
pm_runtime_resume(&pci_dev->dev);
|
|
|
|
|
2014-11-11 07:02:17 +03:00
|
|
|
pci_pme_wakeup_bus(pci_dev->subordinate);
|
2014-09-13 01:36:29 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pci_acpi_add_bus_pm_notifier - Register PM notifier for root PCI bus.
|
|
|
|
* @dev: PCI root bridge ACPI device.
|
|
|
|
*/
|
|
|
|
acpi_status pci_acpi_add_bus_pm_notifier(struct acpi_device *dev)
|
|
|
|
{
|
|
|
|
return acpi_add_pm_notifier(dev, NULL, pci_acpi_wake_bus);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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)
|
|
|
|
{
|
|
|
|
return acpi_add_pm_notifier(dev, &pci_dev->dev, pci_acpi_wake_dev);
|
|
|
|
}
|
|
|
|
|
2005-03-19 08:15:48 +03: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
|
2013-11-14 22:28:18 +04:00
|
|
|
* choose highest power _SxD or any lower power
|
2005-03-19 08:15:48 +03:00
|
|
|
*/
|
|
|
|
|
2008-06-05 03:16:37 +04:00
|
|
|
static pci_power_t acpi_pci_choose_state(struct pci_dev *pdev)
|
2005-03-19 08:15:48 +03: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 06:23:51 +04:00
|
|
|
int acpi_state, d_max;
|
2005-03-19 08:15:48 +03: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 06:23:51 +04: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 06:03:22 +04: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 05:03:49 +04:00
|
|
|
case ACPI_STATE_D3_HOT:
|
2007-07-20 06:03:22 +04:00
|
|
|
return PCI_D3hot;
|
2011-05-04 18:56:43 +04:00
|
|
|
case ACPI_STATE_D3_COLD:
|
|
|
|
return PCI_D3cold;
|
2007-07-20 06:03:22 +04:00
|
|
|
}
|
|
|
|
return PCI_POWER_ERROR;
|
2005-03-19 08:15:48 +03:00
|
|
|
}
|
2008-07-07 05:32:02 +04:00
|
|
|
|
|
|
|
static bool acpi_pci_power_manageable(struct pci_dev *dev)
|
|
|
|
{
|
2014-07-24 03:18:53 +04:00
|
|
|
struct acpi_device *adev = ACPI_COMPANION(&dev->dev);
|
|
|
|
return adev ? acpi_device_power_manageable(adev) : false;
|
2008-07-07 05:32:02 +04:00
|
|
|
}
|
2005-03-19 08:15:48 +03:00
|
|
|
|
2005-03-19 08:16:18 +03:00
|
|
|
static int acpi_pci_set_power_state(struct pci_dev *dev, pci_power_t state)
|
|
|
|
{
|
2014-07-24 03:18:53 +04:00
|
|
|
struct acpi_device *adev = ACPI_COMPANION(&dev->dev);
|
2008-02-23 08:41:51 +03:00
|
|
|
static const u8 state_conv[] = {
|
|
|
|
[PCI_D0] = ACPI_STATE_D0,
|
|
|
|
[PCI_D1] = ACPI_STATE_D1,
|
|
|
|
[PCI_D2] = ACPI_STATE_D2,
|
2013-06-14 02:29:50 +04:00
|
|
|
[PCI_D3hot] = ACPI_STATE_D3_COLD,
|
|
|
|
[PCI_D3cold] = ACPI_STATE_D3_COLD,
|
2005-03-19 08:16:18 +03:00
|
|
|
};
|
2008-07-07 05:32:52 +04:00
|
|
|
int error = -EINVAL;
|
2005-03-19 08:16:18 +03:00
|
|
|
|
2007-07-20 06:03:25 +04:00
|
|
|
/* If the ACPI device has _EJ0, ignore the device */
|
2014-07-24 03:18:53 +04:00
|
|
|
if (!adev || acpi_has_method(adev->handle, "_EJ0"))
|
2008-07-07 05:32:52 +04:00
|
|
|
return -ENODEV;
|
2008-02-23 08:41:51 +03:00
|
|
|
|
|
|
|
switch (state) {
|
2012-10-24 04:08:38 +04: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 08:41:51 +03:00
|
|
|
case PCI_D0:
|
|
|
|
case PCI_D1:
|
|
|
|
case PCI_D2:
|
|
|
|
case PCI_D3hot:
|
2014-07-24 03:18:53 +04:00
|
|
|
error = acpi_device_set_power(adev, state_conv[state]);
|
2008-02-23 08:41:51 +03:00
|
|
|
}
|
2008-07-07 05:32:52 +04:00
|
|
|
|
|
|
|
if (!error)
|
2013-07-30 06:32:30 +04:00
|
|
|
dev_dbg(&dev->dev, "power state changed by ACPI to %s\n",
|
2013-06-14 02:29:50 +04:00
|
|
|
acpi_power_state_string(state_conv[state]));
|
2008-07-07 05:32:52 +04:00
|
|
|
|
|
|
|
return error;
|
2005-03-19 08:16:18 +03:00
|
|
|
}
|
|
|
|
|
2008-07-07 05:34:48 +04:00
|
|
|
static bool acpi_pci_can_wakeup(struct pci_dev *dev)
|
|
|
|
{
|
2014-07-24 03:18:53 +04:00
|
|
|
struct acpi_device *adev = ACPI_COMPANION(&dev->dev);
|
|
|
|
return adev ? acpi_device_can_wakeup(adev) : false;
|
2008-07-07 05:34:48 +04:00
|
|
|
}
|
|
|
|
|
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-09 01:16:24 +04:00
|
|
|
static void acpi_pci_propagate_wakeup_enable(struct pci_bus *bus, bool enable)
|
|
|
|
{
|
|
|
|
while (bus->parent) {
|
2009-11-29 18:35:54 +03: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-09 01:16:24 +04: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 05:34:48 +04: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-09 01:16:24 +04:00
|
|
|
if (acpi_pci_can_wakeup(dev))
|
|
|
|
return acpi_pm_device_sleep_wake(&dev->dev, enable);
|
|
|
|
|
2009-11-29 18:35:54 +03: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-09 01:16:24 +04:00
|
|
|
return 0;
|
2008-07-07 05:34:48 +04:00
|
|
|
}
|
|
|
|
|
2010-02-18 01:44:09 +03: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 11:43:25 +04:00
|
|
|
if (!acpi_pm_device_run_wake(&bridge->dev, enable))
|
2010-02-18 01:44:09 +03:00
|
|
|
return;
|
|
|
|
bus = bus->parent;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We have reached the root bus. */
|
|
|
|
if (bus->bridge)
|
2012-03-27 11:43:25 +04:00
|
|
|
acpi_pm_device_run_wake(bus->bridge, enable);
|
2010-02-18 01:44:09 +03: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 06:23:51 +04: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-18 01:44:09 +03:00
|
|
|
return 0;
|
|
|
|
|
2012-03-27 11:43:25 +04:00
|
|
|
if (!acpi_pm_device_run_wake(&dev->dev, enable))
|
2010-02-18 01:44:09 +03:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
acpi_pci_propagate_run_wake(dev->bus, enable);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-01-21 04:17:42 +03:00
|
|
|
static bool acpi_pci_need_resume(struct pci_dev *dev)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev = ACPI_COMPANION(&dev->dev);
|
|
|
|
|
|
|
|
if (!adev || !acpi_device_power_manageable(adev))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (device_may_wakeup(&dev->dev) != !!adev->wakeup.prepare_count)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (acpi_target_system_state() == ACPI_STATE_S0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return !!adev->power.flags.dsw_present;
|
|
|
|
}
|
|
|
|
|
2008-07-07 05:32:02 +04: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 05:34:48 +04:00
|
|
|
.sleep_wake = acpi_pci_sleep_wake,
|
2010-02-18 01:44:09 +03:00
|
|
|
.run_wake = acpi_pci_run_wake,
|
2015-01-21 04:17:42 +03:00
|
|
|
.need_resume = acpi_pci_need_resume,
|
2008-07-07 05:32:02 +04:00
|
|
|
};
|
2005-03-19 08:16:18 +03:00
|
|
|
|
2013-04-12 09:44:21 +04:00
|
|
|
void acpi_pci_add_bus(struct pci_bus *bus)
|
|
|
|
{
|
2013-07-14 01:27:23 +04:00
|
|
|
if (acpi_pci_disabled || !bus->bridge)
|
2013-04-12 09:44:21 +04:00
|
|
|
return;
|
|
|
|
|
2013-07-14 01:27:23 +04:00
|
|
|
acpi_pci_slot_enumerate(bus);
|
|
|
|
acpiphp_enumerate_slots(bus);
|
2013-04-12 09:44:21 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void acpi_pci_remove_bus(struct pci_bus *bus)
|
|
|
|
{
|
2013-07-14 01:27:23 +04:00
|
|
|
if (acpi_pci_disabled || !bus->bridge)
|
2013-04-12 09:44:21 +04:00
|
|
|
return;
|
|
|
|
|
2013-04-12 09:44:26 +04:00
|
|
|
acpiphp_remove_slots(bus);
|
2013-04-12 09:44:24 +04:00
|
|
|
acpi_pci_slot_remove(bus);
|
2013-04-12 09:44:21 +04:00
|
|
|
}
|
|
|
|
|
2005-03-19 02:53:36 +03:00
|
|
|
/* ACPI bus type */
|
2013-11-29 19:27:34 +04:00
|
|
|
static struct acpi_device *acpi_pci_find_companion(struct device *dev)
|
2005-03-19 02:53:36 +03:00
|
|
|
{
|
ACPI: Try harder to resolve _ADR collisions for bridges
In theory, under a given ACPI namespace node there should be only
one child device object with _ADR whose value matches a given bus
address exactly. In practice, however, there are systems in which
multiple child device objects under a given parent have _ADR matching
exactly the same address. In those cases we use _STA to determine
which of the multiple matching devices is enabled, since some systems
are known to indicate which ACPI device object to associate with the
given physical (usually PCI) device this way.
Unfortunately, as it turns out, there are systems in which many
device objects under the same parent have _ADR matching exactly the
same bus address and none of them has _STA, in which case they all
should be regarded as enabled according to the spec. Still, if
those device objects are supposed to represent bridges (e.g. this
is the case for device objects corresponding to PCIe ports), we can
try harder and skip the ones that have no child device objects in the
ACPI namespace. With luck, we can avoid using device objects that we
are not expected to use this way.
Although this only works for bridges whose children also have ACPI
namespace representation, it is sufficient to address graphics
adapter detection issues on some systems, so rework the code finding
a matching device ACPI handle for a given bus address to implement
this idea.
Introduce a new function, acpi_find_child(), taking three arguments:
the ACPI handle of the device's parent, a bus address suitable for
the device's bus type and a bool indicating if the device is a
bridge and make it work as outlined above. Reimplement the function
currently used for this purpose, acpi_get_child(), as a call to
acpi_find_child() with the last argument set to 'false' and make
the PCI subsystem use acpi_find_child() with the bridge information
passed as the last argument to it. [Lan Tianyu notices that it is
not sufficient to use pci_is_bridge() for that, because the device's
subordinate pointer hasn't been set yet at this point, so use
hdr_type instead.]
This change fixes a regression introduced inadvertently by commit
33f767d (ACPI: Rework acpi_get_child() to be more efficient) which
overlooked the fact that for acpi_walk_namespace() "post-order" means
"after all children have been visited" rather than "on the way back",
so for device objects without children and for namespace walks of
depth 1, as in the acpi_get_child() case, the "post-order" callbacks
ordering is actually the same as the ordering of "pre-order" ones.
Since that commit changed the namespace walk in acpi_get_child() to
terminate after finding the first matching object instead of going
through all of them and returning the last one, it effectively
changed the result returned by that function in some rare cases and
that led to problems (the switch from a "pre-order" to a "post-order"
callback was supposed to prevent that from happening, but it was
ineffective).
As it turns out, the systems where the change made by commit
33f767d actually matters are those where there are multiple ACPI
device objects representing the same PCIe port (which effectively
is a bridge). Moreover, only one of them, and the one we are
expected to use, has child device objects in the ACPI namespace,
so the regression can be addressed as described above.
References: https://bugzilla.kernel.org/show_bug.cgi?id=60561
Reported-by: Peter Wu <lekensteyn@gmail.com>
Tested-by: Vladimir Lalov <mail@vlalov.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
2013-08-08 00:55:00 +04:00
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
2013-11-29 02:58:08 +04:00
|
|
|
bool check_children;
|
ACPI: Try harder to resolve _ADR collisions for bridges
In theory, under a given ACPI namespace node there should be only
one child device object with _ADR whose value matches a given bus
address exactly. In practice, however, there are systems in which
multiple child device objects under a given parent have _ADR matching
exactly the same address. In those cases we use _STA to determine
which of the multiple matching devices is enabled, since some systems
are known to indicate which ACPI device object to associate with the
given physical (usually PCI) device this way.
Unfortunately, as it turns out, there are systems in which many
device objects under the same parent have _ADR matching exactly the
same bus address and none of them has _STA, in which case they all
should be regarded as enabled according to the spec. Still, if
those device objects are supposed to represent bridges (e.g. this
is the case for device objects corresponding to PCIe ports), we can
try harder and skip the ones that have no child device objects in the
ACPI namespace. With luck, we can avoid using device objects that we
are not expected to use this way.
Although this only works for bridges whose children also have ACPI
namespace representation, it is sufficient to address graphics
adapter detection issues on some systems, so rework the code finding
a matching device ACPI handle for a given bus address to implement
this idea.
Introduce a new function, acpi_find_child(), taking three arguments:
the ACPI handle of the device's parent, a bus address suitable for
the device's bus type and a bool indicating if the device is a
bridge and make it work as outlined above. Reimplement the function
currently used for this purpose, acpi_get_child(), as a call to
acpi_find_child() with the last argument set to 'false' and make
the PCI subsystem use acpi_find_child() with the bridge information
passed as the last argument to it. [Lan Tianyu notices that it is
not sufficient to use pci_is_bridge() for that, because the device's
subordinate pointer hasn't been set yet at this point, so use
hdr_type instead.]
This change fixes a regression introduced inadvertently by commit
33f767d (ACPI: Rework acpi_get_child() to be more efficient) which
overlooked the fact that for acpi_walk_namespace() "post-order" means
"after all children have been visited" rather than "on the way back",
so for device objects without children and for namespace walks of
depth 1, as in the acpi_get_child() case, the "post-order" callbacks
ordering is actually the same as the ordering of "pre-order" ones.
Since that commit changed the namespace walk in acpi_get_child() to
terminate after finding the first matching object instead of going
through all of them and returning the last one, it effectively
changed the result returned by that function in some rare cases and
that led to problems (the switch from a "pre-order" to a "post-order"
callback was supposed to prevent that from happening, but it was
ineffective).
As it turns out, the systems where the change made by commit
33f767d actually matters are those where there are multiple ACPI
device objects representing the same PCIe port (which effectively
is a bridge). Moreover, only one of them, and the one we are
expected to use, has child device objects in the ACPI namespace,
so the regression can be addressed as described above.
References: https://bugzilla.kernel.org/show_bug.cgi?id=60561
Reported-by: Peter Wu <lekensteyn@gmail.com>
Tested-by: Vladimir Lalov <mail@vlalov.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
2013-08-08 00:55:00 +04:00
|
|
|
u64 addr;
|
2005-03-19 02:53:36 +03:00
|
|
|
|
2014-05-04 08:23:38 +04:00
|
|
|
check_children = pci_is_bridge(pci_dev);
|
2005-03-19 02:53:36 +03:00
|
|
|
/* Please ref to ACPI spec for the syntax of _ADR */
|
|
|
|
addr = (PCI_SLOT(pci_dev->devfn) << 16) | PCI_FUNC(pci_dev->devfn);
|
2013-11-29 19:27:34 +04:00
|
|
|
return acpi_find_child_device(ACPI_COMPANION(dev->parent), addr,
|
2013-11-29 02:58:08 +04:00
|
|
|
check_children);
|
2005-03-19 02:53:36 +03:00
|
|
|
}
|
|
|
|
|
2012-12-23 03:02:54 +04:00
|
|
|
static void pci_acpi_setup(struct device *dev)
|
2012-12-23 03:02:44 +04:00
|
|
|
{
|
|
|
|
struct pci_dev *pci_dev = to_pci_dev(dev);
|
2013-12-30 02:37:15 +04:00
|
|
|
struct acpi_device *adev = ACPI_COMPANION(dev);
|
2012-12-23 03:02:54 +04:00
|
|
|
|
2013-12-30 02:37:15 +04:00
|
|
|
if (!adev)
|
|
|
|
return;
|
|
|
|
|
|
|
|
pci_acpi_add_pm_notifier(adev, pci_dev);
|
|
|
|
if (!adev->wakeup.flags.valid)
|
2012-12-23 03:02:44 +04:00
|
|
|
return;
|
|
|
|
|
|
|
|
device_set_wakeup_capable(dev, true);
|
|
|
|
acpi_pci_sleep_wake(pci_dev, false);
|
|
|
|
if (adev->wakeup.flags.run_wake)
|
|
|
|
device_set_run_wake(dev, true);
|
|
|
|
}
|
|
|
|
|
2012-12-23 03:02:54 +04:00
|
|
|
static void pci_acpi_cleanup(struct device *dev)
|
2012-12-23 03:02:44 +04:00
|
|
|
{
|
2013-12-30 02:37:15 +04:00
|
|
|
struct acpi_device *adev = ACPI_COMPANION(dev);
|
|
|
|
|
|
|
|
if (!adev)
|
|
|
|
return;
|
2012-12-23 03:02:44 +04:00
|
|
|
|
2013-12-30 02:37:15 +04:00
|
|
|
pci_acpi_remove_pm_notifier(adev);
|
|
|
|
if (adev->wakeup.flags.valid) {
|
2012-12-23 03:02:44 +04:00
|
|
|
device_set_wakeup_capable(dev, false);
|
|
|
|
device_set_run_wake(dev, false);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-03-04 01:35:20 +04:00
|
|
|
static bool pci_acpi_bus_match(struct device *dev)
|
|
|
|
{
|
2013-12-05 15:52:53 +04:00
|
|
|
return dev_is_pci(dev);
|
2013-03-04 01:35:20 +04:00
|
|
|
}
|
|
|
|
|
2006-04-28 11:42:21 +04:00
|
|
|
static struct acpi_bus_type acpi_pci_bus = {
|
2013-03-04 01:35:20 +04:00
|
|
|
.name = "PCI",
|
|
|
|
.match = pci_acpi_bus_match,
|
2013-11-29 19:27:34 +04:00
|
|
|
.find_companion = acpi_pci_find_companion,
|
2012-12-23 03:02:54 +04:00
|
|
|
.setup = pci_acpi_setup,
|
|
|
|
.cleanup = pci_acpi_cleanup,
|
2005-03-19 02:53:36 +03:00
|
|
|
};
|
|
|
|
|
2006-04-28 11:42:21 +04:00
|
|
|
static int __init acpi_pci_init(void)
|
2005-03-19 02:53:36 +03:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2009-02-03 10:14:33 +03:00
|
|
|
if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) {
|
2013-05-28 12:03:46 +04:00
|
|
|
pr_info("ACPI FADT declares the system doesn't support MSI, so disable it\n");
|
2007-04-25 07:05:12 +04:00
|
|
|
pci_no_msi();
|
|
|
|
}
|
2008-07-23 06:32:24 +04:00
|
|
|
|
2009-02-03 10:14:33 +03:00
|
|
|
if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_ASPM) {
|
2013-05-28 12:03:46 +04:00
|
|
|
pr_info("ACPI FADT declares the system doesn't support PCIe ASPM, so disable it\n");
|
2008-07-23 06:32:24 +04:00
|
|
|
pcie_no_aspm();
|
|
|
|
}
|
|
|
|
|
2006-04-28 11:42:21 +04:00
|
|
|
ret = register_acpi_bus_type(&acpi_pci_bus);
|
2005-03-19 02:53:36 +03:00
|
|
|
if (ret)
|
|
|
|
return 0;
|
2013-04-12 09:44:24 +04:00
|
|
|
|
2008-07-07 05:32:02 +04:00
|
|
|
pci_set_platform_pm(&acpi_pci_platform_pm);
|
2013-04-12 09:44:24 +04:00
|
|
|
acpi_pci_slot_init();
|
2013-04-12 09:44:26 +04:00
|
|
|
acpiphp_init();
|
2013-04-12 09:44:24 +04:00
|
|
|
|
2005-03-19 02:53:36 +03:00
|
|
|
return 0;
|
|
|
|
}
|
2006-04-28 11:42:21 +04:00
|
|
|
arch_initcall(acpi_pci_init);
|