The Qualcomm PCIe host controller driver added support for parsing the
-power-on-us property[1] from each Root Port node and programming it as
art of host initialization (PCI: qcom: Program T_POWER_ON) [2]. Prior to
this, T_POWER_ON was expected to be programmed correctly in hardware or
by the bootloader, but not all targets support this, which can lead to an
incorrectly calculated LTR_L1.2_THRESHOLD in aspm.c and improper L1.2 exit
behavior.

This series adds the t-power-on-us = <80>; property to the PCIe root
port node(s) on the following targets, so the controller programs the
correct T_POWER_ON value instead of relying on the (currently incorrect)
hardware default:

- kodiak
- lemans
- monaco
- hamoa
- glymur
- talos
- sm8750
- kaanapali

[1] https://lore.kernel.org/all/20260205093346.667898-1-krishna.chundru@oss.qualcomm.com/
[2] https://lore.kernel.org/all/20260428-t_power_on_fux-v5-0-f1ef926a91ff@oss.qualcomm.com/

Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
Krishna Chaitanya Chundru (8):
      arm64: dts: qcom: kodiak: Add t-power-on-us property for PCIe root ports
      arm64: dts: qcom: lemans: Add t-power-on-us property for PCIe root ports
      arm64: dts: qcom: monaco: Add t-power-on-us property for PCIe root ports
      arm64: dts: qcom: hamoa: Add t-power-on-us property for PCIe root ports
      arm64: dts: qcom: glymur: Add t-power-on-us property for PCIe root ports
      arm64: dts: qcom: talos: Add t-power-on-us property for PCIe root port
      arm64: dts: qcom: sm8750: Add t-power-on-us property for PCIe root port
      arm64: dts: qcom: kaanapali: Add t-power-on-us property for PCIe root port

 arch/arm64/boot/dts/qcom/glymur.dtsi    | 8 ++++++++
 arch/arm64/boot/dts/qcom/hamoa.dtsi     | 8 ++++++++
 arch/arm64/boot/dts/qcom/kaanapali.dtsi | 2 ++
 arch/arm64/boot/dts/qcom/kodiak.dtsi    | 4 ++++
 arch/arm64/boot/dts/qcom/lemans.dtsi    | 4 ++++
 arch/arm64/boot/dts/qcom/monaco.dtsi    | 4 ++++
 arch/arm64/boot/dts/qcom/sm8750.dtsi    | 2 ++
 arch/arm64/boot/dts/qcom/talos.dtsi     | 2 ++
 8 files changed, 34 insertions(+)
---
base-commit: 08df884136f1c1197bab2a27814404fd329d9aac
change-id: 20260911-t_pwr_on-069f454ebb23

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

On 9/11/26 8:50 AM, Krishna Chaitanya Chundru wrote:
> The Qualcomm PCIe host controller driver added support for parsing the
> -power-on-us property[1] from each Root Port node and programming it as
> art of host initialization (PCI: qcom: Program T_POWER_ON) [2]. Prior to
> this, T_POWER_ON was expected to be programmed correctly in hardware or
> by the bootloader, but not all targets support this, which can lead to an
> incorrectly calculated LTR_L1.2_THRESHOLD in aspm.c and improper L1.2 exit
> behavior.

This is a good problem description. Does it have observable effects
that could also be mentioned here, beyond perhaps lspci reporting
an odd value?


> This series adds the t-power-on-us = <80>; property to the PCIe root
> port node(s) on the following targets, so the controller programs the
> correct T_POWER_ON value instead of relying on the (currently incorrect)
> hardware default:
> 
> - kodiak
> - lemans
> - monaco
> - hamoa
> - glymur
> - talos
> - sm8750
> - kaanapali

Because you said "currently incorrect", it clearly applies to all of
these platforms. Are other ones that we support in the tree also
affected?

Konrad

On 9/21/2026 2:09 PM, Konrad Dybcio wrote:
> On 9/11/26 8:50 AM, Krishna Chaitanya Chundru wrote:
>> The Qualcomm PCIe host controller driver added support for parsing the
>> -power-on-us property[1] from each Root Port node and programming it as
>> art of host initialization (PCI: qcom: Program T_POWER_ON) [2]. Prior to
>> this, T_POWER_ON was expected to be programmed correctly in hardware or
>> by the bootloader, but not all targets support this, which can lead to an
>> incorrectly calculated LTR_L1.2_THRESHOLD in aspm.c and improper L1.2 exit
>> behavior.
> This is a good problem description. Does it have observable effects
> that could also be mentioned here, beyond perhaps lspci reporting
> an odd value?
we haven't seen direct problem till now, but we might seen some issue due to
incorrect LTR_L1.2_THRESHOLD value.
>> This series adds the t-power-on-us = <80>; property to the PCIe root
>> port node(s) on the following targets, so the controller programs the
>> correct T_POWER_ON value instead of relying on the (currently incorrect)
>> hardware default:
>>
>> - kodiak
>> - lemans
>> - monaco
>> - hamoa
>> - glymur
>> - talos
>> - sm8750
>> - kaanapali
> Because you said "currently incorrect", it clearly applies to all of
> these platforms. Are other ones that we support in the tree also
> affected?
yes all targets  will be affected, not sure about ipq platforms.
I added mostly active targets which we are currently using, I can extend if
recommended.

