[PATCH v4 0/5] PCI: qcom: Add D3cold support

Krishna Chaitanya Chundru
2026-04-07T13:03:33Z

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.

Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
Changes in v4:
- Added new argument to the API to know if there is any device with
wakeup enabled and pme can be generated in D3cold. we need this info
to decide to turn off power to device or not.
- Couple of nits in commit text (Mani).
- Link to v3: https://lore.kernel.org/r/20260311-d3cold-v3-0-4d85dc7c2695@oss.qualcomm.com

Changes in v3:
- Changed the function name from pci_host_common_can_enter_d3cold() to
pci_host_common_d3cold_possible() (Mani).
- Couple of nits for commit text, newlines etc(Mani).
- Removed -ETIMEDOUT check and added -ENODEV & -EIO(Mani).
- Link to v2: https://lore.kernel.org/r/20260217-d3cold-v2-0-89b322864043@oss.qualcomm.com

Changes in v2:
- Updated the cover letter (Bjorn Andersson)
- Add get_ltssm helper function to read LTSSM state from parf.
- Allow D3cold if there is no driver enabled for a endpoint.
- Added a seperate patch to make phy down in deinit part to avoid power
leakage.
- Revert icc bw voting if resume fails(Bjorn Andersson).
- Link to v1: https://lore.kernel.org/r/20260128-d3cold-v1-0-dd8f3f0ce824@oss.qualcomm.com

---
Krishna Chaitanya Chundru (5):
PCI: host-common: Add helper to determine host bridge D3cold eligibility
PCI: qcom: Add .get_ltssm() helper
PCI: qcom: Power down PHY via PARF_PHY_CTRL before disabling rails/clocks
PCI: dwc: Use common D3cold eligibility helper in suspend path
PCI: qcom: Add D3cold support

drivers/pci/controller/dwc/pcie-designware-host.c | 11 +-
drivers/pci/controller/dwc/pcie-designware.h | 1 +
drivers/pci/controller/dwc/pcie-qcom.c | 194 +++++++++++++++-------
drivers/pci/controller/pci-host-common.c | 63 +++++++
drivers/pci/controller/pci-host-common.h | 2 +
5 files changed, 204 insertions(+), 67 deletions(-)
---
base-commit: 3aae9383f42f687221c011d7ee87529398e826b3
change-id: 20251229-d3cold-bf99921960bb

Best regards,
--
Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>