All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amey Narkhede <ameynarkhede03@gmail.com>
To: "Pali Rohár" <pali@kernel.org>
Cc: alex.williamson@redhat.com, helgaas@kernel.org,
	lorenzo.pieralisi@arm.com, kabel@kernel.org,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	raphael.norwitz@nutanix.com
Subject: Re: How long should be PCIe card in Warm Reset state?
Date: Tue, 23 Mar 2021 21:49:41 +0530	[thread overview]
Message-ID: <20210323161941.gim6msj3ruu3flnf@archlinux> (raw)
In-Reply-To: <20210310110535.zh4pnn4vpmvzwl5q@pali>

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

  reply	other threads:[~2021-03-23 16:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10 11:05 How long should be PCIe card in Warm Reset state? Pali Rohár
2021-03-23 16:19 ` Amey Narkhede [this message]
2021-03-23 16:27   ` Pali Rohár
2021-03-23 16:57     ` Amey Narkhede
2021-03-25  9:18       ` David Laight
2021-03-30 13:04         ` Maciej W. Rozycki
2021-03-30 13:10           ` Pali Rohár
2021-03-30 14:34             ` Maciej W. Rozycki
2021-03-30 15:04               ` Pali Rohár
2021-03-30 15:22                 ` Maciej W. Rozycki
2021-04-25 15:39           ` Pali Rohár

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=20210323161941.gim6msj3ruu3flnf@archlinux \
    --to=ameynarkhede03@gmail.com \
    --cc=alex.williamson@redhat.com \
    --cc=helgaas@kernel.org \
    --cc=kabel@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=pali@kernel.org \
    --cc=raphael.norwitz@nutanix.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.