![]() | |||||||||||||
Messages in this thread |
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > If my understanding of "threaded handlers" is correct, that is > delaying the delivery of the interrupt to a thread while restoring the > ability to process further interrupts of the same or lower priority > immediately. correct. It's basically a different type of 'flow' of handling an interrupt. It's a host-side genirq-level detail that should have no irqchip level impact at all. The only detail is that sometimes a threaded flow /cannot/ be implemented if the irqchip lacks certain methods. (such as a mask/unmask) i.e. Sergei's patch tweaking the irqchip data structures is wrong - the correct approach is what i do for i386/x86_64: install a different "threaded" flow handler. I prefer this to tweaking the existing 'fasteoi' handler, to make the act of supporting a threaded flow design explicit. (and to allow a mixed threaded/non-threaded flow setup) I didnt take Daniel's prior patch for that reason: he tried to tweak the fasteoi flow handler - which is an almost good approach but not good enough :-) > There is no such thing as an explicit "ack" on fasteoi controllers. > The ack is implicit with the reading of the vector (either via a > special cycle on the bus or via reading the intack register for > example on mpic). well, even if it's coupled to the reading of the vector, there is an ack initiated by the host. This is not really a fundamental thing, it's API semantics of the hardware interface. so the question is not 'is there an ACK' (all non-MSI-type-of IRQ delivery mechanisms have some sort of ACK mechanism), but what is the precise structure of ACK-ing an IRQ that the host recieves. on PPC64, 'get the vector' initiates an ACK as well - is that done before handle_irq() is done? > So by doing a mask followed by an eoi, you essentially mask the > interrupt preventing further delivery of that interrupt and lower the > CPU priority in the PIC thus allowing processing of further > interrupts. correct, that's what should happen. > Are there other fasteoi controllers than the ones I have on powerpc > anyway ? well, if you mean the x86 APICs, there you get the vector 'for free' as part of the IRQ entry call sequence, and there's an EOI register in the local APIC that notifies the IRQ hardware, lowers the CPU priority, etc. We have that as an ->eoi handler right now. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-11-20 10:07 [from the cache] ©2003-2008 | |||||||||||||