[PATCH 6/6] ARM: nmk: update GPIO chained IRQ handler to use EOI in parent chip

[Thomas Gleixner]

On Tue, 1 Mar 2011, Russell King - ARM Linux wrote:

> On Tue, Mar 01, 2011 at 10:29:37PM +0100, Thomas Gleixner wrote:
> > Can you please take the time and explain me the difference of the
> > following:
> 
> Can you please take the time to realise that sometimes the combination
> between the primary and secondary interrupt controller is so tied that
> this kind of thing can't happen?
> 
> Sometimes the secondary interrupt controller *must* mask the parent
> interrupt because it has no masking capability of its own.
> 
> Sometimes the secondary interrupt controller *must* cause the primary
> controller to ack the interrupt status *before* the secondary handler
> reads the status.
> 
> You can not say "the primary controller behaves like X so we always do
> X" because the action required on the primary is a combination of how
> the primary behaves *and* how the secondary behaves.
> 
> Consider for example an edge triggered interrupt connected to a secondary
> controller - yes, we have that combination.  When you read the secondary
> status register and clear those interrupts which are pending, the
> secondary controller resets to inactive its output.  If there's still
> pending interrupts, it re-asserts the output causing a new edge.
> 
> If your primary 'flow' handler were to acknowledge the interrupt *after*
> the demux, you'd lose interrupts.
> 
> However, if the very same primary interrupt controller is connected to
> a FPGA based oring of several interrupt sources, this has to ack before
> reading the status, read the status, process *all* interrupts, re-ack,
> re-read the status and repeat until the status register indicates no
> further interrupts are pending.
> 
> You can't deal with these two situations if you tie all the primary
> flow handling outside of the secondary demux handler.  And it's
> *wrong* to do so.  The behaviour required for the primary controller
> inherently depends on the secondary controller.
> 
> It may not be clean from a software point of view, but that's hardware
> for you, and we have to make this work.  You *can't* do that by
> separating the primary flow from the demux.

You are talking about very specific cases, where the demux handler is
tighlty integrated into the primary chip implementation. No discussion
about that. I do not want to change anything there. Period.

The problem which caused that discussion has nothing to do with the
above. It's about bog standard nested controllers which do not have a
tight coupling to the the primary chip. But changing the primary chip
from ack based to eoi based requires to touch multiple demux handlers
while a primary chip agnostic solution for these cases would avoid
that. W/O any negative side effects.

Your oddball FPGA example has nothing to do with that and can happily
use the existing model. Such a demux handler will never have to deal
with different primary chips.

Thanks,

	tglx