Re: genirq vs. fastack

[Thomas Gleixner <tglx@linutronix.de>]

Hi Ben,

On Wed, 2006-05-31 at 11:52 +1000, Benjamin Herrenschmidt wrote:
> Hi Thomas, Ingo !
> 
> There is one bit in genirq that I don't get (and doesn't work for me),
> it's the "fastack" handler. It does:
> 
> out:
> 	if (!(desc->status & IRQ_DISABLED))
> 		desc->chip->ack(irq);
> 	else
> 		desc->chip->mask(irq);
> 
> Which doesn't at all match the needs of things like XICS or MPIC and
> thus I wonder if it does also make sense for controllers for which you
> intend it. It should just be:
> 
> 	desc->chip->end(irq);
> 
> Basically, those controllers will have 1) already acke'd the interrupt
> by the time you get the vector (the act of getting the vector does the
> ack), 2) will use a processor priority mecanism to handle non-reentrency
> of an interrupt thus mask/unmask is completely orthogonal to handling of
> interrupts and thus there is no need to do anything about mask/unmask in
> the handler, 3) all we need is to do an "EOI" (end of interrupt) at the
> end of the handling, which is what is done logically in the end()
> handler.

I see your point, but isn't EOI the chip specific implementation of
chip->ack() in that case ? 

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()
function for Ingo's x86 implementation. So the intended seperation of
low level chip functions and flow control would be moot.

	tglx


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