[PATCH v2] PCI: rockchip: Skip the Tpvperl wait when power is already valid

Manivannan Sadhasivam manivannan.sadhasivam at oss.qualcomm.com
Wed Oct 14 00:27:47 PDT 2026


On 2026-09-11 22:15 +0100, Enrique Hernández Bello wrote:
> Since commit c47f90be4c89 ("PCI: rockchip-host: Fix
> rockchip_pcie_host_init_port() PERST# handling"), a JMicron JMB585
> behind an rk3399 root port almost never becomes usable: the link trains
> normally, but the endpoint's configuration space never answers, so the
> device is not enumerated. On this controller a configuration read that
> gets no usable completion is reported as an external abort rather than
> as an all-ones response, which on arm64 brings the machine down.
> 
> The change added an unconditional 100 ms sleep so that PERST# stays
> asserted for at least Tpvperl after power becomes valid. The wait is
> performed while PERST# is asserted, so it also extends the reset by
> 100 ms, and this endpoint does not tolerate the longer assertion.
> 

This is hard to believe. First of all, Tpvperl is the min time specified by the
CEM spec to allow the power to be stable, not the max. Even if the bootloader
has already enabled the power supply during boot, it would've taken several
seconds for the kernel driver to probe and execute this delay of 100ms. But
claiming that the Endpoint doesn't tolerate this 100ms delay, but still several
seconds of the boot delay is quite hard to believe.

Maybe the issue is with the delay between PERST# assert and deassert? Is the
PERST# signal polarity on the board DTS correct? We used to see Endpoint
firmware crashes when the polarity was incorrect and the Endpoint got confused
with incorrect PERST# sequence.

> Tpvperl is counted from the supplies becoming valid (PCIe CEM r5.1,
> sec 2.9.2). On boards whose PCIe supplies are always-on -- vcc3v3_pcie
> on ROCK Pi 4 is regulator-always-on and regulator-boot-on -- power has
> been valid since boot, seconds before the driver probes, so the
> requirement is already met and the sleep only lengthens the reset.
> 

I do agree that the Tpvperl delay is *redundant* if the supplies are already
enabled by the bootloader. But I do not agree that it causes the Endpoint to not
respond.

- Mani




More information about the linux-arm-kernel mailing list