On Tue, 1 Nov 2011, Jesse Barnes wrote: > On Tue, 1 Nov 2011 13:50:13 -0400 (EDT) > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > On Tue, 1 Nov 2011, Jesse Barnes wrote: > > > > > On Tue, 1 Nov 2011 17:00:20 +0000 > > > Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > > > > > > > On Tue, Nov 01, 2011 at 09:57:45AM -0700, Jesse Barnes wrote: > > > > > On Tue, 1 Nov 2011 07:47:05 -0700 > > > > > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > I think that the PCI "poll for PME" logic should just resume the > > > > > > device - and *not* suspend it again. Maybe it can suspend it next time > > > > > > around when it polls, if PME has been cleared. That should be (a) sane > > > > > > and (b) obviate any need for some random delay in some random driver. > > > > > > > > > > > > Jesse? > > > > > > > > > > > > That said, Matthew's suggestion sounds like a good idea regardless. > > > > > > > > > > Yeah that makes sense. But hopefully we can get away without polling > > > > > at all if we actually implement PME message interrupt support on the > > > > > host bridge side. Does anyone with affected hardware want to try that? > > > > > I think the publicly available docs have enough info to do it... > > > > > > > > Don't we already have that, assuming the hardware gives us control via > > > > _OSC? The problem we've seen is that a pile of hardware appears to set > > > > the PME flag without generating any interrupt, regardless of whether > > > > we're in ACPI or native delivery modes. > > > > > > On Linus's machine, we didn't see any GPEs and neither does there seem > > > to be an interrupt handler registered for the PME interrupt... Not > > > that having one registered will guarnatee us anything, but it's worth > > > forcing it to see if we at least get interrupts (though that assumes > > > the NEC device is actually sending PME messages to the root complex > > > correctly). > > > > > > Either way, I guess the BIOS on this machine just doesn't expect PME > > > to be used on this device at all... > > > > Pardon me for being slow, but I don't see how this is related to the > > problem Linus reported. Namely, that _every_ PM event caused both of > > the EHCI controllers to be resumed, even if they had nothing to do with > > the event in question. > > Yeah, I was going back to the original problem of why we didn't get > wakeups from the NEC device. I'd like to avoid polling if at all > possible... Are you certain there weren't any wakeups from the NEC device? The dmesg log did show that it woke up: +[ 1013.660675] xhci_hcd 0000:0f:00.0: PME# disabled +[ 1013.660704] xhci_hcd 0000:0f:00.0: setting latency timer to 64 +[ 1013.666892] pci_pm_runtime_suspend(): hcd_pci_runtime_suspend+0x0/0x20 returns -16 +[ 1013.895959] usb 3-1: new full-speed USB device number 4 using xhci_hcd +[ 1013.923417] xhci_hcd 0000:0f:00.0: WARN: Stalled endpoint +[ 1013.925383] xhci_hcd 0000:0f:00.0: WARN: Stalled endpoint +[ 1013.927351] xhci_hcd 0000:0f:00.0: WARN: Stalled endpoint +[ 1013.943380] xhci_hcd 0000:0f:00.0: WARN: short transfer on control ep +[ 1013.958341] xhci_hcd 0000:0f:00.0: WARN: short transfer on control ep +[ 1013.963336] xhci_hcd 0000:0f:00.0: WARN: short transfer on control ep +[ 1013.970317] xhci_hcd 0000:0f:00.0: WARN: short transfer on control ep +[ 1013.971239] usb 3-1: New USB device found, idVendor=0403, idProduct=f680 +[ 1013.971253] usb 3-1: New USB device strings: Mfr=1, Product=2,SerialNumber=3 +[ 1013.971262] usb 3-1: Product: Suunto Sports Instrument +[ 1013.971268] usb 3-1: Manufacturer: Suunto +[ 1013.971276] usb 3-1: SerialNumber: ST000001 etc. And xhci-hcd is bound to the NEC xHCI controller. Alan Stern -- 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
