Threaded interrupt handling question in RT kernel

[Jaccon Bastiaansen]

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

So we think that we should use the request_threaded_irq() function.
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?


Regards,
  Jaccon Bastiaansen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/