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.
> > > 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?
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
