[Top] [All Lists]

Re: How to request an IRQ for NMI on MIPS Processor

To: Adeel Malik <>
Subject: Re: How to request an IRQ for NMI on MIPS Processor
From: Ralf Baechle <>
Date: Tue, 4 Nov 2003 14:28:01 +0100
In-reply-to: <10C6C1971DA00C4BB87AC0206E3CA38264F543@1aurora.enabtech>
Original-recipient: rfc822;
References: <10C6C1971DA00C4BB87AC0206E3CA38264F543@1aurora.enabtech>
User-agent: Mutt/1.4.1i
On Tue, Nov 04, 2003 at 05:58:32PM +0500, Adeel Malik wrote:

> Hi Ralph,

Who is that guy? ;-)

>          Thanks for the reply. Yes you are right that NMI isn't meant to
> be used as a regular IRQ of MIPS Processor. But somehow the board designer
> connected the External Interrupt from video capture device to the NMI and
> now I am thinking as how to how implement the Interrupt handler routine for
> the NMI of MIPS processor. Do you think that we need to re-route the Board
> or there may be some patch available describing the implementation of
> Interrupt handler for NMI of MIPS 4Kc.

As I said the NMI goes through the firmware so the way how to handle the
NMI on your specific board is entirely upto the firmware.  This is also
why you don't find much code related to NMIs in Linux.

I think it's highly desirable to fix this little hardware problem even
though that is going to involve some cost.  To look at things a bit more
from the Linux side:

 - NMI may even interrupt a previous NMI.  Again that means you'll lose your
   previous state, dead.
 - NMI means you have to paranoidly check the interrupt code.

Hmm...  Here's a little idea.  Bits 8 and 9 in the status and cause
registers are for the MIPS sofware interrupt bits which Linux doesn't use
at all.  NMI could use those so on return from NMI a normal maskable
interrupt would be triggered.  That would minimize the NMI path and
complications that could arise from it's not-maskability.


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