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.
[mailto:email@example.com]On Behalf Of Ralf Baechle
Sent: Tuesday, November 04, 2003 5:31 PM
To: Adeel Malik
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
> complete frame. I need to write the driver for that device in
> 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
> 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.