From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Mario Limonciello <mario.limonciello@amd.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Hans de Goede <hdegoede@redhat.com>,
iain@orangesquash.org.uk,
Shyam Sundar S K <Shyam-sundar.S-k@amd.com>,
"open list:PCI SUBSYSTEM" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH v19 2/2] PCI: Add a quirk for AMD PCIe root ports w/ USB4 controllers
Date: Mon, 18 Sep 2023 14:59:28 +0300 (EEST) [thread overview]
Message-ID: <9d3ea5-da3a-cd60-bc6c-442eae404073@linux.intel.com> (raw)
In-Reply-To: <20230915023354.939-3-mario.limonciello@amd.com>
On Thu, 14 Sep 2023, Mario Limonciello wrote:
> Iain reports that USB devices can't be used to wake a Lenovo Z13
> from suspend. This problem occurs because the PCIe root port has been put
> into D3hot and AMD's platform can't handle USB devices waking the platform
> from a hardware sleep state in this case. The platform is put into
> a hardware sleep state by the actions of the amd-pmc driver.
>
> Although the issue is initially reported on a single model it actually
> affects all Yellow Carp (Rembrandt) and Pink Sardine (Phoenix) SoCs.
> This problem only occurs on Linux specifically when attempting to
> wake the platform from a hardware sleep state.
> Comparing the behavior on Windows and Linux, Windows doesn't put
> the root ports into D3 at this time.
>
> Linux decides the target state to put the device into at suspend 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 [1]. In this case the root ports are not power manageable.
>
> If devices are not considered power manageable; specs are ambiguous as
> to what should happen. In this situation Windows 11 puts PCIe ports
> in D0 ostensibly due the policy from the "uPEP driver" which is a
> complimentary driver the Linux "amd-pmc" driver.
>
> Linux chooses to allow D3 for these root ports due to the policy
> introduced by commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during
> suspend").
>
> The Windows uPEP driver expresses the desired state that should be
> selected for suspend but Linux doesn't, so introduce a quirk for the
> problematic root ports.
>
> The quirk removes PME support for D3hot and D3cold at suspend time if the
> system will be using s2idle. When the port is configured for wakeup this
> will prevent these states from being selected in pci_target_state().
>
> After the system is resumes the PME support is re-read from the PM
> capabilities register to allow opportunistic power savings at runtime by
> letting the root port go into D3hot or D3cold.
>
> Cc: stable@vger.kernel.org
> Link: https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/platform-design-for-modern-standby#low-power-core-silicon-cpu-soc-dram [1]
> Fixes: 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend")
> Reported-by: Iain Lane <iain@orangesquash.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@amd.com>
> ---
> drivers/pci/quirks.c | 61 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 61 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index eeec1d6f9023..ebc0afbc814e 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -6188,3 +6188,64 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x9a31, dpc_log_size);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_XILINX, 0x5020, of_pci_make_dev_node);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_XILINX, 0x5021, of_pci_make_dev_node);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_REDHAT, 0x0005, of_pci_make_dev_node);
> +
> +/*
> + * When AMD PCIe root ports with AMD USB4 controllers attached to them are put
> + * into D3hot or D3cold downstream USB devices may fail to wakeup the system.
> + * This manifests as a missing wakeup interrupt.
> + *
> + * Prevent the associated root port from using PME to wake from D3hot or
> + * D3cold power states during s2idle.
> + * This will effectively put the root port into D0 power state over s2idle.
> + */
> +static bool child_has_amd_usb4(struct pci_dev *pdev)
> +{
> + struct pci_dev *child = NULL;
> +
> + while ((child = pci_get_class(PCI_CLASS_SERIAL_USB_USB4, child))) {
> + if (child->vendor != PCI_VENDOR_ID_AMD)
> + continue;
> + if (pcie_find_root_port(child) != pdev)
> + continue;
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static void quirk_reenable_pme(struct pci_dev *dev)
> +{
> + u16 pmc;
> +
> + if (!dev->pm_cap)
> + return;
> +
> + if (!child_has_amd_usb4(dev))
> + return;
> +
> + pci_read_config_word(dev, dev->pm_cap + PCI_PM_PMC, &pmc);
> + pmc &= PCI_PM_CAP_PME_MASK;
> + dev->pme_support = pmc >> PCI_PM_CAP_PME_SHIFT;
FIELD_GET(PCI_PM_CAP_PME_MASK, pmc);
--
i.
> +}
> +
> +static void quirk_disable_pme_suspend(struct pci_dev *dev)
> +{
> + int mask;
> +
> + if (pm_suspend_via_firmware())
> + return;
> +
> + if (!child_has_amd_usb4(dev))
> + return;
> +
> + mask = (PCI_PM_CAP_PME_D3hot|PCI_PM_CAP_PME_D3cold) >> PCI_PM_CAP_PME_SHIFT;
> + if (!(dev->pme_support & mask))
> + return;
> + dev->pme_support &= ~mask;
> + dev_info_once(&dev->dev, "quirk: disabling PME from D3hot and D3cold at suspend\n");
> +}
> +
> +DECLARE_PCI_FIXUP_SUSPEND(PCI_VENDOR_ID_AMD, 0x14b9, quirk_disable_pme_suspend);
> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x14b9, quirk_reenable_pme);
> +DECLARE_PCI_FIXUP_SUSPEND(PCI_VENDOR_ID_AMD, 0x14eb, quirk_disable_pme_suspend);
> +DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_AMD, 0x14eb, quirk_reenable_pme);
>
prev parent reply other threads:[~2023-09-18 12:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-15 2:33 [PATCH v19 0/2] Add quirk for PCIe root port on AMD systems Mario Limonciello
2023-09-15 2:33 ` [PATCH v19 1/2] PCI: Move the `PCI_CLASS_SERIAL_USB_USB4` definition to common header Mario Limonciello
2023-09-15 2:33 ` [PATCH v19 2/2] PCI: Add a quirk for AMD PCIe root ports w/ USB4 controllers Mario Limonciello
2023-09-15 7:08 ` Lukas Wunner
2023-09-15 12:04 ` Mario Limonciello
2023-09-16 4:48 ` Lukas Wunner
2023-09-16 13:09 ` Mario Limonciello
2023-09-16 13:36 ` Lukas Wunner
2023-09-16 14:00 ` Mario Limonciello
2023-09-17 21:40 ` Bjorn Helgaas
2023-09-18 1:02 ` Mario Limonciello
2023-09-18 7:01 ` Lukas Wunner
2023-09-17 21:56 ` Bjorn Helgaas
2023-09-18 1:08 ` Mario Limonciello
2023-09-18 11:59 ` Ilpo Järvinen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9d3ea5-da3a-cd60-bc6c-442eae404073@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=Shyam-sundar.S-k@amd.com \
--cc=bhelgaas@google.com \
--cc=hdegoede@redhat.com \
--cc=iain@orangesquash.org.uk \
--cc=linux-pci@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mika.westerberg@linux.intel.com \
--cc=rjw@rjwysocki.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.