PCI: Afford direct-complete to devices with non-standard PM
authorLukas Wunner <lukas@wunner.de>
Sun, 18 Sep 2016 03:39:20 +0000 (05:39 +0200)
committerBjorn Helgaas <bhelgaas@google.com>
Wed, 28 Sep 2016 16:45:27 +0000 (11:45 -0500)
commit4132a577a0a7e75b938d2ae49c7a16b358f60661
tree2c9bb5011d5dbac77320f160042953f42427b32d
parent29b4817d4018df78086157ea3a55c1d9424a7cfc
PCI: Afford direct-complete to devices with non-standard PM

There are devices not power-manageable by the platform, but still able to
runtime suspend to D3cold with a non-standard mechanism.  One example is
laptop hybrid graphics where the discrete GPU and its built-in HDA
controller are power-managed either with a _DSM (AMD PowerXpress, Nvidia
Optimus) or a separate gmux controller (MacBook Pro).  Another example is
Thunderbolt on Macs which is power-managed with custom ACPI methods.

When putting the system to sleep, we currently handle such devices
improperly by transitioning them from D3cold to D3hot (the default power
state defined at the top of pci_target_state()).  This wastes energy and
prolongs the suspend sequence (powering up the Thunderbolt controller takes
2 seconds).

Avoid that by assuming that a non-standard PM mechanism is at work if the
device is not platform-power-manageable but currently in D3cold.

If the device is wakeup enabled, we might still have to wake it up from
D3cold if PME cannot be signaled from that power state.

The check for devices without PM capability comes before the check for
D3cold since such devices could in theory also be powered down by
non-standard means and should then be afforded direct-complete as well.

Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
drivers/pci/pci.c