[Top] [All Lists]

Re: EISA support

To: "William J. Earl" <>
Subject: Re: EISA support
From: "Andrew R. Baker" <>
Date: Tue, 3 Aug 1999 00:41:46 -0500 (CDT)
Cc: Linux SGI <>
In-reply-to: <>

On Mon, 2 Aug 1999, William J. Earl wrote:

> Andrew R. Baker writes:
>  > 
>  > 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:
>  > 
>  > #ifndef CONFIG_SGI_EISA
>  > 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?
>       Suppose you define a range of request_irq() index values which
> correspond to EISA interrupts.  The generic EISA interrupt would always
> be enabled, and the selective masking would apply to various bits in the
> EISA interrupt controller, in much the way that the cascading interrupts
> in INT2 and INT3 are handled.

I hadn't even thought about doing it that way, but after looking at the
existing interupt code, it shouldn't be much of a problem. My biggest
concern is maintaining compatability with the existing drivers. From what
I can tell, they all grab IRQs in the range of 1-15 (the available range
for EISA on x86 machines).  So the best course of action is to shift the
virtual IRQ numbers up to start at 16, and put the EISA irqs on the 0-15
range.  Are there any major things I should consider before doing this?
Are there any arguments against this? 


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