Development Plan Proposal for Unifying Interrupt and PCI APIs

gregory.menke at gsfc.nasa.gov gregory.menke at gsfc.nasa.gov
Sun Oct 24 03:48:16 UTC 2004


I think RTEMS must support shared interrupts.  Not that all interrupt
systems should or must be shared, but some bsp's and hardware will
require it.  I think its also possible to implement a solution thats
far too clever for the problem.  If you have a shared interrupt being
asserted its because one or more hardware devices are driving the
shared interrupt line.  All drivers on the interrupt must be called,
regardless of order or if each one's hardware is asserting or not.  In
some cases it might be possible to detect when the last interrupt
cause is serviced, so the handler traverse could be stopped early- but
detecting this case isn't going to save much overhead.

One reasonable and simple approach is to keep a linked list of handlers
for each vector.  When the interrupt shows up, the handlers are called
in order.  Each handler performs a quick check of its hardware.  If
its asserting, the interrupt is serviced and the handler chain
iteration continues.  If a handler finds its hardware is not
asserting, it returns right away, and the chain iteration continues.

The upshot is multiple interrupt sources can be simultaneously
asserting interrupts, so prioritizing the handlers isn't going to buy
you much beyond mitigating worst-case interrupt latency because the
chain of handlers is always fully traversed.  I think its worth
considering how a more definite handler priority scheme might work,
right now the powerpc_shared bsp chains handlers on each vector in
fifo order.

Gregm





More information about the users mailing list