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.
> +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.
Does this FPGA fabric refer to the Root Port or to the Endpoint? We
should know whether this issue is common to all xilinx Root Ports or
specific to certain Endpoints.
I assume that even if we wait for the link to come up and then wait
PCIE_T_RRS_READY_MS before sending config requests, this Endpoint is
still not ready to return an RRS response? I'm looking at this text
from sec 6.6.1:
Unless Readiness Notifications mechanisms are used, the Root Complex
and/or system software must allow at least 1.0 s following exit from
a Conventional Reset of a device, before determining that the device
is broken if it fails to return a Successful Completion status for a
valid Configuration Request. This period is independent of how
quickly Link training completes.
Note: This delay is analogous to the Trhfa parameter specified for
PCI/PCI-X, and is intended to allow an adequate amount of time for
devices which require self initialization.
It seems like the PCI core RRS handling should already account for
this 1.0 s period.
> + */
> + 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);
> +}
