Re: Threaded interrupt handling question in RT kernel

On Tue, 16 Aug 2011, Jaccon Bastiaansen wrote:

Hello Thomas, Peter

We have a question about threaded interrupt handling:

By default, when using threaded interrupt handlers, the IRQ is
disabled in hard IRQ context and enabled again after all threaded
interrupt handlers connected to that IRQ have run. In this way, high
priority interrupt handlers can be delayed until the lowest priority
interrupt handler thread has run. Therefore it seems that it's not
useful to have a separate thread for each interrupt handler (what's
the use of being able to set interrupt handler thread priorities when
you still have to wait for the one with the lowest priority).

That's correct, but RT just makes use of the general facility which is
designed to have a separate thread for each device.
 

So we think that we should use the request_threaded_irq() function.

You can do that for a specific driver, but we cannot do that in RT for
every driver in the kernel.

The task of the handler that is executed in hard IRQ context is to
check whether the device that it controls is generating an interrupt
and if it does, deactivate the IRQ output of the device and wakeup the
interrupt handler thread by returning IRQ_WAKE_THREAD. By deactivating
the IRQ output, another device connected to the same IRQ can activate
the IRQ again before the interrupt handler thread of the first device
has run. This guarantees that a high priority threaded interrupt
handler of a device on a shared IRQ can run before a low priority
threaded interrupt handler of a device on the same IRQ has run. So
when using threaded interrupt handlers for devices on a shared IRQ,
make sure that all drivers have used request_threaded_irq().
Otherwise, high priority threaded interrupt handlers can be delayed by
low priority threaded interrupt handlers.

Is all this correct or do we miss something?

That's how it's designed to work.

Thanks,

	tglx