summaryrefslogtreecommitdiff
path: root/drivers/pci/proc.c
diff options
context:
space:
mode:
authorBjorn Helgaas <bhelgaas@google.com>2016-02-22 23:58:18 +0300
committerBjorn Helgaas <bhelgaas@google.com>2016-03-10 23:24:48 +0300
commitc521b014cd51da94ae16c3decf1c407c3e0518f6 (patch)
tree0671f6526a14de5aeb6991256b85f1cc1a001062 /drivers/pci/proc.c
parent408641e93aa5283e586fefd4dc72e67c92aae075 (diff)
downloadlinux-c521b014cd51da94ae16c3decf1c407c3e0518f6.tar.xz
PCI: Sleep rather than busy-wait for VPD access completion
Use usleep_range() instead of udelay() while waiting for a VPD access to complete. This is not a performance path, so no need to hog the CPU. Rationale for usleep_range() parameters: We clear PCI_VPD_ADDR_F for a read (or set it for a write), then wait for the device to change it. For a device that updates PCI_VPD_ADDR between our config write and subsequent config read, we won't sleep at all and can get the device's maximum rate. Sleeping a minimum of 10 usec per 4-byte access limits throughput to about 400Kbytes/second. VPD is small (32K bytes at most), and most devices use only a fraction of that. We back off exponentially up to 1024 usec per iteration. If we reach 1024, we've already waited up to 1008 usec (16 + 32 + ... + 512), so if we miss an update and wait an extra 1024 usec, we can still get about 1/2 of the device's maximum rate. Tested-by: Shane Seymour <shane.seymour@hpe.com> Tested-by: Babu Moger <babu.moger@oracle.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hannes Reinecke <hare@suse.com>
Diffstat (limited to 'drivers/pci/proc.c')
0 files changed, 0 insertions, 0 deletions