public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Mike Looijmans <mike.looijmans@topic.nl>
Cc: linux-pci@vger.kernel.org, "Bjorn Helgaas" <bhelgaas@google.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
	"Michal Simek" <michal.simek@amd.com>,
	"Rob Herring" <robh@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/2] pcie-xilinx: Wait for link-up status during initialization
Date: Wed, 9 Apr 2025 10:17:54 -0500	[thread overview]
Message-ID: <20250409151754.GA283974@bhelgaas> (raw)
In-Reply-To: <20250409144930.10402-1-mike.looijmans@topic.nl>

Please make the subject line match previous changes to this driver.
See "git log --oneline drivers/pci/controller/pcie-xilinx.c"

On Wed, Apr 09, 2025 at 04:49:24PM +0200, Mike Looijmans wrote:
> When the driver loads, the transceiver may still be in the state of
> setting up a link. Wait for that to complete before continuing. This
> fixes that the PCIe core does not work when loading the PL bitstream
> from userspace. There's only milliseconds between the FPGA boot and the
> core initializing in that case, and the link won't be up yet. The design
> only worked when the FPGA was programmed in the bootloader, as that will
> give the system hundreds of milliseconds to boot.
> 
> As the PCIe spec allows up to 100 ms time to establish a link, we'll
> allow up to 200ms before giving up.

This sounds like there's still a race between userspace loading the PL
bitstream and the driver waiting for link up, but we're just waiting
longer in the kernel so userspace has more chance of winning the race.
Is that true?

> @@ -126,6 +127,19 @@ static inline bool xilinx_pcie_link_up(struct xilinx_pcie *pcie)
>  		XILINX_PCIE_REG_PSCR_LNKUP) ? 1 : 0;
>  }
>  
> +static int xilinx_pci_wait_link_up(struct xilinx_pcie *pcie)
> +{
> +	u32 val;
> +
> +	/*
> +	 * PCIe r6.0, sec 6.6.1 provides 100ms timeout. Since this is FPGA
> +	 * fabric, we're more lenient and allow 200 ms for link training.
> +	 */
> +	return readl_poll_timeout(pcie->reg_base + XILINX_PCIE_REG_PSCR, val,
> +			(val & XILINX_PCIE_REG_PSCR_LNKUP), 2 * USEC_PER_MSEC,
> +			200 * USEC_PER_MSEC);

There should be a #define in drivers/pci/pci.h for this 100ms value
that you can use here to connect this more closely with the spec.

Maybe there's a way to use read_poll_timeout(), readx_poll_timeout(),
or something similar so we can use xilinx_pcie_link_up() directly
instead of reimplementing it here?

> +}
> +
>  /**
>   * xilinx_pcie_clear_err_interrupts - Clear Error Interrupts
>   * @pcie: PCIe port information
> @@ -493,7 +507,7 @@ static void xilinx_pcie_init_port(struct xilinx_pcie *pcie)
>  {
>  	struct device *dev = pcie->dev;
>  
> -	if (xilinx_pcie_link_up(pcie))
> +	if (!xilinx_pci_wait_link_up(pcie))
>  		dev_info(dev, "PCIe Link is UP\n");
>  	else
>  		dev_info(dev, "PCIe Link is DOWN\n");


  parent reply	other threads:[~2025-04-09 15:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.d67fd5a1-30a5-4d5a-a4ef-dde83ebcdd8d@emailsignatures365.codetwo.com>
2025-04-09 14:49 ` [PATCH v3 1/2] pcie-xilinx: Wait for link-up status during initialization Mike Looijmans
2025-04-09 14:49   ` [PATCH v3 2/2] pcie-xilinx: Support reset GPIO for PERST# Mike Looijmans
2025-04-09 15:17   ` Bjorn Helgaas [this message]
2025-04-10  6:00     ` [PATCH v3 1/2] pcie-xilinx: Wait for link-up status during initialization Mike Looijmans

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=20250409151754.GA283974@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=michal.simek@amd.com \
    --cc=mike.looijmans@topic.nl \
    --cc=robh@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