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... -- Jesse Barnes, Intel Open Source Technology Center
Attachment:
signature.asc
Description: PGP signature
