PCI: qcom: Add D3cold support

Krishna Chaitanya Chundru krishna.chundru at oss.qualcomm.com
Sun May 3 20:37:31 PDT 2026



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




More information about the linux-arm-kernel mailing list