From: Niklas Cassel <cassel@kernel.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Heiko Stuebner" <heiko@sntech.de>,
"Wilfred Mallawa" <wilfred.mallawa@wdc.com>,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org
Subject: Re: [PATCH v2] PCI: dw-rockchip: Delay link training after hot reset in EP mode
Date: Wed, 18 Jun 2025 16:40:11 +0200 [thread overview]
Message-ID: <aFLPyxZD5lkAtw6b@ryzen> (raw)
In-Reply-To: <aFLL0vPFzxdVOR9a@ryzen>
On Wed, Jun 18, 2025 at 04:23:19PM +0200, Niklas Cassel wrote:
> On Tue, Jun 17, 2025 at 05:05:23PM -0500, Bjorn Helgaas wrote:
> > On Tue, Jun 17, 2025 at 05:01:16PM -0500, Bjorn Helgaas wrote:
> > > On Fri, Jun 13, 2025 at 12:19:09PM +0200, Niklas Cassel wrote:
> >
> > Oh, and this sets PCIE_LTSSM_ENABLE_ENHANCE | PCIE_LTSSM_APP_DLY2_EN
> > once at probe-time, but what about after a link-down/link-up cycle?
> >
> > Don't we need to set PCIE_LTSSM_ENABLE_ENHANCE |
> > PCIE_LTSSM_APP_DLY2_EN again when the link comes up so we don't have
> > the same race when the link goes down again?
>
> Nope, we don't.
>
> To verify I used this patch:
>
> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> index be239254aacd..e79add5412b8 100644
> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> @@ -506,6 +506,8 @@ static irqreturn_t rockchip_pcie_ep_sys_irq_thread(int irq, void *arg)
> if (reg & PCIE_LINK_REQ_RST_NOT_INT) {
> dev_dbg(dev, "hot reset or link-down reset\n");
> dw_pcie_ep_linkdown(&pci->ep);
> + pr_info("PCIE_CLIENT_HOT_RESET_CTRL after reset: %#x\n",
> + rockchip_pcie_readl_apb(rockchip, PCIE_CLIENT_HOT_RESET_CTRL));
> /* Stop delaying link training. */
> val = HIWORD_UPDATE_BIT(PCIE_LTSSM_APP_DLY2_DONE);
> rockchip_pcie_writel_apb(rockchip, val,
>
>
>
>
> [ 85.979567] rockchip-dw-pcie a40000000.pcie-ep: hot reset or link-down reset
> [ 85.980210] PCIE_CLIENT_HOT_RESET_CTRL after reset: 0x12
> [ 93.720413] rockchip-dw-pcie a40000000.pcie-ep: hot reset or link-down reset
> [ 93.721074] PCIE_CLIENT_HOT_RESET_CTRL after reset: 0x12
>
> 0x12 == bit 1 and bit 4 are set.
>
> bit 1: app_dly2_en
> bit 4: app_ltssm_enable_enhance
Oh, and just to verify that the hardware does not clear the app_dly2_en bit
when we write the app_dly2_done bit, I ran the same test, but with the
prints in rockchip_pcie_ep_sys_irq_thread(), just after calling
dw_pcie_ep_linkup(&pci->ep); and got the same result:
[ 57.176862] rockchip-dw-pcie a40000000.pcie-ep: link up
[ 57.177338] PCIE_CLIENT_HOT_RESET_CTRL after linkup: 0x12
[ 72.448052] rockchip-dw-pcie a40000000.pcie-ep: link up
[ 72.448527] PCIE_CLIENT_HOT_RESET_CTRL after linkup: 0x12
So I think this patch is good as is.
(Except for the citation style in the commit message which you didn't like :))
Kind regards,
Niklas
WARNING: multiple messages have this Message-ID (diff)
From: Niklas Cassel <cassel@kernel.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Heiko Stuebner" <heiko@sntech.de>,
"Wilfred Mallawa" <wilfred.mallawa@wdc.com>,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org
Subject: Re: [PATCH v2] PCI: dw-rockchip: Delay link training after hot reset in EP mode
Date: Wed, 18 Jun 2025 16:40:11 +0200 [thread overview]
Message-ID: <aFLPyxZD5lkAtw6b@ryzen> (raw)
In-Reply-To: <aFLL0vPFzxdVOR9a@ryzen>
On Wed, Jun 18, 2025 at 04:23:19PM +0200, Niklas Cassel wrote:
> On Tue, Jun 17, 2025 at 05:05:23PM -0500, Bjorn Helgaas wrote:
> > On Tue, Jun 17, 2025 at 05:01:16PM -0500, Bjorn Helgaas wrote:
> > > On Fri, Jun 13, 2025 at 12:19:09PM +0200, Niklas Cassel wrote:
> >
> > Oh, and this sets PCIE_LTSSM_ENABLE_ENHANCE | PCIE_LTSSM_APP_DLY2_EN
> > once at probe-time, but what about after a link-down/link-up cycle?
> >
> > Don't we need to set PCIE_LTSSM_ENABLE_ENHANCE |
> > PCIE_LTSSM_APP_DLY2_EN again when the link comes up so we don't have
> > the same race when the link goes down again?
>
> Nope, we don't.
>
> To verify I used this patch:
>
> diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> index be239254aacd..e79add5412b8 100644
> --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
> @@ -506,6 +506,8 @@ static irqreturn_t rockchip_pcie_ep_sys_irq_thread(int irq, void *arg)
> if (reg & PCIE_LINK_REQ_RST_NOT_INT) {
> dev_dbg(dev, "hot reset or link-down reset\n");
> dw_pcie_ep_linkdown(&pci->ep);
> + pr_info("PCIE_CLIENT_HOT_RESET_CTRL after reset: %#x\n",
> + rockchip_pcie_readl_apb(rockchip, PCIE_CLIENT_HOT_RESET_CTRL));
> /* Stop delaying link training. */
> val = HIWORD_UPDATE_BIT(PCIE_LTSSM_APP_DLY2_DONE);
> rockchip_pcie_writel_apb(rockchip, val,
>
>
>
>
> [ 85.979567] rockchip-dw-pcie a40000000.pcie-ep: hot reset or link-down reset
> [ 85.980210] PCIE_CLIENT_HOT_RESET_CTRL after reset: 0x12
> [ 93.720413] rockchip-dw-pcie a40000000.pcie-ep: hot reset or link-down reset
> [ 93.721074] PCIE_CLIENT_HOT_RESET_CTRL after reset: 0x12
>
> 0x12 == bit 1 and bit 4 are set.
>
> bit 1: app_dly2_en
> bit 4: app_ltssm_enable_enhance
Oh, and just to verify that the hardware does not clear the app_dly2_en bit
when we write the app_dly2_done bit, I ran the same test, but with the
prints in rockchip_pcie_ep_sys_irq_thread(), just after calling
dw_pcie_ep_linkup(&pci->ep); and got the same result:
[ 57.176862] rockchip-dw-pcie a40000000.pcie-ep: link up
[ 57.177338] PCIE_CLIENT_HOT_RESET_CTRL after linkup: 0x12
[ 72.448052] rockchip-dw-pcie a40000000.pcie-ep: link up
[ 72.448527] PCIE_CLIENT_HOT_RESET_CTRL after linkup: 0x12
So I think this patch is good as is.
(Except for the citation style in the commit message which you didn't like :))
Kind regards,
Niklas
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-06-18 16:36 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-13 10:19 [PATCH v2] PCI: dw-rockchip: Delay link training after hot reset in EP mode Niklas Cassel
2025-06-13 10:19 ` Niklas Cassel
2025-06-13 11:22 ` Manivannan Sadhasivam
2025-06-13 11:22 ` Manivannan Sadhasivam
2025-06-17 22:01 ` Bjorn Helgaas
2025-06-17 22:01 ` Bjorn Helgaas
2025-06-17 22:05 ` Bjorn Helgaas
2025-06-17 22:05 ` Bjorn Helgaas
2025-06-18 14:23 ` Niklas Cassel
2025-06-18 14:23 ` Niklas Cassel
2025-06-18 14:40 ` Niklas Cassel [this message]
2025-06-18 14:40 ` Niklas Cassel
2025-06-18 19:54 ` Bjorn Helgaas
2025-06-18 19:54 ` Bjorn Helgaas
2025-06-18 14:04 ` Niklas Cassel
2025-06-18 14:04 ` Niklas Cassel
2025-06-18 19:59 ` Bjorn Helgaas
2025-06-18 19:59 ` Bjorn Helgaas
2025-06-19 9:53 ` Niklas Cassel
2025-06-19 9: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=aFLPyxZD5lkAtw6b@ryzen \
--to=cassel@kernel.org \
--cc=bhelgaas@google.com \
--cc=heiko@sntech.de \
--cc=helgaas@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=robh@kernel.org \
--cc=wilfred.mallawa@wdc.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.