[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230804210129.5356-8-mario.limonciello@amd.com>
Date: Fri, 4 Aug 2023 16:01:29 -0500
From: Mario Limonciello <mario.limonciello@....com>
To: "Rafael J . Wysocki" <rafael@...nel.org>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Bjorn Helgaas <helgaas@...nel.org>
CC: <linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
"Andy Shevchenko" <andriy.shevchenko@...ux.intel.com>,
<linux-acpi@...r.kernel.org>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"Iain Lane" <iain@...ngesquash.org.uk>,
Shyam-sundar S-k <Shyam-sundar.S-k@....com>,
Mario Limonciello <mario.limonciello@....com>
Subject: [PATCH v10 7/7] PCI: Use device constraints to decide PCI target state fallback policy
Since commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend")
PCIe ports from modern machines (>=2015) are allowed to be put into D3 by
storing a value to the `bridge_d3` variable in the `struct pci_dev`
structure.
pci_power_manageable() uses this variable to indicate a PCIe port can
enter D3.
pci_pm_suspend_noirq() uses the return from pci_power_manageable() to
decide whether to try to put a device into its target state for a sleep
cycle via pci_prepare_to_sleep().
For devices that support D3, the target state is selected by this policy:
1. If platform_pci_power_manageable():
Use platform_pci_choose_state()
2. If the device is armed for wakeup:
Select the deepest D-state that supports a PME.
3. Else:
Use D3hot.
Devices are considered power manageable by the platform when they have
one or more objects described in the table in section 7.3 of the ACPI 6.5
specification.
When devices are not considered power manageable; specs are ambiguous as
to what should happen. In this situation Windows 11 leaves PCIe
ports in D0 while Linux puts them into D3 due to the above mentioned
commit.
In Windows systems that support Modern Standby specify hardware
pre-conditions for the SoC to achieve the lowest power state by device
constraints in a SOC specific "Power Engine Plugin" (PEP) [2] [3].
They can be marked as disabled or enabled and when enabled can specify
the minimum power state required for an ACPI device.
When it is ambiguous what should happen, adjust the logic for
pci_target_state() to check whether a device constraint is present
and enabled.
* If power manageable by ACPI use this to get to select target state
* If a device constraint is present but disabled then choose D0
* If a device constraint is present and enabled then use it
* If a device constraint is not present, then continue to existing
logic (if marked for wakeup use deepest state that PME works)
* If not marked for wakeup choose D3hot
Link: https://uefi.org/specs/ACPI/6.5/07_Power_and_Performance_Mgmt.html#device-power-management-objects [1]
Link: https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/platform-design-for-modern-standby#low-power-core-silicon-cpu-soc-dram [2]
Link: https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf [3]
Fixes: 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend")
Reported-by: Iain Lane <iain@...ngesquash.org.uk>
Closes: https://forums.lenovo.com/t5/Ubuntu/Z13-can-t-resume-from-suspend-with-external-USB-keyboard/m-p/5217121
Signed-off-by: Mario Limonciello <mario.limonciello@....com>
---
v9->v10:
* kerneldoc fixes
* split into more patches
* adjust return variable handling
* Adjust call-site to avoid problems for devices already in d3cold
---
drivers/pci/pci.c | 47 ++++++++++++++++++++++++++++++++++-------------
1 file changed, 34 insertions(+), 13 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 60230da957e0c..108eacc4f8dd9 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1082,6 +1082,14 @@ static inline bool platform_pci_bridge_d3(struct pci_dev *dev)
return acpi_pci_bridge_d3(dev);
}
+static inline int platform_get_constraint(struct pci_dev *dev)
+{
+ if (pci_use_mid_pm())
+ return -ENODEV;
+
+ return acpi_get_lps0_constraint(&dev->dev);
+}
+
/**
* pci_update_current_state - Read power state of given device and cache it
* @dev: PCI device to handle.
@@ -2660,6 +2668,20 @@ int pci_wake_from_d3(struct pci_dev *dev, bool enable)
}
EXPORT_SYMBOL(pci_wake_from_d3);
+/*
+ * Find the deepest state from which the device can generate
+ * PME#.
+ */
+static pci_power_t pci_get_wake_pme_state(struct pci_dev *dev)
+{
+ pci_power_t state = PCI_D3hot;
+
+ while (state && !(dev->pme_support & (1 << state)))
+ state--;
+
+ return state;
+}
+
/**
* pci_target_state - find an appropriate low power state for a given PCI dev
* @dev: PCI device
@@ -2671,6 +2693,8 @@ EXPORT_SYMBOL(pci_wake_from_d3);
*/
static pci_power_t pci_target_state(struct pci_dev *dev, bool wakeup)
{
+ pci_power_t constraint;
+
if (platform_pci_power_manageable(dev)) {
/*
* Call the platform to find the target state for the device.
@@ -2701,23 +2725,20 @@ static pci_power_t pci_target_state(struct pci_dev *dev, bool wakeup)
else if (!dev->pm_cap)
return PCI_D0;
- if (wakeup && dev->pme_support) {
- pci_power_t state = PCI_D3hot;
+ /* if platform indicates preferred state device constraint, use it */
+ constraint = platform_get_constraint(dev);
+ if (constraint < 0)
+ constraint = PCI_D3hot;
- /*
- * Find the deepest state from which the device can generate
- * PME#.
- */
- while (state && !(dev->pme_support & (1 << state)))
- state--;
+ if (wakeup && dev->pme_support) {
+ pci_power_t pme_state = pci_get_wake_pme_state(dev);
- if (state)
- return state;
- else if (dev->pme_support & 1)
- return PCI_D0;
+ /* pick the lesser of any specified constraints */
+ if (pme_state < constraint)
+ constraint = pme_state;
}
- return PCI_D3hot;
+ return constraint;
}
/**
--
2.34.1
Powered by blists - more mailing lists