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

From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 11:56:34 +0000 (GMT) Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:47575 "EHLO 1aurora.enabtech") by linux-mips.org with ESMTP id ; Tue, 4 Nov 2003 11:56:22 +0000 Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Nov 2003 16:56:09 +0500 Message-ID: <10C6C1971DA00C4BB87AC0206E3CA38264F542@1aurora.enabtech> From: Adeel Malik To: linux-mips@linux-mips.org Subject: How to request an IRQ for NMI on MIPS Processor Date: Tue, 4 Nov 2003 16:56:08 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A2CA.A25A8C70" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 3582 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: AdeelM@quartics.com Precedence: bulk X-list: linux-mips This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3A2CA.A25A8C70 Content-Type: text/plain; charset="iso-8859-1" Hi All, 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 ?. Regards, ADEEL MALIK, ------_=_NextPart_001_01C3A2CA.A25A8C70 Content-Type: text/html; charset="iso-8859-1"

Hi All,

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

Regards,

ADEEL MALIK,

------_=_NextPart_001_01C3A2CA.A25A8C70-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 12:30:48 +0000 (GMT) Received: from p508B62C3.dip.t-dialin.net ([IPv6:::ffff:80.139.98.195]:45955 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 4 Nov 2003 12:30:37 +0000 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id hA4CUZsY004802; Tue, 4 Nov 2003 13:30:35 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hA4CUYrH004801; Tue, 4 Nov 2003 13:30:34 +0100 Date: Tue, 4 Nov 2003 13:30:34 +0100 From: Ralf Baechle To: Adeel Malik Cc: linux-mips@linux-mips.org Subject: Re: How to request an IRQ for NMI on MIPS Processor Message-ID: <20031104123034.GA4048@linux-mips.org> References: <10C6C1971DA00C4BB87AC0206E3CA38264F542@1aurora.enabtech> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10C6C1971DA00C4BB87AC0206E3CA38264F542@1aurora.enabtech> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 3583 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips 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 mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 12:58:54 +0000 (GMT) Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:28377 "EHLO 1aurora.enabtech") by linux-mips.org with ESMTP id ; Tue, 4 Nov 2003 12:58:42 +0000 Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Nov 2003 17:58:32 +0500 Message-ID: <10C6C1971DA00C4BB87AC0206E3CA38264F543@1aurora.enabtech> From: Adeel Malik To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: RE: How to request an IRQ for NMI on MIPS Processor Date: Tue, 4 Nov 2003 17:58:32 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 3584 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: AdeelM@quartics.com Precedence: bulk X-list: linux-mips 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: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Ralf Baechle Sent: Tuesday, November 04, 2003 5:31 PM To: Adeel Malik Cc: linux-mips@linux-mips.org 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 mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 04 Nov 2003 13:28:14 +0000 (GMT) Received: from p508B62C3.dip.t-dialin.net ([IPv6:::ffff:80.139.98.195]:135 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 4 Nov 2003 13:28:02 +0000 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id hA4DS1sY005961; Tue, 4 Nov 2003 14:28:01 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hA4DS1Mr005960; Tue, 4 Nov 2003 14:28:01 +0100 Date: Tue, 4 Nov 2003 14:28:01 +0100 From: Ralf Baechle To: Adeel Malik Cc: linux-mips@linux-mips.org Subject: Re: How to request an IRQ for NMI on MIPS Processor Message-ID: <20031104132801.GA5297@linux-mips.org> References: <10C6C1971DA00C4BB87AC0206E3CA38264F543@1aurora.enabtech> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10C6C1971DA00C4BB87AC0206E3CA38264F543@1aurora.enabtech> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 3585 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips 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. Ralf From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Nov 2003 02:59:48 +0000 (GMT) Received: from [IPv6:::ffff:202.96.215.33] ([IPv6:::ffff:202.96.215.33]:5903 "EHLO tmtms.trident.com.cn") by linux-mips.org with ESMTP id ; Tue, 11 Nov 2003 02:59:37 +0000 Received: by TMTMS with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 10:52:29 +0800 Message-ID: <15F9E1AE3207D6119CEA00D0B7DD5F6801C99461@TMTMS> From: "Liu Hongming (Alan)" To: Adeel Malik , linux-mips@linux-mips.org Subject: RE: How to request an IRQ for NMI on MIPS Processor Date: Tue, 11 Nov 2003 10:51:50 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A7FE.C148C790" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 3595 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alanliu@trident.com.cn Precedence: bulk X-list: linux-mips This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3A7FE.C148C790 Content-Type: text/plain; charset="ISO-8859-1" hi Malik, 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. Regards, Alan Liu -----Original Message----- From: Adeel Malik [mailto:AdeelM@quartics.com] Sent: Tuesday, November 04, 2003 7:56 PM To: linux-mips@linux-mips.org Subject: How to request an IRQ for NMI on MIPS Processor Hi All, 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 ?. Regards, ADEEL MALIK, ------_=_NextPart_001_01C3A7FE.C148C790 Content-Type: text/html; charset="ISO-8859-1"

hi Malik,

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.

Regards,

Alan Liu

-----Original Message-----
From: Adeel Malik [mailto:AdeelM@quartics.com]
Sent: Tuesday, November 04, 2003 7:56 PM
To: linux-mips@linux-mips.org
Subject: How to request an IRQ for NMI on MIPS Processor

Hi All,

Regards,

ADEEL MALIK,

------_=_NextPart_001_01C3A7FE.C148C790-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Nov 2003 03:40:42 +0000 (GMT) Received: from p508B68E7.dip.t-dialin.net ([IPv6:::ffff:80.139.104.231]:743 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 11 Nov 2003 03:40:30 +0000 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAB3eJsY023467; Tue, 11 Nov 2003 04:40:19 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAB3eCT0023466; Tue, 11 Nov 2003 04:40:12 +0100 Date: Tue, 11 Nov 2003 04:40:12 +0100 From: Ralf Baechle To: "Liu Hongming (Alan)" Cc: Adeel Malik , linux-mips@linux-mips.org Subject: Re: How to request an IRQ for NMI on MIPS Processor Message-ID: <20031111034012.GA23100@linux-mips.org> References: <15F9E1AE3207D6119CEA00D0B7DD5F6801C99461@TMTMS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15F9E1AE3207D6119CEA00D0B7DD5F6801C99461@TMTMS> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 3596 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips 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 mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Nov 2003 04:47:04 +0000 (GMT) Received: from [IPv6:::ffff:202.96.215.33] ([IPv6:::ffff:202.96.215.33]:40964 "EHLO tmtms.trident.com.cn") by linux-mips.org with ESMTP id ; Tue, 11 Nov 2003 04:46:52 +0000 Received: by TMTMS with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 12:39:48 +0800 Message-ID: <15F9E1AE3207D6119CEA00D0B7DD5F6801C99492@TMTMS> From: "Liu Hongming (Alan)" To: Ralf Baechle , "Liu Hongming (Alan)" Cc: Adeel Malik , linux-mips@linux-mips.org Subject: RE: How to request an IRQ for NMI on MIPS Processor Date: Tue, 11 Nov 2003 12:39:04 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A80D.BC891ED0" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 3597 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alanliu@trident.com.cn Precedence: bulk X-list: linux-mips This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3A80D.BC891ED0 Content-Type: text/plain; charset="ISO-8859-1" 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 ------_=_NextPart_001_01C3A80D.BC891ED0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable 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: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:
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;
- 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.
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;
It seems pretty clear to me that the MIPS designers = never intended the
NMI for anything else than catastrophic = events.

Ralf

------_=_NextPart_001_01C3A80D.BC891ED0-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Nov 2003 05:22:48 +0000 (GMT) Received: from [IPv6:::ffff:203.82.55.162] ([IPv6:::ffff:203.82.55.162]:3552 "EHLO 1aurora.enabtech") by linux-mips.org with ESMTP id ; Tue, 11 Nov 2003 05:22:36 +0000 Received: by 1aurora.enabtech with Internet Mail Service (5.5.2650.21) id ; Tue, 11 Nov 2003 10:21:56 +0500 Message-ID: <10C6C1971DA00C4BB87AC0206E3CA38264F662@1aurora.enabtech> From: Adeel Malik To: "Liu Hongming (Alan)" Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: RE: How to request an IRQ for NMI on MIPS Processor Date: Tue, 11 Nov 2003 10:21:52 +0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A813.B8F095B0" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 3598 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: AdeelM@quartics.com Precedence: bulk X-list: linux-mips This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3A813.B8F095B0 Content-Type: text/plain; charset="iso-8859-1" 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: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Liu Hongming (Alan) Sent: Tuesday, November 11, 2003 9:39 AM To: Ralf Baechle; Liu Hongming (Alan) Cc: Adeel Malik; linux-mips@linux-mips.org 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: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 ------_=_NextPart_001_01C3A813.B8F095B0 Content-Type: text/html; charset="iso-8859-1" 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: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Liu Hongming (Alan)
Sent: Tuesday, November 11, 2003 9:39 AM
To: Ralf Baechle; Liu Hongming (Alan)
Cc: Adeel Malik; linux-mips@linux-mips.org
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: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

------_=_NextPart_001_01C3A813.B8F095B0-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Nov 2003 05:35:03 +0000 (GMT) Received: from [IPv6:::ffff:202.96.215.33] ([IPv6:::ffff:202.96.215.33]:60936 "EHLO tmtms.trident.com.cn") by linux-mips.org with ESMTP id ; Tue, 11 Nov 2003 05:34:51 +0000 Received: by TMTMS with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 13:27:48 +0800 Message-ID: <15F9E1AE3207D6119CEA00D0B7DD5F6801C9949F@TMTMS> From: "Liu Hongming (Alan)" To: Adeel Malik , "Liu Hongming (Alan)" Cc: Ralf Baechle , linux-mips@linux-mips.org Subject: RE: How to request an IRQ for NMI on MIPS Processor Date: Tue, 11 Nov 2003 13:26:53 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A814.6A4B7C10" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 3599 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alanliu@trident.com.cn Precedence: bulk X-list: linux-mips This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3A814.6A4B7C10 Content-Type: text/plain; charset="ISO-8859-1" 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:AdeelM@quartics.com] Sent: Tuesday, November 11, 2003 1:22 PM To: Liu Hongming (Alan) Cc: Ralf Baechle; linux-mips@linux-mips.org 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: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Liu Hongming (Alan) Sent: Tuesday, November 11, 2003 9:39 AM To: Ralf Baechle; Liu Hongming (Alan) Cc: Adeel Malik; linux-mips@linux-mips.org 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: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 ------_=_NextPart_001_01C3A814.6A4B7C10 Content-Type: text/html; charset="ISO-8859-1" RE: How to request an IRQ for NMI on MIPS Processor

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:AdeelM@quartics.com]
Sent: Tuesday, November 11, 2003 1:22 PM
To: Liu Hongming (Alan)
Cc: Ralf Baechle; linux-mips@linux-mips.org
Subject: RE: How to request an IRQ for NMI on MIPS Processor

Liu,

Secondly, Linux Kernel especially the Embedded Linux Versions for various Processors doesn't support the use of NMI as a regular IRQ.

Thatswhy we don't find much code related to NMIs in Linux.

ADEEL MALIK,

-----Original Message-----
From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Liu Hongming (Alan)
Sent: Tuesday, November 11, 2003 9:39 AM
To: Ralf Baechle; Liu Hongming (Alan)
Cc: Adeel Malik; linux-mips@linux-mips.org
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: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

------_=_NextPart_001_01C3A814.6A4B7C10-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 11 Nov 2003 05:45:43 +0000 (GMT) Received: from p508B68E7.dip.t-dialin.net ([IPv6:::ffff:80.139.104.231]:7296 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 11 Nov 2003 05:45:32 +0000 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by dea.linux-mips.net (8.12.8/8.12.8) with ESMTP id hAB5jVJH026396; Tue, 11 Nov 2003 06:45:31 +0100 Received: (from ralf@localhost) by dea.linux-mips.net (8.12.8/8.12.8/Submit) id hAB5jTA6026395; Tue, 11 Nov 2003 06:45:29 +0100 Date: Tue, 11 Nov 2003 06:45:29 +0100 From: Ralf Baechle To: "Liu Hongming (Alan)" Cc: Adeel Malik , linux-mips@linux-mips.org Subject: Re: How to request an IRQ for NMI on MIPS Processor Message-ID: <20031111054529.GA26238@linux-mips.org> References: <15F9E1AE3207D6119CEA00D0B7DD5F6801C9949F@TMTMS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15F9E1AE3207D6119CEA00D0B7DD5F6801C9949F@TMTMS> User-Agent: Mutt/1.4.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 3600 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Nov 11, 2003 at 01:26:53PM +0800, Liu Hongming (Alan) wrote: > I have understood your situation. > > 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. > 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? 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