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:
>
> #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?
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.
Ralf
|