On Wed, 6 Apr 2011 17:24:27 -0400 (EDT) Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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(); I don't think I can turn off the interrupt request prior to calling pm_runtime_get(), as my hw is not accessible till after resume is complete. I think that would be true of any hw that implemented device wakeups as regular irqs. Is there a general objection to moving to a threaded irq other than it needs to be tested? From my reading threaded irqs can provide some benefit besides just allowing me to sleep while resuming :). You could also allow other drivers to allocate the irq (rather than doing it in hcd.c), which would let them chose whether to be threaded or not. -- 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
