[PATCH 1/1][resend] check for pci bar restore completion and retry

[PATCH 1/1][resend] check for pci bar restore completion and retry

[Allen Kay]

On some OEM systems, pci_restore_state() is called while FLR has not yet
completed.  As a result, PCI BAR register restore is not successful.  This fix
reads back the restored value and compares it with saved value and re-tries 10
times before giving up.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
Signed-off-by: Eric Chanudet <eric.chanudet@citrix.com>
Signed-off-by: Allen Kay <allen.m.kay@intel.com>
---
 drivers/pci/pci.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index af295bb..0549050 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -959,6 +959,7 @@ void pci_restore_state(struct pci_dev *dev)
 {
 	int i;
 	u32 val;
+	int tries;
 
 	if (!dev->state_saved)
 		return;
@@ -973,12 +974,16 @@ void pci_restore_state(struct pci_dev *dev)
 	 */
 	for (i = 15; i >= 0; i--) {
 		pci_read_config_dword(dev, i * 4, &val);
-		if (val != dev->saved_config_space[i]) {
+		tries = 10;		
+		while (tries && val != dev->saved_config_space[i]) {
 			dev_dbg(&dev->dev, "restoring config "
 				"space at offset %#x (was %#x, writing %#x)\n",
 				i, val, (int)dev->saved_config_space[i]);
 			pci_write_config_dword(dev,i * 4,
 				dev->saved_config_space[i]);
+			pci_read_config_dword(dev, i * 4, &val);
+			mdelay(10);
+			tries--;
 		}
 	}
 	pci_restore_pcix_state(dev);
-- 
1.6.0.6

Re: [PATCH 1/1][resend] check for pci bar restore completion and retry

[Jesse Barnes]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

On Thu, 26 Jan 2012 10:25:53 -0800
"Kay, Allen M" <allen.m.kay@intel.com> wrote:

> On some OEM systems, pci_restore_state() is called while FLR has not yet
> completed.  As a result, PCI BAR register restore is not successful.  This fix
> reads back the restored value and compares it with saved value and re-tries 10
> times before giving up.

Applied, but I don't think I got an answer as to why we don't do this
delay/check when we perform the FLR in the first place?

-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: [PATCH 1/1][resend] check for pci bar restore completion and retry

[Kay, Allen M]

Sorry Jesse, I did not see this until now.  There is some problem with my email I was not aware of - many emails did not go into my inbox.

Given there are many reset methods, checking for actual BAR restore is more reliable and less testing for a various reset methods.  We can potentially add checks for completion in pcie_flr() since that's easy to do.

Eric/Jean, do you have other comments? 

Allen

-----Original Message-----
From: Jesse Barnes [mailto:jbarnes@virtuousgeek.org] 
Sent: Friday, January 27, 2012 11:44 AM
To: Kay, Allen M
Cc: linux-pci-owner@vger.kernel.org; Barnes, Jesse; Wilcox, Matthew R; linux-kernel@vger.kernel.org; jean.guyader@eu.citrix.com; eric.chanudet@citrix.com
Subject: Re: [PATCH 1/1][resend] check for pci bar restore completion and retry

On Thu, 26 Jan 2012 10:25:53 -0800
"Kay, Allen M" <allen.m.kay@intel.com> wrote:

> On some OEM systems, pci_restore_state() is called while FLR has not 
> yet completed.  As a result, PCI BAR register restore is not 
> successful.  This fix reads back the restored value and compares it 
> with saved value and re-tries 10 times before giving up.

Applied, but I don't think I got an answer as to why we don't do this delay/check when we perform the FLR in the first place?

--
Jesse Barnes, Intel Open Source Technology Center