On Thu, 15 Nov 2012, Alan Stern wrote:
> On Thu, 15 Nov 2012, Thomas Gleixner wrote:
> > The main thing is that you need a real primary handler, which runs in
> > hard interrupt context, because the USB interrupts are often shared
> > and you don't want and cannot block out the other devices while you
> > are handling your device.
> >
> > So the primary handler has to figure out (as it does now) whether the
> > interrupt originates from the USB device. If not it returns IRQ_NONE
> > as now. If yes, it has to disable the interrupt at the host device
> > level and return IRQ_WAKE_THREAD. IIRC one of the problems I ran into
> > was that not all host controllers preserve the interrupt cause when
> > you have read it out already, but my memory is really blurry.
>
> Right, I follow that. It's easy to save a copy of the interrupt cause.
>
> > Now the threaded handler does the device handling and at the end of
> > it, it reenables the interrupts at the device level again for the next
> > round.
>
> Does this depend on how much work the primary handler needs to do in
> order to turn off the interrupt source? For example, if the interrupt
> source can be turned off simply by clearing a bit in a status register,
> couldn't the primary handler do that and then leave device interrupts
> enabled? If multiple interrupts arrived before the threaded handler
> started running, they could all be OR'ed together in the saved
> interrupt-cause value.
Yeah, that's fine.
> 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.
> > 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?
> 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.
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
