[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <30d9589a-8050-421b-a9a5-ad3422feadad@amd.com>
Date: Wed, 28 Aug 2024 16:24:01 -0500
From: Mario Limonciello <mario.limonciello@....com>
To: Bjorn Helgaas <helgaas@...nel.org>, linux-pci@...r.kernel.org
Cc: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
"Maciej W . Rozycki" <macro@...am.me.uk>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Lukas Wunner <lukas@...ner.de>,
"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
Duc Dang <ducdang@...gle.com>, Alex Williamson <alex.williamson@...hat.com>,
linux-kernel@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
"Li, Gary" <Gary.Li@....com>
Subject: Re: [RFC PATCH 0/3] PCI: Use Configuration RRS to wait for device
ready
On 8/27/2024 18:48, Bjorn Helgaas wrote:
> From: Bjorn Helgaas <bhelgaas@...gle.com>
>
> After a device reset, pci_dev_wait() waits for a device to become
> completely ready by polling the PCI_COMMAND register. The spec envisions
> that software would instead poll for the device to stop responding to
> config reads with Completions with Request Retry Status (RRS).
>
> Polling PCI_COMMAND leads to hardware retries that are invisible to
> software and the backoff between software retries doesn't work correctly.
>
> Root Ports are not required to support the Configuration RRS Software
> Visibility feature that prevents hardware retries and makes the RRS
> Completions visible to software, so this series only uses it when available
> and falls back to PCI_COMMAND polling when it's not.
>
> This is completely untested and posted for comments.
>
> Bjorn Helgaas (3):
> PCI: Wait for device readiness with Configuration RRS
> PCI: aardvark: Correct Configuration RRS checking
> PCI: Rename CRS Completion Status to RRS
>
> drivers/bcma/driver_pci_host.c | 10 ++--
> drivers/pci/controller/dwc/pcie-tegra194.c | 18 +++---
> drivers/pci/controller/pci-aardvark.c | 64 +++++++++++-----------
> drivers/pci/controller/pci-xgene.c | 6 +-
> drivers/pci/controller/pcie-iproc.c | 18 +++---
> drivers/pci/pci-bridge-emul.c | 4 +-
> drivers/pci/pci.c | 41 +++++++++-----
> drivers/pci/pci.h | 11 +++-
> drivers/pci/probe.c | 33 +++++------
> include/linux/bcma/bcma_driver_pci.h | 2 +-
> include/linux/pci.h | 1 +
> include/uapi/linux/pci_regs.h | 6 +-
> 12 files changed, 117 insertions(+), 97 deletions(-)
>
Although this looks like a useful series, I'm sorry to say but this
doesn't solve the issue that Gary and I raised. We double checked today
and found that reading the vendor ID works just fine at this time.
I think that we're still better off polling PCI_PM_CTRL to "wait" for D0
after the state change from D3cold.
Powered by blists - more mailing lists