On Thu, Apr 07, 2011 at 10:28:52AM -0700, Kristen Carlson Accardi wrote: > On Thu, 7 Apr 2011 13:17:58 -0400 (EDT) > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > On Thu, 7 Apr 2011, Kristen Carlson Accardi wrote: > > > > > I was thinking about this last night, and I realized that I wasn't > > > thinking of the shared interrupts correctly. One thing we could do > > > to take care of the shared interrupts while in suspend issue would > > > be to make a flag that would indicate whether the device can receive > > > irqs as a wake up source. Then, in the irq handler you could > > > check if you are suspended, and if the flag is not set then you > > > can ignore the irq, otherwise you would need to wake up and see if > > > it is for you. I believe this would at least get rid of the > > > problem with having a lot of wakeups. If you wanted to optimize > > > further, you could also only do the get/put if your device has > > > the can_wake_irq flag (or whatever) set. > > > > Yes, that would work. Once we move to threaded interrupts, that is. > > > > Alan Stern > > > > Would you guys like me to send you a patch that you can add to > your development kernel to put make usb_hcd_irq threaded? I can also > add the can_wake_irq stuff in a separate (dependent) patch. Yes, that would be good and I would like to take that. But note, you can solve your problem today by just turning on "threaded interrupts for the whole system" which should do what you are looking for here, right? Then there's no need to do this on a per-interrupt-handler basis for your system. thanks, greg k-h -- 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
