On Thu, 15 Nov 2012, Alan Stern wrote:
> On Thu, 15 Nov 2012, Thomas Gleixner wrote:
>
> > > I guess this amounts to the same thing as asking what happens if a
> > > device interrupt occurs while the threaded handler is running. Would
> > > the kernel then schedule the threaded handler to run a second time?
> > > Or is it not prepared to handle this sort of thing?
> >
> > Right now, it reschedules it, but I have some idea how to deal with
> > that.
>
> Isn't rescheduling the right thing to do? Presumably the threaded
> handler is only aware of the hardware events that occurred before it
> started running. If new events occur while the handler is running, it
> should be rescheduled so that it can take care of them.
Yes, that's what the code does now. Though there were people asking in
some other context to have an interface which lets them poll from
their interrupt handler thread code whether there is a new event
pending and clear that to avoid a full round trip.
> > > > So the only thing you have to worry about vs. interupts is protecting
> > > > the access to the irq related hardware registers and of course vs. the
> > > > timers. Btw, what's the reason for using hrtimers in USB?
> > >
> > > The ehci-hcd driver often needs delays ranging between 1 and 10 ms.
> > > hrtimers seemed to be the best way of getting them.
> >
> > Are these delays related to the interrupt flow or do they come from a
> > separate control entity?
>
> Most of them come from a separate control entity. A couple are related
> to the interrupt flow. (For example, sometimes an interrupt occurs and
> the interrupt handler needs to schedule a timer for 2 ms in the
> future.)
>
> > > 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.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
