On Wed, 6 Apr 2011, Kristen Carlson Accardi wrote: > > Indeed, this is not necessarily the best approach. Without using > > threaded interrupts you could call pm_runtime_get() and > > pm_runtime_put() in hcd_irq(), and also add a call to usb_hcd_irq() in > > hcd-pci.c:resume_common() after the ->pci_resume call. > > > > For that matter, it's not clear that all platforms should be > > unconditionally forced to call pm_runtime_get/put in the interrupt > > handler. With shared interrupts, this could amount to a lot of useless > > suspend/resume activity. Can those calls be made specific to > > Moorestown? Maybe even moved down into ehci-hcd? > > > > You might even find that a quick check irq (whatever that is) becomes > > feasible. > > > > Alan Stern > > > > I have done zero testing with other controllers. I was hoping to > just kick off a discussion about the best way to handle non-PME > wakeups. Okay. It looks like you succeeded! :-) > If I call pm_runtime_get() in the irq, obviously I can't be > sure the HW is available right away, so I could not mask the > interrupt until after resume was called. Correct. > Wouldn't that lead > to a lot of interrupts being generated while we wait for > resume to complete? Yes, it would. That's a symptom of badly designed hardware -- a device generates an interrupt request while in a state such that the interrupt handler cannot turn off the request. This also shows why you would be better off moving the code changes down into ehci-hcd. You could write a Moorestown-specific interrupt handler which would first check whether the controller was suspended. If it was, the handler could turn off the interrupt request and call pm_runtime_get(); otherwise it could call ehci_irq() directly and then see whether it needed to call pm_runtime_put() (or possibly pm_runtime_put_autosuspend()). > We could, I'm sure figure out a way to make this platform > specific - but I'm wondering if there may be other platforms > besides Moorestown that may wakeup during suspend w/o PME, > and if we should consider a general purpose solution. There may very well be other platforms that could benefit from this. Unfortunately I don't know anything about them -- we'll have to wait and see if anyone else on the mailing list speaks up. At this point it's unclear what changes to usbcore would be most beneficial. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
