[Top] [All Lists]

Re: EISA support

To: "Andrew R. Baker" <>
Subject: Re: EISA support
From: "William J. Earl" <>
Date: Mon, 2 Aug 1999 15:44:10 -0700 (PDT)
Cc: "William J. Earl" <>, Linux SGI <>
In-reply-to: <>
References: <> <>
Andrew R. Baker writes:
 > On Mon, 2 Aug 1999, William J. Earl wrote:
 > >       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? 

       I see that some drivers use NR_IRQS to form an IRQ_ports[] array,
to map from IRQ to board object, as in serial.c, whereas others, such as
riscom8.c, wire in 16 as the limit.   Still, you could make
probe_irq_on() and probe_irq_off() actually work for an Indy and Indigo2,
and simply declare broken any drives which do not use NR_IRQS and probe
using the probe_irq_* routines.  The biggest problem with that approach
is that NR_IRQS is 64 on mips, which means that probe_irq_on() and 
would need a different interface (long long instead of int, to allow 64-bit
IRQ bit maps on 32-bit kernel).  

      Changing the MIPS symbolic IRQ mapping to put EISA in the bottom
16 slots is probably the course of least resistance.

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