From: Lukas Wunner <lukas@wunner.de>
To: Yang Su <yang.su@linux.alibaba.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
linux-pci@vger.kernel.org, Keith Busch <kbusch@kernel.org>,
Ashok Raj <ashok.raj@intel.com>,
Sathyanarayanan Kuppuswamy
<sathyanarayanan.kuppuswamy@linux.intel.com>,
Ravi Kishore Koppuravuri <ravi.kishore.koppuravuri@intel.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Sheng Bi <windy.bi.enflame@gmail.com>,
Stanislav Spassov <stanspas@amazon.de>,
shuo.tan@linux.alibaba.com
Subject: Re: [PATCH v2 3/3] PCI/DPC: Await readiness of secondary bus after reset
Date: Sun, 19 Feb 2023 06:12:54 +0100 [thread overview]
Message-ID: <20230219051254.GB12326@wunner.de> (raw)
In-Reply-To: <5d5ee171-18e5-f1b8-d08a-0d88f8eb3a3f@linux.alibaba.com>
On Sat, Feb 18, 2023 at 09:23:47PM +0800, Yang Su wrote:
> I do not understand why pci_bridge_wait_for_secondary_bus() can fix
> Intel's Ponte Vecchio HPC GPU after a DPC-induced Hot Reset.
>
> The func pci_bridge_wait_for_secondary_bus() also use
> pcie_wait_for_link_delay() which time depends on the max device delay
> time of one bus, for the GPU which bus only one device, I think the
> time is 100ms as the input parater in pcie_wait_for_link_delay().
>
> pcie_wait_for_link() also wait fixed 100ms and then wait the device data
> link is ready. So another wait time is pci_dev_wait() in your patch?
> pci_dev_wait() to receive the CRS from the device to check the device
> whether is ready.
>
> Please help me understand which difference work.
The crucial difference is the invocation of pci_dev_wait(), which waits
up to 60 seconds for the device to come out of reset.
The spec allows 1 second but that may be extended via CRS. Ponte Vecchio
has been witnessed to take more than 4 seconds in some cases, hence the
need to wait longer than 1 second.
Thanks,
Lukas
next prev parent reply other threads:[~2023-02-19 5:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-15 8:20 [PATCH v2 0/3] PCI reset delay fixes Lukas Wunner
2023-01-15 8:20 ` [PATCH v2 1/3] PCI/PM: Observe reset delay irrespective of bridge_d3 Lukas Wunner
2023-02-18 13:22 ` Yang Su
2023-02-19 5:07 ` Lukas Wunner
2023-01-15 8:20 ` [PATCH v2 2/3] PCI: Unify delay handling for reset and resume Lukas Wunner
2023-02-23 11:01 ` Yang Su
2023-03-01 6:31 ` Lukas Wunner
2023-01-15 8:20 ` [PATCH v2 3/3] PCI/DPC: Await readiness of secondary bus after reset Lukas Wunner
2023-02-18 13:23 ` Yang Su
2023-02-19 5:12 ` Lukas Wunner [this message]
2023-02-07 19:03 ` [PATCH v2 0/3] PCI reset delay fixes Bjorn Helgaas
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=20230219051254.GB12326@wunner.de \
--to=lukas@wunner.de \
--cc=ashok.raj@intel.com \
--cc=helgaas@kernel.org \
--cc=kbusch@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=ravi.kishore.koppuravuri@intel.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=shuo.tan@linux.alibaba.com \
--cc=stanspas@amazon.de \
--cc=windy.bi.enflame@gmail.com \
--cc=yang.su@linux.alibaba.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.