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

From: "Liu Hongming (Alan)" <[email-masked]>
Date: Tue, 11 Nov 2003 13:26:53 +0800

Hi Adeel,
 
I have understood your situation.
 
Under this situation,I think you need not use request_irq.
Just keep your 'interrupt' handler in BIOS or bootloader,
of course,it is different with Rest Exception,since 
many registers' status are not the same as hardware-reseting.
You could detect the difference.Right?

Alan Liu
 
-----Original Message-----
From: Adeel Malik [mailto:[email-masked]]
Sent: Tuesday, November 11, 2003 1:22 PM
To: Liu Hongming (Alan)
Cc: Ralf Baechle; [email-masked]
Subject: RE: How to request an IRQ for NMI on MIPS Processor

Liu,
      In my board the interrupt was routed directly to an NMI line of MIPS
CPU rather than regular IRQs 0 - 5.   I went through the MIPS Architecture
Programming Guide Document, describing Interrupt and Exception Handling for
MIPS Processor. It is written there that although a Non-Maskable Interrupt
(NMI) includes "interrupt" in its name, it is more correctly described as an
NMI exception because it does not affect, nor is it controlled by the
processor interrupt system. 
 
Secondly, Linux Kernel especially the Embedded Linux Versions for various
Processors doesn't support the use of NMI as a regular IRQ.
 
The Interrupt Vector Address of all the Hardware Interrupt from IRQ0 - IRQ5
for MIPS Processor have the same vector location that is 0x80000180 or
0x80000380 which is a cached access, but the vector Location of NMI is
0xbfc00000 which is an un-cached access. So one needs to modify the
boot-code which is error-prone if it is possible at all.
 
Thatswhy we don't find much code related to NMIs in Linux.
 
ADEEL MALIK,

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Liu Hongming (Alan)
Sent: Tuesday, November 11, 2003 9:39 AM
To: Ralf Baechle; Liu Hongming (Alan)
Cc: Adeel Malik; [email-masked]
Subject: RE: How to request an IRQ for NMI on MIPS Processor

Hi Ralf, 

I have never used these kind of boards.It seems to me 
NMI is implemented by interrupt controller,to cpu,it is a 
normal interrupt source.If 'NMI' in Adeel's board is like 
what you repeated,request_irq could just use cpu's pin number 
as the 'irq' parameter. I think NMI has been used in many 
boards that only means 'non-maskable' to interrupt controller, 
not cpu. If it is this case, NMI interrupt is a normal case. 

Regards, 
Alan Liu 

-----Original Message----- 
From: Ralf Baechle [ mailto:[email-masked] <mailto:[email-masked]>
] 
Sent: Tuesday, November 11, 2003 11:40 AM 
To: Liu Hongming (Alan) 
Cc: Adeel Malik; [email-masked] 
Subject: Re: How to request an IRQ for NMI on MIPS Processor 

Liu, 

On Tue, Nov 11, 2003 at 10:51:50AM +0800, Liu Hongming (Alan) wrote: 

> when using request_irq(...),the parameter irq is a value specified by you,

> of course,when porting linux for your board,you should have specified
value 
> for every IRQ. 0--5 only means CPU pin for interrupt,unless that only one 
> interrupt 
> may occur on this pin,you will use other value in request_irq,instead of 
> 0-5. 
>  
> all in all, when we touch request_irq,it is board specific.When your board

> has 
> been made out,all interrupts have specific route to cpu(unless you have
IRQ 
> router,since embedded,need this??).If you have more external interrupts
than 
> cpu pins,maybe you have cascaded many interrupt using one cpu pin.So, 
> the parameter irq in request_irq is determined by your board and your 
> porting 
> for interrupt handling.Just ask that guy that ported linux.He will tell 
> you.If you 
> are using linux ported by others,have a look at BSP codes. 

your answer is correct for normal interrupts, not the NMI.  The NMI goes 
through the firmware and none of the board support code so far bothered 
to make it available via request_irq as it has several severe limitations. 
To repeat one of my prior postings about 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, 11 Nov 2003 06:45:29 +0100

> Under this situation,I think you need not use request_irq.

Request_irq is just the software interface; it could be used to drive
any kind of interrupt mechanism, even NMI or the two MIPS software
interrupts.  The actual problem here is the underlying hardware
mechanism and firmware.

> You could detect the difference.Right?

Note the firmware is usually in some kind of PROM (sloooow) and also
running uncached.  One reasons of many why the MIPS NMI is only a good
idea for fatal events.

  Ralf