|
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
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,
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:ralf@linux-mips.org]
Sent: Tuesday, November 11, 2003 11:40 AM
To: Liu Hongming (Alan)
Cc: Adeel Malik;
linux-mips@linux-mips.org
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
| 