[Top] [All Lists]

Re: EISA support

To: "Andrew R. Baker" <>
Subject: Re: EISA support
From: Ralf Baechle <>
Date: Tue, 3 Aug 1999 00:06:15 +0200
Cc: Linux SGI <>
In-reply-to: <>; from Andrew R. Baker on Mon, Aug 02, 1999 at 08:51:06PM -0500
References: <>
On Mon, Aug 02, 1999 at 08:51:06PM -0500, Andrew R. Baker wrote:

> While working in EISA support for the Indigo2 I have run across some
> interesting design decisions and I would like to get some feedback.
> First is interupt handling.  On the Indigo2 all the EISA interupts and
> mapped down to a single INT2 interrupt.  In other words, an [E]ISA card
> generates an interrupt, which in turn, generates an INT2 interrupt, which
> generates a CPU interrupt.  This causes a problem because current device
> drivers do a "request_irq" call to allocate an interrupt, on the Indy and
> Indigo2, this procedure allocates an INT2/3 irq.  ASFAIK, this means that
> to be supported on the Indigo2, the device driver needs to call something
> else like "request_isa_irq", so that it can be allocated properly.  I see
> two ways of implementing this.  The first is easier to implement, but
> looks slightly grotesque and would involve lines like:
> request_irq(....);
> #else
> request_isa_irq(....);
> #endif
> the other would be to create a "request_isa_irq" procedure that defaults
> to "request_irq" in most architectures.
> Does anyone have any comments or suggestions on this?

The solution which we're using for other systems is to number the
interrupts such that 0 ... 15 are the (E)ISA interrupts; all other
system specific interrupts use higher numbers.  In such a scenario
request_irq() will essentially just be a demultiplexer which for
(E)ISA interrupt numbers calls request_isa_irq() etc.  You really
should try to leave the interrupt numbers unchanged as they are;
basically every (E)ISA interrupt driver has it's numbers hardwired.


<Prev in Thread] Current Thread [Next in Thread>