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 -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
