Subject: RE: How to request an IRQ for NMI on MIPS Processor

From: Adeel Malik <[email-masked]>
Date: Tue, 4 Nov 2003 17:58:32 +0500

Hi Ralph,
	   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.

Regards, 	

ADEEL MALIK,

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Ralf Baechle
Sent: Tuesday, November 04, 2003 5:31 PM
To: Adeel Malik
Cc: [email-masked]
Subject: Re: How to request an IRQ for NMI on MIPS Processor

On Tue, Nov 04, 2003 at 04:56:08PM +0500, Adeel Malik wrote:

>           In my embedded design, I intend to use NMI of MIPS 4Kc processor
> (rather than IRQ0 or IRQ1 .....) for an external Interrupt Source. The
> external Interrupt source is a video capture device which interrupts the
> MIPS 4Kc CPU via its NMI (Non-Maskable Interrupt) line, whenever it has
one
> complete frame. I need to write the driver for that device in
Linux-2.4.20.
> The request_irq function provided by Linux takes a digit value from 0 to 5
> to map external interrupt sources to any one of CPUs Interrupt pins. How
can
> I request and implement my interrupt handler routine for the NMI of MIPS
> processor ?.

Is there any particular reason for using the NMI?

NMI on MIPS is pretty much miss-designed for use in application code; it's
use should be limited to debugging and recovery from catastrophical
failure.  The reason for this is the way this exception is handled:

  - the BEV, TS, SR, NMI and ERL bits in c0_status are overwritten - that is
    their old state is lost.
  - c0_errorepc is overwritten - again that means the old value is lost so
    in case the NMI interrupts an exception handler that uses this register
    such as the cache error handler you can not resume execution.
  - the program counter is set to 0xbfc00000.  Most likely a slow flash
    memory is mapped at this address but in any case it's an uncached
    segment of the address space so execution will be even slower.
  - execution will pass through the firmware.  That means you can only
    use the NMI at all if firmware provides some kind of hook.

It seems pretty clear to me that the MIPS designers never intended the
NMI for anything else than catastrophic events.

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 4 Nov 2003 14:28:01 +0100

> Hi Ralph,
        ^^

Who is that guy? ;-)

> 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.

  Ralf