Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Shawn Lin <shawn.lin@rock-chips.com>
To: Niklas Cassel <cassel@kernel.org>
Cc: shawn.lin@rock-chips.com, "Bjorn Helgaas" <bhelgaas@google.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	linux-pci@vger.kernel.org, linux-rockchip@lists.infradead.org
Subject: Re: [PATCH] PCI: dw-rockchip: Enable L0S capability
Date: Thu, 10 Apr 2025 16:57:26 +0800	[thread overview]
Message-ID: <11fa4ae4-2765-8d10-176f-602bf9d81d4b@rock-chips.com> (raw)
In-Reply-To: <Z_eEw-l6SG-lF_7R@ryzen>

在 2025/04/10 星期四 16:43, Niklas Cassel 写道:
> Hello Shawn,
> 
> On Thu, Apr 10, 2025 at 09:36:21AM +0800, Shawn Lin wrote:
>> L0S capability isn't enabled on all SoCs by default, so enabling it
>> in order to make ASPM L0S work on Rockchip platforms. We have been
>> testing it for quite a long time and the default FTS number provided
>> by DWC core is broken since it fits only for DWC PHY IP but not for
>> other types of PHY IP from other vendors.
> 
> If we take the rk3588 SoC for example,
> some PCIe controllers use PHY:
> drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
> some PCIe controllers use PHY:
> drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
> 
> This second PHY is obviously a Synopsys PHY.
> 
> So, I think the commit message is a bit confusing/misleading,
> since IMO the second PHY driver is for a DWC PHY IP.
> 
> Is this N_FTS value correct for both of these PHYs?

yes, the vaule is PHY depends, but we don't know which PHY is
used currently. So the safest one is 255 which is the max defined
in spec, seems work fine for both under massive test.

> 
> 
> Having this code in ->start_link() looks incorrect.
> 
> rockchip_pcie_configure_rc(), calls dw_pcie_host_init().
> 
> dw_pcie_host_init() first calls dw_pcie_setup_rc(), which calls dw_pcie_setup().
> dw_pcie_setup() will write pci->n_fts[0] / pci->n_fts[1].
> 
> dw_pcie_host_init() then calls dw_pcie_start_link()
> (which calls ->start_link()).
> 
> So, setting pci->n_fts[0] / pci->n_fts[1] in ->start_link() is thus too late.
> 

Oops, I did move n_fts a bit afterward after testing, in order to look
more reasonable until we enable L0S capability. Let me see how to fix
it.

Thannks for the review.

> 
> Kind regards,
> Niklas
> 
> 
>>
>> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>> ---
>>
>>   drivers/pci/controller/dwc/pcie-dw-rockchip.c | 14 ++++++++++++++
>>   1 file changed, 14 insertions(+)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>> index 21dc99c..56acfea 100644
>> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
>> @@ -185,6 +185,20 @@ static int rockchip_pcie_link_up(struct dw_pcie *pci)
>>   static int rockchip_pcie_start_link(struct dw_pcie *pci)
>>   {
>>   	struct rockchip_pcie *rockchip = to_rockchip_pcie(pci);
>> +	u32 cap, lnkcap;
>> +
>> +	/* Enable L0S capability for all SoCs */
>> +	cap = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
>> +	if (cap) {
>> +		/* Default fts number(210) is broken, override it */
>> +		pci->n_fts[0] = 255; /* Gen1 */
>> +		pci->n_fts[1] = 255; /* Gen2+ */
>> +		lnkcap = dw_pcie_readl_dbi(pci, cap + PCI_EXP_LNKCAP);
>> +		lnkcap |= PCI_EXP_LNKCAP_ASPM_L0S;
>> +		dw_pcie_dbi_ro_wr_en(pci);
>> +		dw_pcie_writel_dbi(pci, cap + PCI_EXP_LNKCAP, lnkcap);
>> +		dw_pcie_dbi_ro_wr_dis(pci);
>> +	}
>>   
>>   	/* Reset device */
>>   	gpiod_set_value_cansleep(rockchip->rst_gpio, 0);
>> -- 
>> 2.7.4
>>
> 

  reply	other threads:[~2025-04-10  9:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-10  1:36 [PATCH] PCI: dw-rockchip: Enable L0S capability Shawn Lin
2025-04-10  8:43 ` Niklas Cassel
2025-04-10  8:57   ` Shawn Lin [this message]
2025-04-10  8:53 ` Niklas Cassel

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=11fa4ae4-2765-8d10-176f-602bf9d81d4b@rock-chips.com \
    --to=shawn.lin@rock-chips.com \
    --cc=bhelgaas@google.com \
    --cc=cassel@kernel.org \
    --cc=kw@linux.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=lpieralisi@kernel.org \
    /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