Message-ID: <1787b076-a07f-4ac2-bd50-55914c70461a@oss.qualcomm.com>
Date: Thu, 29 Jan 2026 10:53:43 +0530
From: Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>
To: Bjorn Andersson <andersson@...nel.org>,
        Manivannan Sadhasivam <mani@...nel.org>
Cc: Jingoo Han <jingoohan1@...il.com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Krzysztof Wilczyński <kwilczynski@...nel.org>,
        Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
        Will Deacon <will@...nel.org>, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, jonathanh@...dia.com
Subject: Re: [PATCH 0/3] PCI: qcom: Add D3cold support



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@....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@....qualcomm.com>
>>
>>

Powered by blists - more mailing lists