From 42eca2302146fed51335b95128e949ee6f54478f Mon Sep 17 00:00:00 2001 From: Dave Airlie Date: Mon, 29 Oct 2012 17:26:54 -0600 Subject: PCI: Don't touch card regs after runtime suspend D3 If the driver takes care of state saving, don't touch any registers on it. Optimus (dual-gpu) laptops seem to have their own form of D3cold, but unfortunately enter it on normal D3 transitions via the ACPI callback. So when we use runtime PM to transition to D3, the card disappears off the PCI bus, however we then try to access registers on it in the runtime suspend finish, which really doesn't work. This patch checks whether the pci state is saved and doesn't attempt to hit any registers after that point if it is. (Looks okay to Rafael) Signed-off-by: Dave Airlie Signed-off-by: Bjorn Helgaas --- drivers/pci/pci-driver.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index 94c6e2aa03d6..11d9c8a9d0d0 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -1023,10 +1023,10 @@ static int pci_pm_runtime_suspend(struct device *dev) return 0; } - if (!pci_dev->state_saved) + if (!pci_dev->state_saved) { pci_save_state(pci_dev); - - pci_finish_runtime_suspend(pci_dev); + pci_finish_runtime_suspend(pci_dev); + } return 0; } -- cgit From 1f09b09b4de0e120800e49d806d264e7446ed446 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Mon, 29 Oct 2012 17:26:54 -0600 Subject: x86/PCI: Ignore _SEG on HP xw9300 The xw9300 BIOS supplies _SEG methods that are incorrect, which results in some LSI SCSI devices not being discovered. This adds a quirk to ignore _SEG on this machine and default to zero. The xw9300 has three host bridges: ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3f]) ACPI: PCI Root Bridge [PCI1] (domain 0001 [bus 40-7f]) ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 80-ff]) When the BIOS "ACPI Bus Segmentation" option is enabled (as it is by default), the _SEG methods of the PCI1 and PCI2 bridges return 1 and 2, respectively. However, the BIOS implementation appears to be incomplete, and we can't enumerate devices in those domains. But if we assume PCI1 and PCI2 really lead to buses in domain 0, everything works fine. Windows XP and Vista also seem to ignore these _SEG methods. Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543308 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=15362 Reported-and-Tested-by: Sean M. Pappalardo Signed-off-by: Bjorn Helgaas --- arch/x86/pci/acpi.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c index 192397c98606..49e5195223db 100644 --- a/arch/x86/pci/acpi.c +++ b/arch/x86/pci/acpi.c @@ -22,6 +22,7 @@ struct pci_root_info { }; static bool pci_use_crs = true; +static bool pci_ignore_seg = false; static int __init set_use_crs(const struct dmi_system_id *id) { @@ -35,7 +36,14 @@ static int __init set_nouse_crs(const struct dmi_system_id *id) return 0; } -static const struct dmi_system_id pci_use_crs_table[] __initconst = { +static int __init set_ignore_seg(const struct dmi_system_id *id) +{ + printk(KERN_INFO "PCI: %s detected: ignoring ACPI _SEG\n", id->ident); + pci_ignore_seg = true; + return 0; +} + +static const struct dmi_system_id pci_crs_quirks[] __initconst = { /* http://bugzilla.kernel.org/show_bug.cgi?id=14183 */ { .callback = set_use_crs, @@ -98,6 +106,16 @@ static const struct dmi_system_id pci_use_crs_table[] __initconst = { DMI_MATCH(DMI_BIOS_VERSION, "6JET85WW (1.43 )"), }, }, + + /* https://bugzilla.kernel.org/show_bug.cgi?id=15362 */ + { + .callback = set_ignore_seg, + .ident = "HP xw9300", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"), + DMI_MATCH(DMI_PRODUCT_NAME, "HP xw9300 Workstation"), + }, + }, {} }; @@ -108,7 +126,7 @@ void __init pci_acpi_crs_quirks(void) if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) && year < 2008) pci_use_crs = false; - dmi_check_system(pci_use_crs_table); + dmi_check_system(pci_crs_quirks); /* * If the user specifies "pci=use_crs" or "pci=nocrs" explicitly, that @@ -455,6 +473,9 @@ struct pci_bus * __devinit pci_acpi_scan_root(struct acpi_pci_root *root) int pxm; #endif + if (pci_ignore_seg) + domain = 0; + if (domain && !pci_domains_supported) { printk(KERN_WARNING "pci_bus %04x:%02x: " "ignored (multiple domains not supported)\n", -- cgit From 438be3c6b76fa129731a320ec7f0bb3d530bcb50 Mon Sep 17 00:00:00 2001 From: Joe Perches Date: Sun, 28 Oct 2012 01:05:49 -0700 Subject: PCI: Convert dev_printk(KERN_ to dev_( dev_ calls take less code than dev_printk(KERN_ and reducing object size is good. Coalesce formats for easier grep. Signed-off-by: Joe Perches Signed-off-by: Bjorn Helgaas --- drivers/pci/irq.c | 10 +++++----- drivers/pci/pci-stub.c | 2 +- drivers/pci/pcie/aspm.c | 7 ++----- 3 files changed, 8 insertions(+), 11 deletions(-) diff --git a/drivers/pci/irq.c b/drivers/pci/irq.c index e5f69a43b1b1..b008cf86b9c3 100644 --- a/drivers/pci/irq.c +++ b/drivers/pci/irq.c @@ -14,11 +14,11 @@ static void pci_note_irq_problem(struct pci_dev *pdev, const char *reason) { struct pci_dev *parent = to_pci_dev(pdev->dev.parent); - dev_printk(KERN_ERR, &pdev->dev, - "Potentially misrouted IRQ (Bridge %s %04x:%04x)\n", - dev_name(&parent->dev), parent->vendor, parent->device); - dev_printk(KERN_ERR, &pdev->dev, "%s\n", reason); - dev_printk(KERN_ERR, &pdev->dev, "Please report to linux-kernel@vger.kernel.org\n"); + dev_err(&pdev->dev, + "Potentially misrouted IRQ (Bridge %s %04x:%04x)\n", + dev_name(&parent->dev), parent->vendor, parent->device); + dev_err(&pdev->dev, "%s\n", reason); + dev_err(&pdev->dev, "Please report to linux-kernel@vger.kernel.org\n"); WARN_ON(1); } diff --git a/drivers/pci/pci-stub.c b/drivers/pci/pci-stub.c index 775e933c2225..6e47c519c510 100644 --- a/drivers/pci/pci-stub.c +++ b/drivers/pci/pci-stub.c @@ -28,7 +28,7 @@ MODULE_PARM_DESC(ids, "Initial PCI IDs to add to the stub driver, format is " static int pci_stub_probe(struct pci_dev *dev, const struct pci_device_id *id) { - dev_printk(KERN_INFO, &dev->dev, "claimed by stub\n"); + dev_info(&dev->dev, "claimed by stub\n"); return 0; } diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c index 213753b283a6..3da9ecc9ab84 100644 --- a/drivers/pci/pcie/aspm.c +++ b/drivers/pci/pcie/aspm.c @@ -242,8 +242,7 @@ static void pcie_aspm_configure_common_clock(struct pcie_link_state *link) return; /* Training failed. Restore common clock configurations */ - dev_printk(KERN_ERR, &parent->dev, - "ASPM: Could not configure common clock\n"); + dev_err(&parent->dev, "ASPM: Could not configure common clock\n"); list_for_each_entry(child, &linkbus->devices, bus_list) pcie_capability_write_word(child, PCI_EXP_LNKCTL, child_reg[PCI_FUNC(child->devfn)]); @@ -507,9 +506,7 @@ static int pcie_aspm_sanity_check(struct pci_dev *pdev) */ pcie_capability_read_dword(child, PCI_EXP_DEVCAP, ®32); if (!(reg32 & PCI_EXP_DEVCAP_RBER) && !aspm_force) { - dev_printk(KERN_INFO, &child->dev, "disabling ASPM" - " on pre-1.1 PCIe device. You can enable it" - " with 'pcie_aspm=force'\n"); + dev_info(&child->dev, "disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'\n"); return -EINVAL; } } -- cgit From 21c5fd97380ba22c2a616b482307b2ef94429f31 Mon Sep 17 00:00:00 2001 From: Ian Abbott Date: Tue, 30 Oct 2012 17:25:53 +0000 Subject: PCI: Add workaround for PLX PCI 9050 BAR alignment erratum The PLX PCI 9050 PCI Target bridge controller has a bug that prevents its local configuration registers being read through BAR0 (memory) or BAR1 (i/o) if the base address lies on an odd 128-byte boundary, i.e. if bit 7 of the base address is non-zero. This bug is described in the PCI 9050 errata list, version 1.4, May 2005. It was fixed in the pin-compatible PCI 9052, which can be distinguished from the PCI 9050 by checking the revision in the PCI header, which is hard-coded for these chips. Workaround the problem by re-allocating the affected regions to a 256-byte boundary. Note that BAR0 and/or BAR1 may have been disabled (size 0) during initialization of the PCI chip when its configuration is read from a serial EEPROM. Currently, the fix-up has only been used for devices with the default vendor and device ID of the PLX PCI 9050. The PCI 9052 shares the same default device ID as the PCI 9050 but they have different PCI revision codes. Signed-off-by: Ian Abbott Signed-off-by: Bjorn Helgaas --- drivers/pci/quirks.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 7a451ff56ecc..2d0d1c229c68 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1790,6 +1790,34 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TOSHIBA_2, PCI_DEVICE_ID_TOSHIBA_TC86C001_IDE, quirk_tc86c001_ide); +/* + * PLX PCI 9050 PCI Target bridge controller has an errata that prevents the + * local configuration registers accessible via BAR0 (memory) or BAR1 (i/o) + * being read correctly if bit 7 of the base address is set. + * The BAR0 or BAR1 region may be disabled (size 0) or enabled (size 128). + * Re-allocate the regions to a 256-byte boundary if necessary. + */ +static void __devinit quirk_plx_pci9050(struct pci_dev *dev) +{ + unsigned int bar; + + /* Fixed in revision 2 (PCI 9052). */ + if (dev->revision >= 2) + return; + for (bar = 0; bar <= 1; bar++) + if (pci_resource_len(dev, bar) == 0x80 && + (pci_resource_start(dev, bar) & 0x80)) { + struct resource *r = &dev->resource[bar]; + dev_info(&dev->dev, + "Re-allocating PLX PCI 9050 BAR %u to length 256 to avoid bit 7 bug\n", + bar); + r->start = 0; + r->end = 0xff; + } +} +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9050, + quirk_plx_pci9050); + static void __devinit quirk_netmos(struct pci_dev *dev) { unsigned int num_parallel = (dev->subsystem_device & 0xf0) >> 4; -- cgit From 2794bb28b66b61eca15ffc492463001445a47227 Mon Sep 17 00:00:00 2001 From: Ian Abbott Date: Mon, 29 Oct 2012 14:40:18 +0000 Subject: PCI: Add PLX PCI 9050 workaround for some Meilhaus DAQ cards The Meilhaus ME-2000i and ME-2600i data acquisition cards supported by the Comedi "me_daq" driver use the PLX PCI 9050 PCI Target bridge chip affected by the bug that prevents the chip's local configuration registers being read from BAR0 or BAR1 base addresses that are an odd multiple of 128 bytes. Use the PLX PCI 9050 quirk handler for these devices to re-allocate affected regions to a 256-byte boundary. Signed-off-by: Ian Abbott Signed-off-by: Bjorn Helgaas --- drivers/pci/quirks.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 2d0d1c229c68..0c59f7aba12b 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1817,6 +1817,17 @@ static void __devinit quirk_plx_pci9050(struct pci_dev *dev) } DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9050, quirk_plx_pci9050); +/* + * The following Meilhaus (vendor ID 0x1402) device IDs (amongst others) + * may be using the PLX PCI 9050: 0x0630, 0x0940, 0x0950, 0x0960, 0x100b, + * 0x1400, 0x140a, 0x140b, 0x14e0, 0x14ea, 0x14eb, 0x1604, 0x1608, 0x160c, + * 0x168f, 0x2000, 0x2600, 0x3000, 0x810a, 0x810b. + * + * Currently, device IDs 0x2000 and 0x2600 are used by the Comedi "me_daq" + * driver. + */ +DECLARE_PCI_FIXUP_HEADER(0x1402, 0x2000, quirk_plx_pci9050); +DECLARE_PCI_FIXUP_HEADER(0x1402, 0x2600, quirk_plx_pci9050); static void __devinit quirk_netmos(struct pci_dev *dev) { -- cgit From 6e965e0d0e1d102c261326b06338d3385ea55f97 Mon Sep 17 00:00:00 2001 From: Huang Ying Date: Fri, 26 Oct 2012 13:07:51 +0800 Subject: PCI/PM: Add comments for PME poll support for PCIe There are comments on why PME poll support is necessary for PCI devices, but not for PCIe devices. That may lead to misunderstanding that PME poll is only necessary for PCI devices. So add comments related to PCIe PME poll to make it more clear. The content of comments comes from the changelog of commit: 379021d5c0899fcf9410cae4ca7a59a5a94ca769 Signed-off-by: Huang Ying Signed-off-by: Bjorn Helgaas Acked-by: Rafael J. Wysocki --- drivers/pci/pci.c | 28 +++++++++++++++++++--------- 1 file changed, 19 insertions(+), 9 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 54858838f098..485cfa9af2ef 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1578,15 +1578,25 @@ void pci_pme_active(struct pci_dev *dev, bool enable) pci_write_config_word(dev, dev->pm_cap + PCI_PM_CTRL, pmcsr); - /* PCI (as opposed to PCIe) PME requires that the device have - its PME# line hooked up correctly. Not all hardware vendors - do this, so the PME never gets delivered and the device - remains asleep. The easiest way around this is to - periodically walk the list of suspended devices and check - whether any have their PME flag set. The assumption is that - we'll wake up often enough anyway that this won't be a huge - hit, and the power savings from the devices will still be a - win. */ + /* + * PCI (as opposed to PCIe) PME requires that the device have + * its PME# line hooked up correctly. Not all hardware vendors + * do this, so the PME never gets delivered and the device + * remains asleep. The easiest way around this is to + * periodically walk the list of suspended devices and check + * whether any have their PME flag set. The assumption is that + * we'll wake up often enough anyway that this won't be a huge + * hit, and the power savings from the devices will still be a + * win. + * + * Although PCIe uses in-band PME message instead of PME# line + * to report PME, PME does not work for some PCIe devices in + * reality. For example, there are devices that set their PME + * status bits, but don't really bother to send a PME message; + * there are PCI Express Root Ports that don't bother to + * trigger interrupts when they receive PME messages from the + * devices below. So PME poll is used for PCIe devices too. + */ if (dev->pme_poll) { struct pci_pme_device *pme_dev; -- cgit