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 v5:
- Add additional checks for legacy, integrated endpoints also as pointed
  by sashiko.
- for older platforms we need to read LTSSM state from ELBI regitsers,
  updated the code to read elbi regitser by sashiko.
- Couple of nits by sashiko. 
- Link to v4: https://lore.kernel.org/r/20260407-d3cold-v4-0-bb171f75b465@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

To: Will Deacon <will@kernel.org>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
To: Krzysztof Wilczyński <kwilczynski@kernel.org>
To: Manivannan Sadhasivam <mani@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Bjorn Helgaas <bhelgaas@google.com>
To: Jingoo Han <jingoohan1@gmail.com>
Cc: linux-pci@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org

---
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 |  15 +-
 drivers/pci/controller/dwc/pcie-designware.h      |   1 +
 drivers/pci/controller/dwc/pcie-qcom.c            | 224 ++++++++++++++++------
 drivers/pci/controller/pci-host-common.c          |  71 +++++++
 drivers/pci/controller/pci-host-common.h          |   2 +
 5 files changed, 242 insertions(+), 71 deletions(-)
---
base-commit: 3b3bea6d4b9c162f9e555905d96b8c1da67ecd5b
change-id: 20251229-d3cold-bf99921960bb

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

On Wed, 29 Apr 2026 12:12:22 +0530, Krishna Chaitanya Chundru wrote:
> 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.
> 
> [...]

Applied, thanks!

[1/5] PCI: host-common: Add helper to determine host bridge D3cold eligibility
      commit: fdf2dc2b677c8a26573624ffcd8f4e2265a99b6f
[2/5] PCI: qcom: Add .get_ltssm() helper
      commit: 60aa688121667577f2f2e7d01c805277dbb75a89
[3/5] PCI: qcom: Power down PHY via PARF_PHY_CTRL before disabling rails/clocks
      commit: c3554c5ec37a490fc66480e10f00ac5bada8eb0e
[4/5] PCI: dwc: Use common D3cold eligibility helper in suspend path
      commit: f4f39b1fdb9445b1e4682fed6f86a2e327755acd
[5/5] PCI: qcom: Add D3cold support
      commit: 2ce984daf09332c09bdc26550d7b6cd4f12d3a6c

Best regards,
-- 
Manivannan Sadhasivam <mani@kernel.org>

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

On 5/4/2026 2:00 AM, Steev Klimaszewski wrote:
> 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.
This series, will not have any impact on the boot, this series comes in to the
picture only in case
of suspend and resume. can you share your platform details and kernel you are
booting with.

- Krishna Chaitanya.
>
> -- steev

On Sun, May 3, 2026 at 10:37 PM Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> wrote:
>
> >
> > 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.

> This series, will not have any impact on the boot, this series comes in to the
> picture only in case
> of suspend and resume. can you share your platform details and kernel you are
> booting with.

Oddly, it seems to, because if I simply go back to v4, the system boots.  I'm
using a 7.0 kernel on the Thinkpad X13s (SC8280XP).  The sources are at
https://github.com/steev/linux/tree/lenovo-x13s-linux-7.0.y (with the v5
applied).  PCIE_QCOM is built-in to the kernel.  Not sure what other information
is needed.

>
> - Krishna Chaitanya.
> >
> > -- steev

On 5/4/2026 9:44 AM, Steev Klimaszewski wrote:
> On Sun, May 3, 2026 at 10:37 PM Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> wrote:
>>> 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.
>> This series, will not have any impact on the boot, this series comes in to the
>> picture only in case
>> of suspend and resume. can you share your platform details and kernel you are
>> booting with.
> Oddly, it seems to, because if I simply go back to v4, the system boots.  I'm
> using a 7.0 kernel on the Thinkpad X13s (SC8280XP).  The sources are at
> https://github.com/steev/linux/tree/lenovo-x13s-linux-7.0.y (with the v5
> applied).  PCIE_QCOM is built-in to the kernel.  Not sure what other information
> is needed.
Hi Steev,

