[PATCH v2 1/2] PCI/ASPM: Override the ASPM and Clock PM states set by BIOS for devicetree platforms

[Manivannan Sadhasivam]

On Wed, Oct 15, 2025 at 06:30:54PM -0500, Bjorn Helgaas wrote:
> On Wed, Oct 15, 2025 at 09:00:41PM +0800, Shawn Lin wrote:
> > ...
> 
> > For now, this is a acceptable option if default ASPM policy enable
> > L1ss w/o checking if the HW could supports it... But how about
> > adding supports-clkreq stuff to upstream host driver directly? That
> > would help folks enable L1ss if the HW is ready and they just need
> > adding property to the DT.
> > ...
> 
> > The L1ss support is quite strict and need several steps to check, so we
> > didn't add supports-clkreq for them unless the HW is ready to go...
> > 
> > For adding supports of L1ss,
> > [1] the HW should support CLKREQ#, expecially for PCIe3.0 case on Rockchip
> > SoCs , since both  CLKREQ# of RC and EP should connect to the
> > 100MHz crystal generator's enable pin, as L1.2 need to disable refclk as
> > well. If the enable pin is high active, the HW even need a invertor....
> > 
> > [2] define proper clkreq iomux to pinctrl of pcie node
> > [3] make sure the devices work fine with L1ss.(It's hard to check the slot
> > case with random devices in the wild )
> > [4] add supports-clkreq to the DT and enable
> > CONFIG_PCIEASPM_POWER_SUPERSAVE
> 
> I don't understand the details of the supports-clkreq issue.
> 
> If we need to add supports-clkreq to devicetree, I want to understand
> why we need it there when we don't seem to need it for ACPI systems.
> 
> Generally the OS relies on what the hardware advertises, e.g., in Link
> Capabilities and the L1 PM Substates Capability, and what is available
> from firmware, e.g., the ACPI _DSM for Latency Tolerance Reporting.
> 
> On the ACPI side, I don't think we get any specific information about
> CLKREQ#.  Can somebody explain why we do need it on the devicetree
> side?
> 

I think there is a disconnect between enabling L1ss CAP and CLKREQ#
availability.. When L1ss CAP is enabled for the Root Port in the hardware, there
is no guarantee that CLKREQ# is also available. If CLKREQ# is not available,
then if L1ss is enabled by the OS, it is not possible to exit the L1ss states
(assuming that L1ss is entered due to CLKREQ# in deassert (default) state).

Yes, there seems to be no standard way to know CLKREQ# presence in ACPI, but
in devicetree, we have this 'supports-clkreq' property to tell the OS that
CLKREQ# is available in the platform. But unfortunately, this property is not
widely used by the devicetrees out there. So we cannot use it in generic
pci/aspm.c driver.

We can certainly rely on the BIOS to enable L1ss as the fw developers would
have the knowledge of the CLKREQ# availability. But BIOS is not a thing on
mobile and embedded platforms where L1ss would come handy.

What I would suggest is, the host controller drivers (mostly for devicetree
platforms) should enable L1ss CAP for the Root Port only if they know that
CLKREQ# is available. They can either rely on the 'supports-clkreq' property or
some platform specific knowledge (for instance, on all Qcom platforms, we
certainly know that CLKREQ# is available, but we don't set the DT property).

Then in the generic pci/aspm.c driver, we can just enable L1ss for all devices
if the CAP is set, which we do currently.

- Mani

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