Re: PCI runtime PM issue on NEC xHCI host

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...

-- 
Jesse Barnes, Intel Open Source Technology Center

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux