From: Steev Klimaszewski <threeway@gmail.com>
To: krishna.chundru@oss.qualcomm.com
Cc: bhelgaas@google.com, bjorn.andersson@oss.qualcomm.com,
jingoohan1@gmail.com, jonathanh@nvidia.com,
kwilczynski@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, lpieralisi@kernel.org,
mani@kernel.org, robh@kernel.org, will@kernel.org
Subject: Re: PCI: qcom: Add D3cold support
Date: Sun, 3 May 2026 15:30:06 -0500 [thread overview]
Message-ID: <20260503203008.287559-1-threeway@gmail.com> (raw)
In-Reply-To: <20260429-d3cold-v5-0-89e9735b9df6@oss.qualcomm.com>
Hi Krishna,
> This series adds support for putting Qualcomm PCIe host bridges into D3cold
> when downstream conditions allow it, and introduces a small common helper
> to determine D3cold eligibility based on endpoint state.
> On Qualcomm platforms, PCIe host controllers are currently kept powered
> even when there are no active endpoints (i.e. all endpoints are already in
> PCI_D3hot). This prevents the SoC from entering deeper low‑power states
> such as CXPC.
> While PCIe D3cold support exists in the PCI core, host controller drivers
> lack a common mechanism to determine whether it is safe to power off the
> host bridge without breaking active devices or wakeup functionality.
> As a result, controllers either avoid entering D3cold or depend on rough,
> driver‑specific workarounds.
> This series addresses that gap.
> 1. Introduces pci_host_common_can_enter_d3cold(), a helper that determines
> whether a host bridge may enter D3cold based on downstream PCIe endpoint
> state. The helper permits D3cold only when all *active* endpoints are
> already in PCI_D3hot, and any wakeup‑enabled endpoint supports PME
> from D3cold.
> 2. Updates the Designware PCIe host driver to use this helper in the
> suspend_noirq() path, replacing the existing heuristic that blocked
> D3cold whenever L1 ASPM was enabled.
> 3. Enables D3cold support for Qualcomm PCIe controllers by wiring them into
> the DesignWare common suspend/resume flow and explicitly powering down
> controller resources when all endpoints are in D3hot.
> The immediate outcome of this series is that Qualcomm PCIe host bridges can
> enter D3cold when all endpoints are in D3hot.
> This is a necessary but not sufficient step toward unblocking CXPC. With
> this series applied, CXPC can be achieved on systems with no attached NVMe
> devices. Support for NVMe‑attached systems requires additional changes
> in NVMe driver, which are being worked on separately.
> Tested on:
> - Qualcomm Lemans EVK, Monaco & sc7280 platforms.
> Validation steps:
> - Boot without NVMe attach:
> * PCIe host enters D3cold during suspend
> * SoC is able to reach CXPC provided other drivers also remove
> their votes as part of suspend.
I have been testing this patchset with Mani's patchset that is supposed to be
related to NVMe on the Thinkpad X13s found at:
https://lore.kernel.org/all/20260414-l1ss-fix-v1-0-adbb4555b5ab@oss.qualcomm.com/
v4 of this patchset *boots* along with Mani's patchset, however, v5 does not,
and unfortunately, the machine does not seem to get to a point where I can even
get logs from it. Do you know what I might be missing? I have *not* attempted
to remove the nvme drive and boot off USB to test it.
-- steev
next prev parent reply other threads:[~2026-05-03 20:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 6:42 [PATCH v5 0/5] PCI: qcom: Add D3cold support Krishna Chaitanya Chundru
2026-04-29 6:42 ` [PATCH v5 1/5] PCI: host-common: Add helper to determine host bridge D3cold eligibility Krishna Chaitanya Chundru
2026-04-29 6:42 ` [PATCH v5 2/5] PCI: qcom: Add .get_ltssm() helper Krishna Chaitanya Chundru
2026-04-29 6:42 ` [PATCH v5 3/5] PCI: qcom: Power down PHY via PARF_PHY_CTRL before disabling rails/clocks Krishna Chaitanya Chundru
2026-04-29 6:42 ` [PATCH v5 4/5] PCI: dwc: Use common D3cold eligibility helper in suspend path Krishna Chaitanya Chundru
2026-04-29 6:42 ` [PATCH v5 5/5] PCI: qcom: Add D3cold support Krishna Chaitanya Chundru
2026-05-03 20:30 ` Steev Klimaszewski [this message]
2026-05-04 3:37 ` Krishna Chaitanya Chundru
2026-05-04 4:14 ` Steev Klimaszewski
2026-05-04 7:06 ` Krishna Chaitanya Chundru
2026-05-04 14:16 ` Steev Klimaszewski
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=20260503203008.287559-1-threeway@gmail.com \
--to=threeway@gmail.com \
--cc=bhelgaas@google.com \
--cc=bjorn.andersson@oss.qualcomm.com \
--cc=jingoohan1@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=krishna.chundru@oss.qualcomm.com \
--cc=kwilczynski@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.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=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox