linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stanislav Spassov <stanspas@amazon.com>
To: <linux-pci@vger.kernel.org>
Cc: "Stanislav Spassov" <stanspas@amazon.de>,
	linux-acpi@vger.kernel.org, "Bjorn Helgaas" <bhelgaas@google.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Jan H . Schönherr" <jschoenh@amazon.de>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Ashok Raj" <ashok.raj@intel.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Sinan Kaya" <okaya@kernel.org>,
	"Rajat Jain" <rajatja@google.com>,
	"kbuild test robot" <lkp@intel.com>
Subject: [PATCH v3 03/17] PCI: Use pci_bridge_wait_for_secondary_bus after SBR
Date: Tue, 3 Mar 2020 14:28:38 +0100	[thread overview]
Message-ID: <20200303132852.13184-4-stanspas@amazon.com> (raw)
In-Reply-To: <20200303132852.13184-1-stanspas@amazon.com>

From: Stanislav Spassov <stanspas@amazon.de>

So far, pci_bridge_wait_for_secondary_bus() was only invoked by PM code
after (runtime) resume of devices, but it naturally makes sense for
handling post-SBR waiting as well.

It uses the PCI_PM_D3COLD_WAIT value (100ms), potentially overridden on
a per-device basis to a lower-value, as the basis for determining
how long to wait, and handles special cases such as legacy PCI devices
(requiring Trhfa), and the different starting points for the waiting
time depending on PCIe port speed.

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.

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.

Signed-off-by: Stanislav Spassov <stanspas@amazon.de>
---
 drivers/pci/pci.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index ac8504d75c32..c1a866f733e9 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4800,14 +4800,7 @@ void pci_reset_secondary_bus(struct pci_dev *dev)
 	ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET;
 	pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);
 
-	/*
-	 * 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.
-	 */
-	ssleep(1);
+	pci_bridge_wait_for_secondary_bus(dev);
 }
 
 void __weak pcibios_reset_secondary_bus(struct pci_dev *dev)
-- 
2.25.1




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879




  parent reply	other threads:[~2020-03-03 13:30 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-03 13:28 [PATCH v3 00/17] Improve PCI device post-reset readiness polling Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 01/17] PCI: Fall back to slot/bus reset if softer methods timeout Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 02/17] PCI: Remove unused PCI_PM_BUS_WAIT Stanislav Spassov
2020-03-03 13:28 ` Stanislav Spassov [this message]
2020-03-03 13:28 ` [PATCH v3 04/17] PCI: Do not override delay for D0->D3hot transition Stanislav Spassov
2020-03-03 18:57   ` Rafael J. Wysocki
2020-03-07 10:58     ` Spassov, Stanislav
2020-03-03 13:28 ` [PATCH v3 05/17] PCI: Fix handling of _DSM 8 (avoiding reset delays) Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 06/17] PCI: Fix us->ms conversion in pci_acpi_optimize_delay Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 07/17] PCI: Clean up and document PM/reset delays Stanislav Spassov
2020-03-03 19:03   ` Rafael J. Wysocki
2020-03-07 11:30     ` Spassov, Stanislav
2020-03-03 13:28 ` [PATCH v3 08/17] PCI: Add more delay overrides to struct pci_dev Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 09/17] PCI: Generalize pci_bus_max_d3cold_delay to pci_bus_max_delay Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 10/17] PCI: Use correct delay in pci_bridge_wait_for_secondary_bus Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 11/17] PCI: Refactor pci_dev_wait to remove timeout parameter Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 12/17] PCI: Refactor pci_dev_wait to take pci_init_event Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 13/17] PCI: Cache CRS Software Visibiliy in struct pci_dev Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 14/17] PCI: Introduce per-device reset_ready_poll override Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 15/17] PCI: Refactor polling loop out of pci_dev_wait Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 16/17] PCI: Add CRS handling to pci_dev_wait() Stanislav Spassov
2020-03-05 17:56   ` Raj, Ashok
2020-03-06 18:07     ` Spassov, Stanislav
2020-03-03 13:28 ` [PATCH v3 17/17] PCI: Lower PCIE_RESET_READY_POLL_MS from 1m to 1s Stanislav Spassov

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=20200303132852.13184-4-stanspas@amazon.com \
    --to=stanspas@amazon.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=bhelgaas@google.com \
    --cc=corbet@lwn.net \
    --cc=jschoenh@amazon.de \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=okaya@kernel.org \
    --cc=rajatja@google.com \
    --cc=stanspas@amazon.de \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).