linux-arm-kernel.lists.infradead.org archive mirror
 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" <kwilczynski@kernel.org>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Manivannan Sadhasivam" <mani@kernel.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 v4 1/2] PCI: xilinx: Wait for link-up status during initialization
Date: Tue, 10 Jun 2025 13:57:34 -0500	[thread overview]
Message-ID: <20250610185734.GA819344@bhelgaas> (raw)
In-Reply-To: <20250610143919.393168-1-mike.looijmans@topic.nl>

On Tue, Jun 10, 2025 at 04:39:03PM +0200, Mike Looijmans wrote:
> When the driver loads, the transceiver and endpoint may still be 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. Existing reference designs worked because the endpoint and
> PL were initialized by a bootloader. If the endpoint power and/or reset
> is supplied by the kernel, or if the PL is programmed from within the
> kernel, the link won't be up yet and the driver just has to wait for
> link training to finish.
> 
> As the PCIe spec allows up to 100 ms time to establish a link, we'll
> allow up to 200ms before giving up.

> +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,
> +			2 * PCIE_T_RRS_READY_MS * USEC_PER_MSEC);
> +}

I don't think this is what PCIE_T_RRS_READY_MS is for.  Sec 6.6.1
requires 100ms *after* the link is up before sending config requests:

  For cases where system software cannot determine that DRS is
  supported by the attached device, or by the Downstream Port above
  the attached device:

    ◦ With a Downstream Port that does not support Link speeds greater
      than 5.0 GT/s, software must wait a minimum of 100 ms following
      exit from a Conventional Reset before sending a Configuration
      Request to the device immediately below that Port.

    ◦ With a Downstream Port that supports Link speeds greater than
      5.0 GT/s, software must wait a minimum of 100 ms after Link
      training completes before sending a Configuration Request to the
      device immediately below that Port. Software can determine when
      Link training completes by polling the Data Link Layer Link
      Active bit or by setting up an associated interrupt (see §
      Section 6.7.3.3).  It is strongly recommended for software to
      use this mechanism whenever the Downstream Port supports it.

Bjorn


  parent reply	other threads:[~2025-06-10 22:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.69fac8ab-ab7f-45b5-992e-b4c97ec31d85@emailsignatures365.codetwo.com>
2025-06-10 14:39 ` [PATCH v4 1/2] PCI: xilinx: Wait for link-up status during initialization Mike Looijmans
2025-06-10 14:39   ` [PATCH v4 2/2] PCI: xilinx: Support reset GPIO for PERST# Mike Looijmans
2025-06-10 19:07     ` Bjorn Helgaas
2025-06-11  6:45       ` Mike Looijmans
2025-06-10 18:57   ` Bjorn Helgaas [this message]
2025-06-11  6:48     ` [PATCH v4 1/2] PCI: xilinx: Wait for link-up status during initialization Mike Looijmans
2025-06-25 21:46       ` Manivannan Sadhasivam
2025-06-25 21:50         ` Manivannan Sadhasivam
2025-06-10 19:12   ` Bjorn Helgaas
2025-06-11  7:00     ` 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=20250610185734.GA819344@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=kwilczynski@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.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;
as well as URLs for NNTP newsgroup(s).