On Wed, 6 Apr 2011, Kristen Carlson Accardi wrote: > > > 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. You might be able to do a partial resume in the interrupt handler -- enough to allow the request to be turned off. However this may not be worth the trouble, especially if we make the move to threaded interrupts. 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
