On Wed, 2 Mar 2011, Russell King - ARM Linux wrote:

On Tue, Mar 01, 2011 at 10:29:37PM +0100, Thomas Gleixner wrote:

quoted

Errm. I did never say that we disable the parent interrupt by any
means except when the chained handler explicitely wants to do that,
which is pretty much pointlesss nowadays, as we run all interrupt
handlers with interrupts disabled.

And that's now why some platforms struggle to work, and we're having
to bodge around this - like the ARM platforms with MMC support.  Like

Whats the problem for MMC?

some other platforms where having IRQs disabled during IDE prevents
interrupts being recevied for long periods of time (longer than the
100Hz tick period).

That was discussed to death already and the general agreement was that
those handlers should either enable interrupts themself, when it's
required, or being converted to threaded handlers. An interrupt
handler or any other code section which runs more than 10ms with
interrupts disabled is a bug by definition.

I *violently* disagree with the direction that genirq is heading.  It's
*actively* breaking stuff.  What's really annoying is that problems like
the above I did point out, but you seem happy to completely ignore them.
The result is that more and more ARM platforms *are* becoming utterly
useless, or requiring additional complexity being shoved into subsystems
to cope with this crap.

What we need is a *decent* IRQ support system.  Not something created out
of religious arguments which is what we have now.

 
I'm not religious about it, at least not more than you with your total
refusement to distinguish between special case oddball FPGA demux and
bog standard functional irq chips.

Thanks,

	tglx