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.