- Krishna Chaitanya.
>
> Konrad

On Mon, Sep 21, 2026 at 04:40:43PM +0530, Krishna Chaitanya Chundru wrote:
> 
> 
> On 9/21/2026 2:09 PM, Konrad Dybcio wrote:
> > On 9/11/26 8:50 AM, Krishna Chaitanya Chundru wrote:
> >> The Qualcomm PCIe host controller driver added support for parsing the
> >> -power-on-us property[1] from each Root Port node and programming it as
> >> art of host initialization (PCI: qcom: Program T_POWER_ON) [2]. Prior to
> >> this, T_POWER_ON was expected to be programmed correctly in hardware or
> >> by the bootloader, but not all targets support this, which can lead to an
> >> incorrectly calculated LTR_L1.2_THRESHOLD in aspm.c and improper L1.2 exit
> >> behavior.
> > This is a good problem description. Does it have observable effects
> > that could also be mentioned here, beyond perhaps lspci reporting
> > an odd value?
> we haven't seen direct problem till now, but we might seen some issue due to
> incorrect LTR_L1.2_THRESHOLD value.

Can you specify what issue can be seen without this series? I'd assume the
link will fail to enter L1.2 and will result in slightly more power drain as
the link can only enter L1.1.

- Mani

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

On 9/21/26 1:34 PM, Manivannan Sadhasivam wrote:
> On Mon, Sep 21, 2026 at 04:40:43PM +0530, Krishna Chaitanya Chundru wrote:
>>
>>
>> On 9/21/2026 2:09 PM, Konrad Dybcio wrote:
>>> On 9/11/26 8:50 AM, Krishna Chaitanya Chundru wrote:
>>>> The Qualcomm PCIe host controller driver added support for parsing the
>>>> -power-on-us property[1] from each Root Port node and programming it as
>>>> art of host initialization (PCI: qcom: Program T_POWER_ON) [2]. Prior to
>>>> this, T_POWER_ON was expected to be programmed correctly in hardware or
>>>> by the bootloader, but not all targets support this, which can lead to an
>>>> incorrectly calculated LTR_L1.2_THRESHOLD in aspm.c and improper L1.2 exit
>>>> behavior.
>>> This is a good problem description. Does it have observable effects
>>> that could also be mentioned here, beyond perhaps lspci reporting
>>> an odd value?
>> we haven't seen direct problem till now, but we might seen some issue due to
>> incorrect LTR_L1.2_THRESHOLD value.
> 
> Can you specify what issue can be seen without this series? I'd assume the
> link will fail to enter L1.2 and will result in slightly more power drain as
> the link can only enter L1.1.

Would that produce an explicit warning message somewhere?

i.e. can I reasonably be able to tell I'm missing this change and
I need it?

(if not, this is of course not a blocker, but the answer to that
question is always worth sharing)

Konrad

On Mon, Sep 21, 2026 at 01:44:50PM +0200, Konrad Dybcio wrote:
> On 9/21/26 1:34 PM, Manivannan Sadhasivam wrote:
> > On Mon, Sep 21, 2026 at 04:40:43PM +0530, Krishna Chaitanya Chundru wrote:
> >>
> >>
> >> On 9/21/2026 2:09 PM, Konrad Dybcio wrote:
> >>> On 9/11/26 8:50 AM, Krishna Chaitanya Chundru wrote:
> >>>> The Qualcomm PCIe host controller driver added support for parsing the
> >>>> -power-on-us property[1] from each Root Port node and programming it as
> >>>> art of host initialization (PCI: qcom: Program T_POWER_ON) [2]. Prior to
> >>>> this, T_POWER_ON was expected to be programmed correctly in hardware or
> >>>> by the bootloader, but not all targets support this, which can lead to an
> >>>> incorrectly calculated LTR_L1.2_THRESHOLD in aspm.c and improper L1.2 exit
> >>>> behavior.
> >>> This is a good problem description. Does it have observable effects
> >>> that could also be mentioned here, beyond perhaps lspci reporting
> >>> an odd value?
> >> we haven't seen direct problem till now, but we might seen some issue due to
> >> incorrect LTR_L1.2_THRESHOLD value.
> > 
> > Can you specify what issue can be seen without this series? I'd assume the
> > link will fail to enter L1.2 and will result in slightly more power drain as
> > the link can only enter L1.1.
> 

[Correcting my own reply]

The power drain issue will only happen if the default value is higher than the
programmed one. If the default is lower, L1.2 would be entered too aggressively
and the link may fail to exit L1.2, resulting in LDn. This would be
catastrophic.

> Would that produce an explicit warning message somewhere?
> 

Nope. PCI core would happily use whatever threshold programmed in the registers.

> i.e. can I reasonably be able to tell I'm missing this change and
> I need it?
> 
> (if not, this is of course not a blocker, but the answer to that
> question is always worth sharing)
> 

We can warn in the pcie-qcom driver though as it parses this property. But we
should only do so for SoCs included in this series, selectively.

- Mani

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