| Message ID | 20240422185803.3575319-3-sean.anderson@linux.dev |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | phy: zynqmp: A PCIe fix and debugfs support | expand |
On 4/22/24 20:58, Sean Anderson wrote:
> Similarly to DisplayPort, nonzero PCIe lanes never achieve PLL lock [1].
What is this [1] for?
M
On 4/23/24 02:25, Michal Simek wrote: > > > On 4/22/24 20:58, Sean Anderson wrote: >> Similarly to DisplayPort, nonzero PCIe lanes never achieve PLL lock [1]. > > What is this [1] for? I was originally going to have the comment below the fold in the commit message as a footnote. I forgot to remove this after editing. --Sean
diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c index b507ed4c3053..08c88dcd7799 100644 --- a/drivers/phy/xilinx/phy-zynqmp.c +++ b/drivers/phy/xilinx/phy-zynqmp.c @@ -624,11 +624,13 @@ static int xpsgtr_phy_power_on(struct phy *phy) if (!xpsgtr_phy_init_required(gtr_phy)) return ret; /* - * Wait for the PLL to lock. For DP, only wait on DP0 to avoid - * cumulating waits for both lanes. The user is expected to initialize - * lane 0 last. + * Wait for the PLL to lock. For DP and PCIe, only wait on instance 0 + * to avoid cumulative waits for both lanes. The user is expected to + * initialize lane 0 last. */ - if (gtr_phy->protocol != ICM_PROTOCOL_DP || !gtr_phy->instance) + if ((gtr_phy->protocol != ICM_PROTOCOL_DP && + gtr_phy->protocol != ICM_PROTOCOL_PCIE) || + !gtr_phy->instance) ret = xpsgtr_wait_pll_lock(phy); return ret;
Similarly to DisplayPort, nonzero PCIe lanes never achieve PLL lock [1]. Don't wait for them. Signed-off-by: Sean Anderson <sean.anderson@linux.dev> --- Maybe it's actually that only the final lane configured locks? I haven't tested this out. drivers/phy/xilinx/phy-zynqmp.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)