On Thu, 15 Nov 2012, Thomas Gleixner wrote:
> On Thu, 15 Nov 2012, Alan Stern wrote:
> > > > To prevent the timer handler from interfering with the threaded
> > > > handler, should the threaded handler use spin_{un}lock_bh()?
> > >
> > > _irqsave() unfortunately as the hrtimer callbacks run in hard
> > > interrupt context.
> >
> > Hmmm. Doesn't that mean there would be no benefit from using threaded
> > interrupt handlers?
>
> Not versus the timers. Threaded interrupt handlers are handy, if you
> want to be able to schedule or run complex code w/o hogging the
> (soft)interrupt system for a long time. It also allows you to move stuff
> which you hand off to tasklets, workqueues or other deferred entities
> into your handler which reduced locking complexities and other problems.
>
> But again, that really depends on what your driver/interrupt handler
> has to do and whether avoiding the handoff of work makes sense or not.
Bah. Hit send too fast. :)
That said, it might even make sense versus timers, if you have to
delay operations on the device for time X. You can even just sleep in
your interrupt thread and get woken, when either the timer expires or
another interrupt comes in.
Though I'm not familiar enough with the USB code to tell whether any
of this helps or not. Its definitely pointless just to enforce the
threaded handler and not make use of its extended abilities.
Thanks,
tglx
--
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
