From: Aksh Garg <a-garg7@ti.com>
To: Hans Zhang <18255117159@163.com>,
Manikandan Karunakaran Pillai <mpillai@cadence.com>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"lpieralisi@kernel.org" <lpieralisi@kernel.org>,
"kwilczynski@kernel.org" <kwilczynski@kernel.org>,
"mani@kernel.org" <mani@kernel.org>
Cc: "robh@kernel.org" <robh@kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Siddharth Vadapalli <s-vadapalli@ti.com>
Subject: Re: [PATCH v4 2/2] PCI: cadence: Add debugfs property to provide LTSSM status of the PCIe link
Date: Wed, 13 May 2026 17:00:15 +0530 [thread overview]
Message-ID: <31b5f0ad-70a5-4397-8740-6808d0266a7e@ti.com> (raw)
In-Reply-To: <c0bd820d-9716-4109-9d5e-7e72e0716cf1@163.com>
On 13/05/26 14:25, Hans Zhang wrote:
>
>
> On 5/13/26 16:34, Aksh Garg wrote:
>
>>>>
>>>
>>> The above LTSSM states are internal LTSSM encoding states and may not
>>> be available for software to use.
>>> The LTSSM states in the document pointed by Aksh (TI Soc) are the
>>> states available in all cadence controllers.
>>
>> Is this true for HPA IPs as well? The test performed by Hans:
>> root@orangepi6plus:~# cat /sys/kernel/debug/cdns_pcie_a0*/ltss*
>> L0_STATE (0x29)
>> L0_STATE (0x29)
>> L0_STATE (0x29)
>>
>> This implies that the L0_STATE LTSSM state is mapped to 0x29 (41) there,
>> which according to your response is internal LTSSM encoding, and hence
>> the register read should have resulted in 0x10 instead of 0x29.
>>
>
> Hi Aksh,
>
>
> For HPA, my view is similar to that of DWC - it requires a common
> internal LTSSM state. For each of its own Root Port drivers, a callback
> can be used to implement the reading of LTSSM. This part can be referred
> to as the implementation of the function in DWC.
>
>
> static inline enum dw_pcie_ltssm dw_pcie_get_ltssm(struct dw_pcie *pci)
> {
> u32 val;
>
> if (pci->ops && pci->ops->get_ltssm)
> return pci->ops->get_ltssm(pci);
>
> val = dw_pcie_readl_dbi(pci, PCIE_PORT_DEBUG0);
>
> return (enum dw_pcie_ltssm)FIELD_GET(PORT_LOGIC_LTSSM_STATE_MASK,
> val);
> }
>
>
> static int ltssm_status_show(struct seq_file *s, void *v)
> {
> struct dw_pcie *pci = s->private;
> enum dw_pcie_ltssm val;
>
> val = dw_pcie_get_ltssm(pci);
> seq_printf(s, "%s (0x%02x)\n", dw_pcie_ltssm_status_string(val), val);
>
> return 0;
> }
>
>
>
> For example, it can be modified as follows. Of course, the function name
> will start with "cdns".
>
> For LGA IP, currently we will allow each Root Port driver to implement
> the corresponding ops::get_ltssm() by itself.
>
> static int ltssm_status_show(struct seq_file *s, void *v)
> {
> struct dw_pcie *pci = s->private;
> enum dw_pcie_ltssm val;
>
> if (pci->ops && pci->ops->get_ltssm)
> val = pci->ops->get_ltssm(pci);
> else
> val = dw_pcie_get_ltssm(pci);
> seq_printf(s, "%s (0x%02x)\n", dw_pcie_ltssm_status_string(val), val);
>
> return 0;
> }
>
The process above tells how to read the register and get the LTSSM
state values. However, my concern is whether we require different LTSSM
state encoding in your debugfs patch, one for LGA, and other for HPA.
This is because the L0_state seems to have different values in the LTSSM
fields of different IPs. On LGA, the L0_state seems to have value as
0x10 in the register (as can be seen in the J7200 TRM). On HPA, the
L0_state seems to have value of 0x29 in the register (as can be seen in
your test logs in the cover letter). Hence, if we want to print the
LTSSM state string in the debugfs, then for LGA IPs, 0x10 value should
print L0_STATE, and for HPA IPs, 0x41 value should print L0_state.
Please correct me if I am missing something here.
>
> Best regards,
> Hans
>
next prev parent reply other threads:[~2026-05-13 11:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-08 3:40 [PATCH v4 0/2] PCI: cadence: Add LTSSM debugfs Hans Zhang
2026-05-08 3:41 ` [PATCH v4 1/2] PCI: cadence: Add HPA architecture flag Hans Zhang
2026-05-08 3:41 ` [PATCH v4 2/2] PCI: cadence: Add debugfs property to provide LTSSM status of the PCIe link Hans Zhang
2026-05-08 4:19 ` sashiko-bot
2026-05-08 4:31 ` Hans Zhang
2026-05-13 5:23 ` Aksh Garg
2026-05-13 6:11 ` Manikandan Karunakaran Pillai
2026-05-13 6:39 ` Hans Zhang
2026-05-13 7:08 ` Manikandan Karunakaran Pillai
2026-05-13 8:34 ` Aksh Garg
2026-05-13 8:55 ` Hans Zhang
2026-05-13 11:30 ` Aksh Garg [this message]
2026-05-13 12:04 ` Hans Zhang
2026-05-14 1:39 ` Manikandan Karunakaran Pillai
2026-05-14 1:46 ` Hans Zhang
2026-05-14 4:25 ` Manikandan Karunakaran Pillai
2026-05-13 6:37 ` Hans Zhang
2026-05-13 8:25 ` Aksh Garg
2026-05-13 8:29 ` Hans Zhang
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=31b5f0ad-70a5-4397-8740-6808d0266a7e@ti.com \
--to=a-garg7@ti.com \
--cc=18255117159@163.com \
--cc=bhelgaas@google.com \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=mpillai@cadence.com \
--cc=robh@kernel.org \
--cc=s-vadapalli@ti.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).