On Thu, 15 Nov 2012, Thomas Gleixner wrote:
> > This reminds me -- it might be a good idea to start migrating the USB
> > host controller drivers to use threaded interrupts. The difficulty is
> > that I'm not sure what would be required.
>
> I had some rough go at it two years ago, but hell don't ask me where I
> buried those patches.
In fact, I still have a copy of your email from back then. :-) I was
planning to use it as a guide.
> 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.
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?
> 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.
To prevent the timer handler from interfering with the threaded
handler, should the threaded handler use spin_{un}lock_bh()?
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
