On Tuesday, November 01, 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... OK, so this means the BIOS doesn't allow us to control PCIe PME signaling and then it is _should_ trigger GPEs. (1) How exactly have you verified that there are no GPEs signaled? I'm asking, because it _looks_ like a GPE actually _is_ signaled. (2) Any chance to see /proc/interrupts from the Linus' machine? > 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). That's not very likely to work from my experience. > Either way, I guess the BIOS on this machine just doesn't expect PME > to be used on this device at all... Well, it doesn't have any other chance to actually get the signals. The only thing that the BIOS can do is to tell the kernel not to handle PME directly. But then, if the BIOS doesn't handle them (which seems to be the case here), we need to poll the devices. Thanks, Rafael -- 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
