[Top] [All Lists]

Re: [patch 06/38] mips: dec: Convert to new irq_chip functions

To: Atsushi Nemoto <>
Subject: Re: [patch 06/38] mips: dec: Convert to new irq_chip functions
From: "Maciej W. Rozycki" <>
Date: Tue, 29 Mar 2011 14:20:16 +0100 (BST)
In-reply-to: <>
Original-recipient: rfc822;
References: <> <alpine.LFD.2.00.1103242024470.31464@localhost6.localdomain6> <> <>
User-agent: Alpine 2.00 (LFD 1167 2008-08-23)
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
> platforms.
> I suppose something was lost at this conversion, but not sure.

 OK, thanks.

 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.


<Prev in Thread] Current Thread [Next in Thread>