I made mistake in re basing the code, can you try below and see if that fixes
your issue.
I will send this in next patch series.

--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -1327,7 +1327,7 @@ static enum dw_pcie_ltssm qcom_pcie_get_ltssm(struct
dw_pcie *pci)
        struct qcom_pcie *pcie = to_qcom_pcie(pci);
        u32 val;

-       if (pcie->cfg->ops->ltssm_enable)
+       if (pcie->cfg->ops->get_ltssm)
                return pcie->cfg->ops->get_ltssm(pcie);
 
- Krishna Chaitanya.
>> - Krishna Chaitanya.
>>> -- steev

On Mon, May 04, 2026 at 12:36:29PM +0530, Krishna Chaitanya Chundru wrote:
> 
> 
> On 5/4/2026 9:44 AM, Steev Klimaszewski wrote:
> > On Sun, May 3, 2026 at 10:37 PM Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> wrote:
> >>> 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.
> >> This series, will not have any impact on the boot, this series comes in to the
> >> picture only in case
> >> of suspend and resume. can you share your platform details and kernel you are
> >> booting with.
> > Oddly, it seems to, because if I simply go back to v4, the system boots.  I'm
> > using a 7.0 kernel on the Thinkpad X13s (SC8280XP).  The sources are at
> > https://github.com/steev/linux/tree/lenovo-x13s-linux-7.0.y (with the v5
> > applied).  PCIE_QCOM is built-in to the kernel.  Not sure what other information
> > is needed.
> Hi Steev,
> 
> I made mistake in re basing the code, can you try below and see if that fixes
> your issue.
> I will send this in next patch series.
> 
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -1327,7 +1327,7 @@ static enum dw_pcie_ltssm qcom_pcie_get_ltssm(struct
> dw_pcie *pci)
>         struct qcom_pcie *pcie = to_qcom_pcie(pci);
>         u32 val;
> 
> -       if (pcie->cfg->ops->ltssm_enable)
> +       if (pcie->cfg->ops->get_ltssm)
>                 return pcie->cfg->ops->get_ltssm(pcie);

Squashed this change while applying.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Hi Krishna,

On Mon, May 4, 2026 at 2:06 AM Krishna Chaitanya Chundru
<krishna.chundru@oss.qualcomm.com> wrote:
>
>
>
> On 5/4/2026 9:44 AM, Steev Klimaszewski wrote:
> > On Sun, May 3, 2026 at 10:37 PM Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> wrote:
> >>> 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.
> >> This series, will not have any impact on the boot, this series comes in to the
> >> picture only in case
> >> of suspend and resume. can you share your platform details and kernel you are
> >> booting with.
> > Oddly, it seems to, because if I simply go back to v4, the system boots.  I'm
> > using a 7.0 kernel on the Thinkpad X13s (SC8280XP).  The sources are at
> > https://github.com/steev/linux/tree/lenovo-x13s-linux-7.0.y (with the v5
> > applied).  PCIE_QCOM is built-in to the kernel.  Not sure what other information
> > is needed.
> Hi Steev,
>
> I made mistake in re basing the code, can you try below and see if that fixes
> your issue.
> I will send this in next patch series.
>
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -1327,7 +1327,7 @@ static enum dw_pcie_ltssm qcom_pcie_get_ltssm(struct
> dw_pcie *pci)
>         struct qcom_pcie *pcie = to_qcom_pcie(pci);
>         u32 val;
>
> -       if (pcie->cfg->ops->ltssm_enable)
> +       if (pcie->cfg->ops->get_ltssm)
>                 return pcie->cfg->ops->get_ltssm(pcie);
>
> - Krishna Chaitanya.
> >> - Krishna Chaitanya.
> >>> -- steev


Indeed, that fixes it, thank you!

-- steev