On Tue, 29 Mar 2011, Atsushi Nemoto wrote:
> > > Then that code was broken before. Since MIPS was converted to the flow
> > > handlers nothing ever called .end(). I seem to miss something.
> > I'll see what I can do about it, but I need a pointer to the offending
> > change -- Ralf or anyone, can you provide me with one?
> JFYI from my old memory...
> On 2006, I once converted ioasic_irq and ioasic_dma_irq to the flow
> handlers, and then revert ioasic_dma_irq to old style.
> Then, Franck Bui-Huu added GENERIC_HARDIRQS_NO__DO_IRQ to some
> platforms but not DECstation.
> And then, on 2009, Ralf enabled GENERIC_HARDIRQS_NO__DO_IRQ for all
> I suppose something was lost at this conversion, but not sure.
I've had a look into the issue and my understanding at the moment is the
IOASIC DMA interrupts will need a dedicated handler along the lines of the
old approach, i.e. mask at the beginning (because the output is
level-triggered) to let other interrupts through, call the high-level
handler, and issue an EOI and unmask at the end (some of these interrupts
are informational only so the EOI could well be issued at the beginning,
but there's no gain from doing so that would justify the extra
diversification). I've noticed some other (non-MIPS) platforms use their
own handlers too, so it's not the only one the new generic handlers do not
fit, sigh... I'll see what I can do about this problem.
OTOH, the remaining ordinary IOASIC interrupts are just plain old
level-triggered pass-through signals with no actions beyond mask/unmask
required/available at the interrupt controller level, so the
handle_level_irq() is exactly what they need.
As I say, except from our driver for the onboard SCSI adapter (that is
pending a revive), we only use these DMA interrupts for exceptional
conditions, such as a memory error during a DMA transaction, so they
hardly ever happen and any run-time breakage could have survived for long.