From: Sinan Kaya <okaya@codeaurora.org>
To: linux-pci@vger.kernel.org, timur@codeaurora.org,
alex.williamson@redhat.com
Cc: linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Sinan Kaya <okaya@codeaurora.org>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH V7 2/3] PCI: handle CRS returned by device after FLR
Date: Wed, 2 Aug 2017 15:15:16 -0400 [thread overview]
Message-ID: <1501701317-32249-2-git-send-email-okaya@codeaurora.org> (raw)
In-Reply-To: <1501701317-32249-1-git-send-email-okaya@codeaurora.org>
An endpoint is allowed to issue Configuration Request Retry Status (CRS)
following a Function Level Reset (FLR) request to indicate that it is
not ready to accept new requests. CRS is defined in PCIe r3.1, sec 2.3.1.
Request Handling Rules and CRS usage in FLR context is mentioned in
PCIe r3.1, sec 6.6.2. Function-Level Reset.
Adding a vendor ID read if this is a physical function before attempting
to read any other registers on the endpoint. A CRS indication will only
be given if the address to be read is vendor ID register.
pci_bus_read_dev_vendor_id() knows how to deal with CRS returned values.
Calling pci_bus_read_dev_vendor_id() with 60 seconds timeout to be
consistent with the rest of the kernel CRS timeout policy.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/pci/pci.c | 27 +++++++++++----------------
1 file changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 2ed604a..ad49e73 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3813,30 +3813,25 @@ int pci_wait_for_pending_transaction(struct pci_dev *dev)
/*
* We should only need to wait 100ms after FLR for virtual functions.
- * Wait for up to 1000ms for config space to return something other than -1.
- * Intel IGD requires this when an LCD panel is attached. We read the 2nd
- * dword because VFs don't implement the 1st dword.
+ * Wait for up to 60s for config space to return something other than -1.
+ * Intel IGD requires 300ms when an LCD panel is attached. We use
+ * pci_bus_read_dev_vendor_id() for reading the vendor ID as it handles
+ * CRS gracefully.
*/
static void pci_flr_wait(struct pci_dev *dev)
{
- int i = 0;
u32 id;
+ bool ret;
- if (dev->is_virtfn) {
- msleep(100);
- return;
- }
+ /* don't touch the HW before waiting 100ms */
+ msleep(100);
- do {
- msleep(100);
- pci_read_config_dword(dev, PCI_COMMAND, &id);
- } while (i++ < 10 && id == ~0);
+ if (dev->is_virtfn)
+ return;
- if (id == ~0)
+ ret = pci_bus_read_dev_vendor_id(dev->bus, dev->devfn, &id, 60000);
+ if (!ret)
dev_warn(&dev->dev, "Failed to return from FLR\n");
- else if (i > 1)
- dev_info(&dev->dev, "Required additional %dms to return from FLR\n",
- (i - 1) * 100);
}
/**
--
1.9.1
next prev parent reply other threads:[~2017-08-02 19:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-02 19:15 [PATCH V7 1/3] PCI: limit FLR wait time to 100ms maximum Sinan Kaya
2017-08-02 19:15 ` Sinan Kaya [this message]
2017-08-02 19:15 ` [PATCH V7 3/3] PCI: display not responding message while device is unreachable Sinan Kaya
2017-08-02 20:27 ` [PATCH V7 1/3] PCI: limit FLR wait time to 100ms maximum Bjorn Helgaas
2017-08-02 20:32 ` Sinan Kaya
2017-08-02 21:22 ` Sinan Kaya
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=1501701317-32249-2-git-send-email-okaya@codeaurora.org \
--to=okaya@codeaurora.org \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=timur@codeaurora.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;
as well as URLs for NNTP newsgroup(s).