Re: Interrupt handling

Hi Andy,

Andy Valencia wrote:
>
> This approach is OK for smaller scale systems. The underlying assumption is
> that interrupt granularity (to wit, masking) matches driver granularity.
> I've worked with a number of embedded systems where there are too many
> devices sharing the same CPU interrupt level. In some of these systems,
> there is a secondary interrupt controller which can mask individual sources.
> But then you're back to the same problem--in the kernel, before you return,
> being able to decode sources. In some cases, you can do this in a general
> way--the secondary interrupt decode logic can be read to determine source.
> In others, you have to go query each specific kind of device to find the
> "culprit". And then you're right back to the problem of device specific
> code needing to run before you can return from kernel mode.

I had another thought about this case too (after I sent the original
note)...

FWIW I know about the sharing problem having supported 8 16550-style
UARTs on a single interrupt line with a fast 8051 last year :-/

Back to the point though... when interrupts are shared, the general
solution must be something like disabling the interrupt channel on the
ICU and then hitting all of device servers attached to the interrupt
source with an interrupt message. The choice must then be to allow the
first of these that finds an interrupt pending to re-enable the channel
on the ICU. If another has a pending interrupt we'd simply re-enter the
ISR when we "iret" and try again (the joys of level triggering :-)).

Now arguably this solution adds some overhead for queuing the interrupt
messages to the device servers, but then again this is already accepted
to a large extent in the design anyway.

Another variant on this theme might hit each server in turn with an
interrupt message and expect the server to reply with an indication of
whether it handled the interrupt or not. If it didn't then the kernel
could hit the next server with the interrupt message; if it did then the
kernel could re-enable the interrupt channel.

Of course one very useful optimization under these circumstances would
be some form of priority queueing of messages (e.g. possibly allowing
the interrupt messages to be made more important than some others).

BTW I thought that the only edge triggered PC interrupts were on the ISA
bus (and even then it generally seems to be the PIC that's doing the
edge triggering - the 4 Ethernet cards I've looked at in the last 2
weeks all hold the interrupt line high until the cause of the interrupt
is either masked within the Ethernet chipset or is ack'd).

                        Regards,
                        Dave
Received on Sun May 28 13:50:21 2000