On Wednesday, November 02, 2011, Linus Torvalds wrote: > On Tue, Nov 1, 2011 at 3:28 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > > > > The fact that you see the EHCI "resume" messages with commit 379021d5c0 applied > > means that the EHCI really does have the PME Status bit set when it's being > > polled, because the resume wouldn't be triggered otherwise. > > I don't think that is true. > > > So, it _seems_ like plugging the USB device into the xHCI port causes the EHCI's > > PME Status bit to be set as well. > > I suspect that runtime-PM is doing something wrong, because I can not > confirm that at all. > > > You can try to confirm this by looking at the PME Status bits of the > > devices in question under 3.1 (ie. without commit 379021d5c0) before > > (they should be unset) and after plugging in the USB device (the xHCI's PME > > status should be set, the EHCI's one may or may not be set). Simply look at > > the status line under the PM capability in the output of "lspci -vv" for > > each interesting device. > > No. In 3.1, the *only* device with "PME+" is the NEC XHCI controller. > > An no dmesg entries or anything. There does seem to be ACPI interrupts > happening, although I do not know whether they really were related to > the USB insertion event. If the number in /sys/firmware/acpi/interrupts/gpe0D increases too at the same time, then they are related. > > I wonder if plugging a device into a known non-xHCI USB port triggers any > > events with plain 3.1? > > Yes. Plugging something into the other USB port (which I originally > didn't even realize is a USB port at all: I think it's an eSATA port > as well) works. > > But it shows similar crazy "cross-talk" issues: when that event > happens, *both* ehci controllers get woken up, *and* the xhci > controller does too. Does the Ehternet controller take part in that too? > I really think there is something wrong in the PM code. That's entirely possible, but I'd like to understand what's going on. :-) > I do believe that there could be a BIOS issue too (let me be on record - for > the millionth time - as saying that BIOS coders are monkeys on crack and > to basically expect all firmware to be broken by default), but see > above: the hardware isn't *that* broken. The PME+ status really only > happened for the XHCI controller when I plugged in the USB cable in > there. So the fact that current git will chatter about all those other > controllers means that there must be paths that do *not* check PME. PME Status that is. Well, pci_acpi_wake_dev() appears to be the only one, at least in the PCI land. pci_pme_wakeup_bus() calls pci_pme_wakeup() recursively and that _does_ check PME Status. The polling uses pci_pme_wakeup() too. However, the Matthew's patch changing pci_acpi_wake_dev(), reproduced below, didn't make any difference for you and, moreover, the DSDT doesn't seem to contain any device objects for xHCI, so at least this one shouldn't be notified via ACPI. Bummer. So I wonder if the wakeups may actually originate in the USB land? I mean, we have the logic causing child devices to resume their parents, so perhaps when EHCI is woken up, it wakes up USB-something and that causes the other controllers to resume? Alan, is that possible at all? Rafael diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c index 4ecb640..67698e8 100644 --- a/drivers/pci/pci-acpi.c +++ b/drivers/pci/pci-acpi.c @@ -50,8 +50,10 @@ static void pci_acpi_wake_dev(acpi_handle handle, u32 event, void *context) pci_dev->pme_poll = false; pci_wakeup_event(pci_dev); - pci_check_pme_status(pci_dev); - pm_runtime_resume(&pci_dev->dev); + + if (pci_check_pme_status(pci_dev)) + pm_runtime_resume(&pci_dev->dev); + if (pci_dev->subordinate) pci_pme_wakeup_bus(pci_dev->subordinate); } -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
