Messages in this thread | | | Subject | Re: genirq vs. fastack | From | Benjamin Herrenschmidt <> | Date | Wed, 31 May 2006 19:11:57 +1000 |
| |
> I see your point, but isn't EOI the chip specific implementation of > chip->ack() in that case ?
Not ack, end :)
The ack is implicit when retreiving the irq number (when the irq happens), the register is even called the ack register :) the EOI isn't ack'ing, it's really "end of interrupt", that is end of handling by the processor, thus the CPU local priority can be lowered to what it was when the interrupt happened.
> The intention was to get down to the chip primitives and away from the > flow type chip->functions. Your patch would actually force the flow > control part (if (!(desc->status & IRQ_DISABLED))) back into the end()
No. end() for mpic and xics will be the exact same one-liner. The whole point is that on those chips, mask/unmask are completely disconnected from the interrupt flow. Mask should happen when disable_irq() is called wether the irq is in progress or not, independently, and thus the handler shouldn't mask. Beside, eoi _must_ be called wether it was masked in between or not or the controller will lose track.
> function for Ingo's x86 implementation. So the intended seperation of > low level chip functions and flow control would be moot.
Nope. Both MPIC and xics will mask/unmask in ... mask() and unmask() _and_ have a end() handler that does a EOI without testing if the irq was disabled. There is no flow handling. That's the whole point of the handler for "smart" controllers. Non smart controllers can use normal flow handlers as far as I'm concerned.
Ben.
- 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/
| |