Re: How long should be PCIe card in Warm Reset state?

[Amey Narkhede <ameynarkhede03@gmail.com>]

On 21/03/23 05:27PM, Pali Rohár wrote:
> On Tuesday 23 March 2021 21:49:41 Amey Narkhede wrote:
> > On 21/03/10 12:05PM, Pali Rohár wrote:
> > > Hello!
> > >
> > > I would like to open a question about PCIe Warm Reset. Warm Reset of
> > > PCIe card is triggered by asserting PERST# signal and in most cases
> > > PERST# signal is controlled by GPIO.
> > >
> > > Basically every native Linux PCIe controller driver is doing this Warm
> > > Reset of connected PCIe card during native driver initialization
> > > procedure.
> > >
> > > And now the important question is: How long should be PCIe card in Warm
> > > Reset state? After which timeout can be PERST# signal de-asserted by
> > > Linux controller driver?
> > >
> > > Lorenzo and Rob already expressed concerns [1] [2] that this Warm Reset
> > > timeout should not be driver specific and I agree with them.
> > >
> > > I have done investigation which timeout is using which native PCIe
> > > driver [3] and basically every driver is using different timeout.
> > >
> > > I have tried to find timeouts in PCIe specifications, I was not able to
> > > understand and deduce correct timeout value for Warm Reset from PCIe
> > > specifications. What I have found is written in my email [4].
> > >
> > > Alex (as a "reset expert"), could you look at this issue?
> > >
> > > Or is there somebody else who understand PCIe specifications and PCIe
> > > diagrams to figure out what is the minimal timeout for de-asserting
> > > PERST# signal?
> > >
> > > There are still some issues with WiFi cards (e.g. Compex one) which
> > > sometimes do not appear on PCIe bus. And based on these "reset timeout
> > > differences" in Linux PCIe controller drivers, I suspect that it is not
> > > (only) the problems in WiFi cards but also in Linux PCIe controller
> > > drivers. In my email [3] I have written that I figured out that WLE1216
> > > card needs to be in Warm Reset state for at least 10ms, otherwise card
> > > is not detected.
> > >
> > > [1] - https://lore.kernel.org/linux-pci/20200513115940.fiemtnxfqcyqo6ik@pali/
> > > [2] - https://lore.kernel.org/linux-pci/20200507212002.GA32182@bogus/
> > > [3] - https://lore.kernel.org/linux-pci/20200424092546.25p3hdtkehohe3xw@pali/
> > > [4] - https://lore.kernel.org/linux-pci/20200430082245.xblvb7xeamm4e336@pali/
> >
> > I somehow got my hands on PCIe Gen4 spec. It says on page no 555-
> > "When PERST# is provided to a component or adapter, this signal must be
> > used by the component or adapter as Fundamental Reset.
> > When PERST# is not provided to a component or adapter, Fundamental Reset is
> > generated autonomously by the component or adapter, and the details of how
> > this is done are outside the scope of this document."
> > Not sure what component/adapter means in this context.
> >
> > Then below it says-
> > "In some cases, it may be possible for the Fundamental Reset mechanism
> > to be triggered  by hardware without the removal and re-application of
> > power to the component.  This is called a warm reset. This document does
> > not specify a means for generating a warm reset."
> >
> > Thanks,
> > Amey
>
> Hello Amey, PCIe Base document does not specify how to control PERST#
> signal and how to issue Warm Reset. But it is documented in PCIe CEM,
> Mini PCIe CEM and M.2 CEM documents (maybe in some other PCIe docs too).
>
> It is needed look into more documents, "merge them in head" and then
> deduce final meaning...
Okay so PCIe CEM revision 2.0(from 2007) on page no 22 says-
"On power up, the deassertion of PERST# is delayed 100 ms (TPVPERL)
from the power rails achieving specified operating limits.  Also, within
this time, the reference clocks  (REFCLK+, REFCLK-) also become stable,
at least TPERST-CLK before PERST# is deasserted."

Then below it says-
"After there has been time (TPVPERL) for the power and clock to become
stable, PERST# is deasserted high and the PCI Express functions can start
up."

And then there is table of timing on page no 33-
Symbol 		Parameter 				Min
TPVPERL 	Power Stable to PERST# inactive 	100ms
TPERST-CLK 	REFCLK stable before PERST# inactive 	100μs
TPERST 		PERST# active time 			100μs
TFAIL 		Power level invalid to PERST# active 	500ns
...

I agree this is confusing.

Thanks,
Amey