From: Yang Su <yang.su@linux.alibaba.com>
To: bhelgaas@google.com
Cc: alex.williamson@redhat.com, matthew@wil.cx,
jbarnes@virtuousgeek.org, rjw@sisk.pl, greg@kroah.com,
patchwork-bot@kernel.org, andrew.murray@arm.com,
lorenzo.pieralisi@arm.com, robh@kernel.org, kw@linux.com,
linux-kernel@vger.kernel.org
Subject: [tune sbr time 1/1] PCI: Tune secondary bus reset time for PCIe
Date: Sun, 1 Jan 2023 17:14:57 +0800 [thread overview]
Message-ID: <03c5388700f8b0db95ede6084eaa6e59b84a23bf.1672563632.git.yang.su@linux.alibaba.com> (raw)
In-Reply-To: <cover.1672563632.git.yang.su@linux.alibaba.com>
On PCI Express, there will be cases where the new code sleeps far less
than the 1s being replaced by this patch. This should be okay, because
PCI Express Base Specification Revision 5.0 Version 1.0 (May 22, 2019)
in Section 6.6.1 "Conventional Reset" only notes 100ms as the minimum
waiting time. After this time, the OS is permitted to issue
Configuration Requests, but it is possible that the device responds
with Configuration Request Retry Status (CRS) Completions, rather than
Successful Completion. Returning CRS can go on for up to 1 second after
a Conventional Reset (such as SBR) before the OS can consider the device
broken. This additional wait is handled by pci_dev_wait. Besides,
this patch also cover PCI and PCI-X after device reset waiting Tpvrh 1000ms.
Currently, the only callchain that lands in the function modified by
this patch which invokes one out of two versions of pcibios_reset_secondary_bus
that both end with a call to pci_reset_secondary_bus.
Afterwards, pci_reset_secondary_bus always invokes pci_dev_wait
which wait for the device to return a non-CRS completion.
Signed-off-by: Yang Su <yang.su@linux.alibaba.com>
---
drivers/pci/pci.c | 36 +++++++++++++++++++++++++++++++++---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index fba95486caaf..8e4899755718 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5063,10 +5063,40 @@ void pci_reset_secondary_bus(struct pci_dev *dev)
* Trhfa for conventional PCI is 2^25 clock cycles.
* Assuming a minimum 33MHz clock this results in a 1s
* delay before we can consider subordinate devices to
- * be re-initialized. PCIe has some ways to shorten this,
- * but we don't make use of them yet.
+ * be re-initialized.
+ *
+ * For conventional PCI needing 1s delay after bus reset.
+ * Using pci_is_pcie to judge the bus is pci or pcie.
+ * If the bus is pci, sleeping 1s to wait device is ready.
+ *
+ * And if the bus is pcie, PCI Express Base Specification Revision 2.0
+ * (December 20, 2006) in Section 6.6.1 "Conventional Reset" only notes
+ * 100ms as the minimum waiting time, the same as the newer PCIe spec
+ * PCI Express Base Specification Revision 3.0 Version 1.a (December 7, 2015)
+ * and PCI Express Base Specification Revision 5.0 Version 1.0 (May 22, 2019).
+ * With a Downstream Port that supports Link speeds greater than 5.0 GT/s,
+ * software must wait a minimum of 100 ms after Link training completes before
+ * sending a Configuration Request to the device immediately below that Port.
+ * After this time, the OS is permitted to issue Configuration Requests,
+ * but it is possible that the device responds with Configuration Request
+ * Retry Status (CRS) Completions, rather than Successful Completion.
+ * Returning CRS can go on for up to 1 second after a Conventional Reset
+ * (such as SBR) before the OS can consider the device. This additional
+ * wait is handled by pci_dev_wait.
+ *
+ * Currently, the only callchain that lands in the function modified by
+ * this patch starts at pci_bridge_secondary_bus_reset which invokes
+ * one out of two versions of pcibios_reset_secondary_bus that both end
+ * with a call to pci_reset_secondary_bus.
+ * Afterwards, pci_bridge_secondary_bus_reset always invokes pci_dev_wait.
*/
- ssleep(1);
+ if (pci_is_pcie(dev))
+ if (pcie_get_speed_cap(dev) <= PCIE_SPEED_5_0GT)
+ msleep(100);
+ else
+ pcie_wait_for_link(dev, true);
+ else
+ ssleep(1);
}
void __weak pcibios_reset_secondary_bus(struct pci_dev *dev)
--
2.19.1.6.gb485710b
WARNING: multiple messages have this Message-ID
From: Yang Su <yang.su@linux.alibaba.com>
To: bhelgaas@google.com
Cc: linux-pci@vger.kernel.org, alex.williamson@redhat.com,
matthew@wil.cx, jbarnes@virtuousgeek.org, rjw@sisk.pl,
greg@kroah.com, patchwork-bot@kernel.org, andrew.murray@arm.com,
lorenzo.pieralisi@arm.com, robh@kernel.org, kw@linux.com,
linux-kernel@vger.kernel.org
Subject: [PATCH 1/1] PCI: Tune secondary bus reset time for PCIe
Date: Sun, 1 Jan 2023 17:22:33 +0800 [thread overview]
Message-ID: <03c5388700f8b0db95ede6084eaa6e59b84a23bf.1672563632.git.yang.su@linux.alibaba.com> (raw)
Message-ID: <20230101092233.vztb_lr0suMH4WASooIbGmfszl_HFnozGSIcu3ycowA@z> (raw)
In-Reply-To: <cover.1672563632.git.yang.su@linux.alibaba.com>
On PCI Express, there will be cases where the new code sleeps far less
than the 1s being replaced by this patch. This should be okay, because
PCI Express Base Specification Revision 5.0 Version 1.0 (May 22, 2019)
in Section 6.6.1 "Conventional Reset" only notes 100ms as the minimum
waiting time. After this time, the OS is permitted to issue
Configuration Requests, but it is possible that the device responds
with Configuration Request Retry Status (CRS) Completions, rather than
Successful Completion. Returning CRS can go on for up to 1 second after
a Conventional Reset (such as SBR) before the OS can consider the device
broken. This additional wait is handled by pci_dev_wait. Besides,
this patch also cover PCI and PCI-X after device reset waiting Tpvrh 1000ms.
Currently, the only callchain that lands in the function modified by
this patch which invokes one out of two versions of pcibios_reset_secondary_bus
that both end with a call to pci_reset_secondary_bus.
Afterwards, pci_reset_secondary_bus always invokes pci_dev_wait
which wait for the device to return a non-CRS completion.
Signed-off-by: Yang Su <yang.su@linux.alibaba.com>
---
drivers/pci/pci.c | 36 +++++++++++++++++++++++++++++++++---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index fba95486caaf..8e4899755718 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5063,10 +5063,40 @@ void pci_reset_secondary_bus(struct pci_dev *dev)
* Trhfa for conventional PCI is 2^25 clock cycles.
* Assuming a minimum 33MHz clock this results in a 1s
* delay before we can consider subordinate devices to
- * be re-initialized. PCIe has some ways to shorten this,
- * but we don't make use of them yet.
+ * be re-initialized.
+ *
+ * For conventional PCI needing 1s delay after bus reset.
+ * Using pci_is_pcie to judge the bus is pci or pcie.
+ * If the bus is pci, sleeping 1s to wait device is ready.
+ *
+ * And if the bus is pcie, PCI Express Base Specification Revision 2.0
+ * (December 20, 2006) in Section 6.6.1 "Conventional Reset" only notes
+ * 100ms as the minimum waiting time, the same as the newer PCIe spec
+ * PCI Express Base Specification Revision 3.0 Version 1.a (December 7, 2015)
+ * and PCI Express Base Specification Revision 5.0 Version 1.0 (May 22, 2019).
+ * With a Downstream Port that supports Link speeds greater than 5.0 GT/s,
+ * software must wait a minimum of 100 ms after Link training completes before
+ * sending a Configuration Request to the device immediately below that Port.
+ * After this time, the OS is permitted to issue Configuration Requests,
+ * but it is possible that the device responds with Configuration Request
+ * Retry Status (CRS) Completions, rather than Successful Completion.
+ * Returning CRS can go on for up to 1 second after a Conventional Reset
+ * (such as SBR) before the OS can consider the device. This additional
+ * wait is handled by pci_dev_wait.
+ *
+ * Currently, the only callchain that lands in the function modified by
+ * this patch starts at pci_bridge_secondary_bus_reset which invokes
+ * one out of two versions of pcibios_reset_secondary_bus that both end
+ * with a call to pci_reset_secondary_bus.
+ * Afterwards, pci_bridge_secondary_bus_reset always invokes pci_dev_wait.
*/
- ssleep(1);
+ if (pci_is_pcie(dev))
+ if (pcie_get_speed_cap(dev) <= PCIE_SPEED_5_0GT)
+ msleep(100);
+ else
+ pcie_wait_for_link(dev, true);
+ else
+ ssleep(1);
}
void __weak pcibios_reset_secondary_bus(struct pci_dev *dev)
--
2.19.1.6.gb485710b
next prev parent reply other threads:[~2023-01-01 9:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-01 9:14 [tune sbr time 0/1] Tune pci sbr time Yang Su
2023-01-01 9:14 ` Yang Su [this message]
2023-01-01 9:22 ` [PATCH 1/1] PCI: Tune secondary bus reset time for PCIe Yang Su
2023-01-12 22:48 ` Bjorn Helgaas
2023-01-13 3:58 ` Yang Su
2023-02-14 22:20 ` Bjorn Helgaas
2023-01-01 9:22 ` [PATCH 0/1] Tune pci sbr time Yang Su
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=03c5388700f8b0db95ede6084eaa6e59b84a23bf.1672563632.git.yang.su@linux.alibaba.com \
--to=yang.su@linux.alibaba.com \
--cc=alex.williamson@redhat.com \
--cc=andrew.murray@arm.com \
--cc=bhelgaas@google.com \
--cc=greg@kroah.com \
--cc=jbarnes@virtuousgeek.org \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=matthew@wil.cx \
--cc=patchwork-bot@kernel.org \
--cc=rjw@sisk.pl \
--cc=robh@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®