On Wed, 6 Apr 2011 15:26:37 -0700 Greg KH <greg@xxxxxxxxx> wrote: > On Wed, Apr 06, 2011 at 02:36:24PM -0700, Kristen Carlson Accardi wrote: > > 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 :). > > No, I would like to move to a threaded irq eventually for USB as it > would make the RT people much happier. It is the right thing to do, and > if you want to push for it, I have no objection. > > But we should make that change independant of your resume issues so it > gets good testing. I'm actually not in a big rush to push my resume issue fix as the patch that WorksForMe(tm) is small enough to be carried in the Meego kernel for a while. So while we would obviously prefer to not carry around patches that are not upstream, my needs are temporarily taken care of. If it is feasible, I would love to see you move sooner rather than later. The thing is - once you move to a threaded irq, my resume issue is pretty much not going to impact anyone else, even if you leave the get/put calls exactly where I have them in the patch. Basically, unless you are a strange whacky piece of hardware like Moorestown, you will never get an irq while you are suspended. If you are not suspended, then a call to get_sync() is just going be incrementing a ref counter, not actually scheduling a resume, and so should not cause anyone normal any problems. If you *are* a strange piece of hw and getting an irq during suspend, then you are a) most likely not sharing irqs, so this isn't a big deal and b) if you are sharing an irq, then that is just a penalty you are going to have to take for having dumb hardware designers. I guess what I'm saying is that I feel the get/put calls are rather insignificant once you take the leap of going to a threaded irq. And is much cleaner to just take care of the wakeup like this than to try to move it down into ehci or some other platform specific host driver. > > > 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. > > That would get messy, I'd prefer to just do it all at once instead of > waiting for the individual host controllers to have to enable it as odds > are some never will be changed and no one will remember why they didn't. > You could do somethink like add an op: .alloc_irq if (op->alloc_irq) let controller driver do allocation, which would allow them to call request_threaded_irq and swap out the irq handler with their own, or not - if usb_hcd_irq is made available. else driver doesn't have a special alloc, so just do it the way you always have. Although as I said, it seems cleaner to just do the put/get in usb_hcd_irq. Thanks, Kristen -- 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
