From mboxrd@z Thu Jan  1 00:00:00 1970
From: tglx@linutronix.de (Thomas Gleixner)
Date: Wed, 2 Mar 2011 00:44:05 +0100 (CET)
Subject: [PATCH 6/6] ARM: nmk: update GPIO chained IRQ handler to use
	EOI in parent chip
In-Reply-To: <20110301231432.GG27107@n2100.arm.linux.org.uk>
References: <1298900022-21516-1-git-send-email-will.deacon@arm.com>
	<1298900022-21516-7-git-send-email-will.deacon@arm.com>
	<20110228140327.GA1937@n2100.arm.linux.org.uk>
	<001401cbd772$a1f93ae0$e5ebb0a0$@deacon@arm.com>
	<alpine.LFD.2.00.1102281949050.2701@localhost6.localdomain6>
	<20110228214445.GD1937@n2100.arm.linux.org.uk>
	<alpine.LFD.2.00.1103011140560.2701@localhost6.localdomain6>
	<20110301201904.GA27107@n2100.arm.linux.org.uk>
	<alpine.LFD.2.00.1103012133530.2701@localhost6.localdomain6>
	<20110301231432.GG27107@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.00.1103020033080.2701@localhost6.localdomain6>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

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