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
> 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.