Re: genirq vs. fastack

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> 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/