From: Bjorn Helgaas <helgaas@kernel.org>
To: Richard Zhu <hongxing.zhu@nxp.com>
Cc: frank.li@nxp.com, jingoohan1@gmail.com, l.stach@pengutronix.de,
lpieralisi@kernel.org, kwilczynski@kernel.org, mani@kernel.org,
robh@kernel.org, bhelgaas@google.com, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [RESEND v3 1/5] PCI: dwc: Don't poll L2 if QUIRK_NOL2POLL_IN_PM is existing in suspend
Date: Mon, 18 Aug 2025 10:48:33 -0500 [thread overview]
Message-ID: <20250818154833.GA528281@bhelgaas> (raw)
In-Reply-To: <20250818073205.1412507-2-hongxing.zhu@nxp.com>
On Mon, Aug 18, 2025 at 03:32:01PM +0800, Richard Zhu wrote:
> Refer to PCIe r6.0, sec 5.2, fig 5-1 Link Power Management State Flow
> Diagram. Both L0 and L2/L3 Ready can be transferred to LDn directly.
>
> It's harmless to let dw_pcie_suspend_noirq() proceed suspend after the
> PME_Turn_Off is sent out, whatever the LTSSM state is in L2 or L3 after
> a recommended 10ms max wait refer to PCIe r6.0, sec 5.3.3.2.1 PME
> Synchronization.
>
> The LTSSM states are inaccessible on i.MX6QP and i.MX7D after the
> PME_Turn_Off is sent out.
>
> To support this case, don't poll L2 state and apply a simple delay of
> PCIE_PME_TO_L2_TIMEOUT_US(10ms) if the QUIRK_NOL2POLL_IN_PM flag is set
> in suspend.
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> .../pci/controller/dwc/pcie-designware-host.c | 31 +++++++++++++------
> drivers/pci/controller/dwc/pcie-designware.h | 4 +++
> 2 files changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 952f8594b5012..20a7f827babbf 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -1007,7 +1007,7 @@ int dw_pcie_suspend_noirq(struct dw_pcie *pci)
> {
> u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> u32 val;
> - int ret;
> + int ret = 0;
>
> /*
> * If L1SS is supported, then do not put the link into L2 as some
* devices such as NVMe expect low resume latency.
*/
if (dw_pcie_readw_dbi(pci, offset + PCI_EXP_LNKCTL) & PCI_EXP_LNKCTL_ASPM_L1)
return 0;
You didn't change it in this patch (the L1SS test was added by
4774faf854f5 ("PCI: dwc: Implement generic suspend/resume
functionality")), but this L1SS check is an encapsulation problem.
The ASPM configuration shouldn't leak out here in such an ad hoc way.
*All* drivers, not just NVMe, would prefer low resume latency.
How do we deal with this in other host controller drivers? If any
other driver puts links in L2, I suppose they would have the same
issue? Maybe DWC is the only one that puts the link in L2?
What happens when we add a new driver that puts links in L2? I guess
we'll be debugging some NVMe issue again?
Bjorn
next prev parent reply other threads:[~2025-08-18 15:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-18 7:32 [RESEND PATCH v3 0/5] Add quirks to proceed PME handshake in DWC PM Richard Zhu
2025-08-18 7:32 ` [RESEND v3 1/5] PCI: dwc: Don't poll L2 if QUIRK_NOL2POLL_IN_PM is existing in suspend Richard Zhu
2025-08-18 15:48 ` Bjorn Helgaas [this message]
2025-08-19 5:51 ` Hongxing Zhu
2025-08-19 19:33 ` Bjorn Helgaas
2025-08-19 19:28 ` Bjorn Helgaas
2025-08-21 5:44 ` Hongxing Zhu
2025-08-18 7:32 ` [RESEND v3 2/5] PCI: imx6: Don't poll LTSSM state of i.MX6QP PCIe in PM operations Richard Zhu
2025-08-18 7:32 ` [RESEND v3 3/5] PCI: imx6: Don't poll LTSSM state of i.MX7D " Richard Zhu
2025-08-18 7:32 ` [RESEND v3 4/5] PCI: dwc: Skip PME_Turn_Off message if there is no endpoint connected Richard Zhu
2025-08-19 19:07 ` Bjorn Helgaas
2025-08-21 5:44 ` Hongxing Zhu
2025-08-21 14:36 ` Bjorn Helgaas
2025-08-18 7:32 ` [RESEND v3 5/5] PCI: dwc: Don't return error when wait for link up Richard Zhu
2025-08-18 15:32 ` Bjorn Helgaas
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=20250818154833.GA528281@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=festevam@gmail.com \
--cc=frank.li@nxp.com \
--cc=hongxing.zhu@nxp.com \
--cc=imx@lists.linux.dev \
--cc=jingoohan1@gmail.com \
--cc=kernel@pengutronix.de \
--cc=kwilczynski@kernel.org \
--cc=l.stach@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
/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.