From: Manivannan Sadhasivam <mani@kernel.org>
To: Anthony Ruhier <aruhier@mailbox.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Baochen Qiang <baochen.qiang@oss.qualcomm.com>,
Vasanthakumar Thiagarajan
<vasanthakumar.thiagarajan@oss.qualcomm.com>,
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Subject: Re: [PATCH] PCI: Disable LTR on Qualcomm WCN7850 [17cb:1107] to allow ASPM L1.2
Date: Mon, 26 Oct 2026 12:55:25 +0530 [thread overview]
Message-ID: <at7x8K9Xxa92xW2j@debian> (raw)
In-Reply-To: <atvQtV71SbtMK-jZ@tour-anthony.aruhier.fr>
On Fri, Oct 23, 2026 at 11:49:22PM +0200, Anthony Ruhier wrote:
> On Fri, Oct 23, 2026 at 01:20:04PM -0500, Bjorn Helgaas wrote:
> > By "firmware reports LTR value", do you mean that the WCN7850 sends an
> > LTR Message with snooped/non-snooped values just below
> > LTR_L1.2_THRESHOLD?
> >
> > And since the reported LTR values are never greater than or equal to
> > LTR_L1.2_THRESHOLD, the link never enters L1.2?
>
This is correct.
> Not exactly. The firmware doesn't report a max snoop/no snoop that I could see
> in lspci (it's set at 0ns), but if I set one with setpci, the card still
> doesn't reach L1.2.
Max Snoop/No-Snoop latencies are supposed to be set by the host software, not
the Endpoint firmware. The Endpoint firmware only uses these values to send
their Snoop/No-Snoop latencies in the LTR message.
But there are two issues here in Qcom platforms:
1. Neither the BIOS, nor the PCI core/pcie-qcom driver set the Max
Snoop/No-Snoop latencies for the Endpoints/Upstream Ports based on the platform
requirement.
2. The L1_2_Threshold calculated by the PCI core doesn't match the Qcom platforms:
l1_2_threshold = 2 + 4 + t_common_mode + t_power_on;
On the Qcom platforms, T_POWER_ON is 0 by default. I initially misunderstood
that the T_POWER_ON value of '0' was wrong. But after checking more, I
understood that '0' was indeed the correct value, but there is one more
parameter that we are not taking into account, which is TL10_REFCLK_ON time. It
is ~40-80us depending on the platform.
Unfortunately, PCIe base spec didn't define any registers to pass the
TL10_REFCLK_ON time to the OS. I'm planning to introduce a DT property, set
it in Root Port node and take it account in the l1_2_threshold calculation.
Because of the issue (1), the Endpoint firmware reports 0 Snoop/No-Snoop
latencies as the LTR latencies cannot exceed Max Snoop/No-Snoop latencies set
by the host software. This is the behavior across all Endpoints connected to
the Qcom host machines.
So if the LTR requirement bit is set, and the Endpoint sends 0 latencies in LTR
message, then L1.2 is not entered all the time because, LTR > L1_2_Threshold.
The spec mandates that the link should enter L1.2 only if LTR <= L1_2_Threshold.
The reason why L1.2 is entered in Windows with same Endpoint is, Windows sets
L1_2_Threshold to 0. So LTR <= L1_2_Threshold condition gets satisfied.
But this is not the optimal approach. Ideally, the platform latency requirement
should properly be exposed through the Max Snoop/No-Snoop registers and let the
Endpoint specify its own latency requirement through the LTR message. I'm also
working on getting these values so that we can express these through DT. But we
cannot just program the DT read values directly as we need to account for
cumulative latencies along the path to the Root Port as per the PCI Firmware
Spec, v3.3, sec 4.6.6. Once I get the platform latencies, I will work on
programming it in the PCI core.
- Mani
--
மணிவண்ணன் சதாசிவம்
next prev parent reply other threads:[~2026-10-26 7:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 17:39 Anthony Ruhier via B4 Relay
2026-10-23 18:20 ` Bjorn Helgaas
2026-10-23 21:49 ` Anthony Ruhier
2026-10-25 21:16 ` Anthony Ruhier
2026-10-26 7:25 ` Manivannan Sadhasivam [this message]
2026-10-26 7:53 ` Manivannan Sadhasivam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=at7x8K9Xxa92xW2j@debian \
--to=mani@kernel.org \
--cc=aruhier@mailbox.org \
--cc=baochen.qiang@oss.qualcomm.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=jeff.johnson@oss.qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=vasanthakumar.thiagarajan@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®