drivers/pci/controller/dwc/pcie-designware-host.c | 7 +- drivers/pci/controller/dwc/pcie-designware.h | 1 + drivers/pci/controller/dwc/pcie-qcom.c | 114 +++++++++++++--------- drivers/pci/controller/pci-host-common.c | 29 ++++++ drivers/pci/controller/pci-host-common.h | 2 + 5 files changed, 101 insertions(+), 52 deletions(-)
This series adds a common helper to determine when a PCIe host bridge
can safely enter D3cold, converts the DesignWare host driver to use that
helper, and enables D3cold support for Qualcomm PCIe controllers.
The first patch introduces pci_host_common_can_enter_d3cold() in
pci-host-common. The helper walks all devices on the bridge's bus and
only allows the host bridge to enter D3cold if all PCIe endpoints are
already in PCI_D3hot. For devices that may wake the system, it
additionally requires that the device support PME wakeup from D3cold
(via WAKE#). Devices without wakeup enabled are not restricted by this
check and may be left in D3cold.
The second patch updates the DesignWare host driver to use this common
helper in dw_pcie_suspend_noirq(). Previously, the driver skipped
putting the link into L2 / device D3cold whenever L1 ASPM was enabled,
since some devices (e.g. NVMe) expect low resume latency and may not
tolerate deeper power states. However, such devices typically remain in
D0 and are already covered by the helper's requirement that all
endpoints be in D3hot before the host bridge may enter D3cold. Using the
shared helper removes this coarse heuristic and centralizes the D3cold
eligibility policy.
The third patch enables D3cold support for Qualcomm PCIe controllers. It
adds pme_turn_off() support and switches to the DesignWare common
suspend/resume methods for device D3cold entry and exit. If the
controller is not kept in D3cold, the existing paths are used so that
ICC votes, OPP votes, and other resources remain managed as before. In
addition, qcom_pcie_deinit_2_7_0() is updated to explicitly disable
PCIe clocks and resets in the controller, and the now-unused "suspended"
flag is removed from struct qcom_pcie.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
Krishna Chaitanya Chundru (3):
PCI: host-common: Add shared D3cold eligibility helper for host bridges
PCI: dwc: Use common D3cold eligibility helper in suspend path
PCI: qcom: Add D3cold support
drivers/pci/controller/dwc/pcie-designware-host.c | 7 +-
drivers/pci/controller/dwc/pcie-designware.h | 1 +
drivers/pci/controller/dwc/pcie-qcom.c | 114 +++++++++++++---------
drivers/pci/controller/pci-host-common.c | 29 ++++++
drivers/pci/controller/pci-host-common.h | 2 +
5 files changed, 101 insertions(+), 52 deletions(-)
---
base-commit: 590a64365d9bcc13ee644a3e73ffdc3df26cf23c
change-id: 20251229-d3cold-bf99921960bb
Best regards,
--
Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
On Wed, Jan 28, 2026 at 05:10:40PM +0530, Krishna Chaitanya Chundru wrote: > This series adds a common helper to determine when a PCIe host bridge > can safely enter D3cold, converts the DesignWare host driver to use that > helper, and enables D3cold support for Qualcomm PCIe controllers. > You only modify qcom_pcie_deinit_2_7_0() so which targets is this expected to work on and which targets have you tested it on. How can I test it and what outcome should I expect? > The first patch introduces pci_host_common_can_enter_d3cold() in > pci-host-common. The helper walks all devices on the bridge's bus and > only allows the host bridge to enter D3cold if all PCIe endpoints are > already in PCI_D3hot. For devices that may wake the system, it > additionally requires that the device support PME wakeup from D3cold > (via WAKE#). Devices without wakeup enabled are not restricted by this > check and may be left in D3cold. > > The second patch updates the DesignWare host driver to use this common > helper in dw_pcie_suspend_noirq(). Previously, the driver skipped > putting the link into L2 / device D3cold whenever L1 ASPM was enabled, > since some devices (e.g. NVMe) expect low resume latency and may not > tolerate deeper power states. However, such devices typically remain in > D0 and are already covered by the helper's requirement that all > endpoints be in D3hot before the host bridge may enter D3cold. Using the > shared helper removes this coarse heuristic and centralizes the D3cold > eligibility policy. > > The third patch enables D3cold support for Qualcomm PCIe controllers. It > adds pme_turn_off() support and switches to the DesignWare common > suspend/resume methods for device D3cold entry and exit. If the > controller is not kept in D3cold, the existing paths are used so that > ICC votes, OPP votes, and other resources remain managed as before. In > addition, qcom_pcie_deinit_2_7_0() is updated to explicitly disable > PCIe clocks and resets in the controller, and the now-unused "suspended" > flag is removed from struct qcom_pcie. > This is effectively just duplicating the commit messages. Lacking from both is a good explanation of the problem statement, but that might just be me not getting it? Could you please help me understand what the actual outcome of this series is? I was under the impression that this work would lead us towards unblocking CXPC, but the other patch you sent will prevent CXPC. Regards, Bjorn > Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> > --- > Krishna Chaitanya Chundru (3): > PCI: host-common: Add shared D3cold eligibility helper for host bridges > PCI: dwc: Use common D3cold eligibility helper in suspend path > PCI: qcom: Add D3cold support > > drivers/pci/controller/dwc/pcie-designware-host.c | 7 +- > drivers/pci/controller/dwc/pcie-designware.h | 1 + > drivers/pci/controller/dwc/pcie-qcom.c | 114 +++++++++++++--------- > drivers/pci/controller/pci-host-common.c | 29 ++++++ > drivers/pci/controller/pci-host-common.h | 2 + > 5 files changed, 101 insertions(+), 52 deletions(-) > --- > base-commit: 590a64365d9bcc13ee644a3e73ffdc3df26cf23c > change-id: 20251229-d3cold-bf99921960bb > > Best regards, > -- > Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> > >
On 1/28/2026 8:25 PM, Bjorn Andersson wrote: > On Wed, Jan 28, 2026 at 05:10:40PM +0530, Krishna Chaitanya Chundru wrote: >> This series adds a common helper to determine when a PCIe host bridge >> can safely enter D3cold, converts the DesignWare host driver to use that >> helper, and enables D3cold support for Qualcomm PCIe controllers. >> > You only modify qcom_pcie_deinit_2_7_0() so which targets is this > expected to work on and which targets have you tested it on. How can I > test it and what outcome should I expect? we modified qcom_pcie_deinit_2_7_() because we are trying to undo what we are doing as part of init for other platforms, in init() we are just turning on the resources. I tested this on lemans evk device. After this series we can expect PCIe link will go to D3cold(provided there is no NVMe attach), and cxpc can be achieved. For NVMe devices, mani is working on, in which requires some psci changes[1] >> The first patch introduces pci_host_common_can_enter_d3cold() in >> pci-host-common. The helper walks all devices on the bridge's bus and >> only allows the host bridge to enter D3cold if all PCIe endpoints are >> already in PCI_D3hot. For devices that may wake the system, it >> additionally requires that the device support PME wakeup from D3cold >> (via WAKE#). Devices without wakeup enabled are not restricted by this >> check and may be left in D3cold. >> >> The second patch updates the DesignWare host driver to use this common >> helper in dw_pcie_suspend_noirq(). Previously, the driver skipped >> putting the link into L2 / device D3cold whenever L1 ASPM was enabled, >> since some devices (e.g. NVMe) expect low resume latency and may not >> tolerate deeper power states. However, such devices typically remain in >> D0 and are already covered by the helper's requirement that all >> endpoints be in D3hot before the host bridge may enter D3cold. Using the >> shared helper removes this coarse heuristic and centralizes the D3cold >> eligibility policy. >> >> The third patch enables D3cold support for Qualcomm PCIe controllers. It >> adds pme_turn_off() support and switches to the DesignWare common >> suspend/resume methods for device D3cold entry and exit. If the >> controller is not kept in D3cold, the existing paths are used so that >> ICC votes, OPP votes, and other resources remain managed as before. In >> addition, qcom_pcie_deinit_2_7_0() is updated to explicitly disable >> PCIe clocks and resets in the controller, and the now-unused "suspended" >> flag is removed from struct qcom_pcie. >> > This is effectively just duplicating the commit messages. Lacking from > both is a good explanation of the problem statement, but that might just > be me not getting it? We are adding support for D3cold for qcom controllers, this is a PCIe feature, I haven't added reference to qcom internal power state like CXPC since this alone will not achieve this. But I should have added to this as ultimate purpose is to have CXPC and main blocking is currently PCIe. > > Could you please help me understand what the actual outcome of this > series is? I was under the impression that this work would lead us > towards unblocking CXPC, but the other patch you sent will prevent CXPC. This will keep PCIe in D3cold and achieve CXPC if there is no NVMe endpoints. No other patch is not preventing CXPC, it is just trying to tell genpd framework that don't turn off GENPD, if the controller is not suspended. if we don't have that patch when device is not suspended i.e not kept in D3cold the gdsc is getting turned off and PCIe link is going down. Until PCIe state is in D3cold, gdsc should not be off even in cxpc case. Mani, To avoid the confusion, can I club this patch[2] to this series in next verision [1] https://lore.kernel.org/all/20251231162126.7728-1-manivannan.sadhasivam@oss.qualcomm.com [2] [PATCH] PCI: qcom: Prevent GDSC power down on suspend - Krishna Chaitanya Chundru <https://lore.kernel.org/all/20260128-genpd_fix-v1-1-cd45a249d12f@oss.qualcomm.com/> - Krishna Chaitanya. > > Regards, > Bjorn > >> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> >> --- >> Krishna Chaitanya Chundru (3): >> PCI: host-common: Add shared D3cold eligibility helper for host bridges >> PCI: dwc: Use common D3cold eligibility helper in suspend path >> PCI: qcom: Add D3cold support >> >> drivers/pci/controller/dwc/pcie-designware-host.c | 7 +- >> drivers/pci/controller/dwc/pcie-designware.h | 1 + >> drivers/pci/controller/dwc/pcie-qcom.c | 114 +++++++++++++--------- >> drivers/pci/controller/pci-host-common.c | 29 ++++++ >> drivers/pci/controller/pci-host-common.h | 2 + >> 5 files changed, 101 insertions(+), 52 deletions(-) >> --- >> base-commit: 590a64365d9bcc13ee644a3e73ffdc3df26cf23c >> change-id: 20251229-d3cold-bf99921960bb >> >> Best regards, >> -- >> Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> >> >>
On Thu, Jan 29, 2026 at 10:53:43AM +0530, Krishna Chaitanya Chundru wrote: > > > On 1/28/2026 8:25 PM, Bjorn Andersson wrote: > > On Wed, Jan 28, 2026 at 05:10:40PM +0530, Krishna Chaitanya Chundru wrote: > > > This series adds a common helper to determine when a PCIe host bridge > > > can safely enter D3cold, converts the DesignWare host driver to use that > > > helper, and enables D3cold support for Qualcomm PCIe controllers. > > > > > You only modify qcom_pcie_deinit_2_7_0() so which targets is this > > expected to work on and which targets have you tested it on. How can I > > test it and what outcome should I expect? > we modified qcom_pcie_deinit_2_7_() because we are trying to undo what we > are doing as part of init for other platforms, in init() we are just turning > on the resources. I tested this on lemans evk device. After this series we > can expect PCIe link will go to D3cold(provided there is no NVMe attach), > and cxpc can be achieved. For NVMe devices, mani is working on, in which > requires some psci changes[1] I have no objections to start with one platform, please consider what will happen to others (don't break existing users) and please document in the commit message that this only affects X, Y, Z platforms. > > > The first patch introduces pci_host_common_can_enter_d3cold() in > > > pci-host-common. The helper walks all devices on the bridge's bus and > > > only allows the host bridge to enter D3cold if all PCIe endpoints are > > > already in PCI_D3hot. For devices that may wake the system, it > > > additionally requires that the device support PME wakeup from D3cold > > > (via WAKE#). Devices without wakeup enabled are not restricted by this > > > check and may be left in D3cold. > > > > > > The second patch updates the DesignWare host driver to use this common > > > helper in dw_pcie_suspend_noirq(). Previously, the driver skipped > > > putting the link into L2 / device D3cold whenever L1 ASPM was enabled, > > > since some devices (e.g. NVMe) expect low resume latency and may not > > > tolerate deeper power states. However, such devices typically remain in > > > D0 and are already covered by the helper's requirement that all > > > endpoints be in D3hot before the host bridge may enter D3cold. Using the > > > shared helper removes this coarse heuristic and centralizes the D3cold > > > eligibility policy. > > > > > > The third patch enables D3cold support for Qualcomm PCIe controllers. It > > > adds pme_turn_off() support and switches to the DesignWare common > > > suspend/resume methods for device D3cold entry and exit. If the > > > controller is not kept in D3cold, the existing paths are used so that > > > ICC votes, OPP votes, and other resources remain managed as before. In > > > addition, qcom_pcie_deinit_2_7_0() is updated to explicitly disable > > > PCIe clocks and resets in the controller, and the now-unused "suspended" > > > flag is removed from struct qcom_pcie. > > > > > This is effectively just duplicating the commit messages. Lacking from > > both is a good explanation of the problem statement, but that might just > > be me not getting it? > We are adding support for D3cold for qcom controllers, this is a PCIe > feature, > I haven't added reference to qcom internal power state like CXPC since this > alone > will not achieve this. But I should have added to this as ultimate purpose > is to > have CXPC and main blocking is currently PCIe. Thank you. > > > > Could you please help me understand what the actual outcome of this > > series is? I was under the impression that this work would lead us > > towards unblocking CXPC, but the other patch you sent will prevent CXPC. > This will keep PCIe in D3cold and achieve CXPC if there is no NVMe > endpoints. > > No other patch is not preventing CXPC, it is just trying to tell genpd > framework that > don't turn off GENPD, if the controller is not suspended. if we don't have > that patch > when device is not suspended i.e not kept in D3cold the gdsc is getting > turned off > and PCIe link is going down. Until PCIe state is in D3cold, gdsc should not > be off > even in cxpc case. > Please do include such information in your cover letters or commit messages. By not assuming that recipients can read your mind, you will be able to get more engagement surrounding your patches - and this is a topic that we're very much interested in. Regards, Bjorn > Mani, > To avoid the confusion, can I club this patch[2] to this series in next > verision > > [1] https://lore.kernel.org/all/20251231162126.7728-1-manivannan.sadhasivam@oss.qualcomm.com > [2] [PATCH] PCI: qcom: Prevent GDSC power down on suspend - Krishna > Chaitanya Chundru <https://lore.kernel.org/all/20260128-genpd_fix-v1-1-cd45a249d12f@oss.qualcomm.com/> > > - Krishna Chaitanya. > > > > Regards, > > Bjorn > > > > > Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> > > > --- > > > Krishna Chaitanya Chundru (3): > > > PCI: host-common: Add shared D3cold eligibility helper for host bridges > > > PCI: dwc: Use common D3cold eligibility helper in suspend path > > > PCI: qcom: Add D3cold support > > > > > > drivers/pci/controller/dwc/pcie-designware-host.c | 7 +- > > > drivers/pci/controller/dwc/pcie-designware.h | 1 + > > > drivers/pci/controller/dwc/pcie-qcom.c | 114 +++++++++++++--------- > > > drivers/pci/controller/pci-host-common.c | 29 ++++++ > > > drivers/pci/controller/pci-host-common.h | 2 + > > > 5 files changed, 101 insertions(+), 52 deletions(-) > > > --- > > > base-commit: 590a64365d9bcc13ee644a3e73ffdc3df26cf23c > > > change-id: 20251229-d3cold-bf99921960bb > > > > > > Best regards, > > > -- > > > Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> > > > > > > >
© 2016 - 2026 Red Hat, Inc.