IRQ +and FIQ Dispatchers

The following example code is a simple dispatcher for IRQ interrupts. +It assumes a simplistic interrupt controller that provides 32 interrupt sources, +and has a 32-bit pending-interrupt register where a 'one' bit indicates a +pending interrupt and all ones are cleared when the register is read.

The code assumes that the interrupt source represented by the low order +bit in the pending-interrupt register is represented by interrupt ID number +0 etc.

When implementing the dispatcher it is usual to write it in C++ initially, +but once you have it working you would probably want to rewrite it in assembler +to gain maximum efficiency for what is a time-critical section of code.

Dealing with +chained interrupts

There are two considerations when dealing with chained +interrupts:

how to identify interrupts +on the lower priority chained controllers
how to handle the dispatch +of a chained interrupt.

The first point is a question of allocating locations in your ISR +table for the secondary controllers so that the interrupt ID identifies which hardware controller the interrupt is +on. For example, if each interrupt controller handles 32 interrupt sources, +you could make the first 32 IDs refer to the highest-level controller, the +next 32 refer to one of the second-level controllers etc.

There is +no need to change the Interrupt::Bind() and Interrupt::Unbind() functions, +although you may need to consider extending the Interrupt::Enable() and Interrupt::Disable() functions +to enable and disable the chain interrupt in a higher-level interrupt controller, +if necessary.

There are at least two ways of dispatching a chained +interrupt:

Dispatching a chained interrupt (1)

One +way of dispatching a chained interrupt is simply to make it a special case +in the main interrupt dispatcher. For example:

void IrqDispatch() + { + TUint32 pendingIrqs = TheAssp::IrqPendingRegister(); + + TInt index = 0; + while( pendingIrqs ) + { + if( pendingIrqs & 1 ) + { + if( index == EMainIntChainIrq ) + { + // second-level controller is signalling + SecondLevelIrqDispatch(); + } + else + { + // call ISR + (IsrHandlers[index].iIsr)(IsrHandlers[index].iPtr); + } + } + ++index; + pendingIrqs >>= 1; + } + } +

This approach works for a simple case, for example, where +there is only a main and secondary interrupt controller. It is does not scale +well because the special cases in the dispatcher become an overhead on the +dispatch of normal, unchained interrupts as the number and depth of the chaining +increases.

Dispatching a chained interrupt (2)

A better +way of handling chained interrupts is to bind an ISR to the interrupt source +in the main interrupt controller and use it to dispatch the chained interrupt. +This is far more scalable because you can bind any number of ISRs without +having to add special cases to any of the interrupt dispatchers.

The +dispatcher code could then be re-implemented as:

void IrqDispatch() + // MAIN IRQ DISPATCHER, FIRST-LEVEL INTERRUPT + { + TUint32 pendingIrqs = TheAssp::IrqPendingRegister(); + + TInt index = 0; + while( pendingIrqs ) + { + if( pendingIrqs & 1 ) + { + (IsrHandlers[index].iIsr)(IsrHandlers[index].iPtr); + } + ++index; + pendingIrqs >>= 1; + } + } + void SecondLevelIrqDispatch( TAny* /* aParam */ ) + { + TUint32 pendingIrqs = TheAssp::SecondLevelIrqPendingRegister(); + + TInt index = EStartOfSecondLevelIntId; + while( pendingIrqs ) + { + if( pendingIrqs & 1 ) + { + (IsrHandlers[index].iIsr)(IsrHandlers[index].iPtr); + } + ++index; + pendingIrqs >>= 1; + } + } + void InitialiseSecondLevelDispatch() + // Bind and enable the second-level dispatcher + { + Interrupt::Bind(EMainIntChainIrq,SecondLevelIrqDispatch,NULL); + Interrupt::Enable( EMainIntChainIrq ); + } + +Interrupt sources + +

The second level dispatcher, SecondLevelIrqDispatch(), +is itself an ISR, and takes a TAny * parameter, but is +not needed in this specific example. It reads the interrupt pending register +of the second-level interrupt controller. Note, however, that the TAny * +parameter may be useful when the second level dispatcher is in the variant +as opposed to the ASSP. In that case you have separate interrupt IDs for variant +level interrupts and separate ISR tables. The TAny * parameter +can point to the appropriate ISR table. Alternatively the TAny * +can point to a data block containing IO addresses - especially useful if you +have many I/O devices mapped as hardware chunks. See the code in ...\assabet\specific\variant.cpp.
The index count starts +at offset EStartOfSecondLevelIntId into the ISR table, where +the second-level interrupt ISRs are located. In this example, this symbol +would equate to 32.
EMainIntChainIrq is +the interrupt ID of the chained interrupt source to the main interrupt controller.

Dealing with multiple interrupt sources

The case +where multiple peripherals are connected to the same interrupt source can +be handled through the technique of pseudo interrupt sources. This involves +assigning pseudo-interrupt IDs in the ISR table to correspond to each of the +peripherals that is attached to the interrupt line, i.e. ISRs are bound to +these pseudo-interrupt sources.

Dealing with pseudo interrupt sources +is, in essence, a special case of Chained +interrupts.

The dispatcher can do one of two things:

examine the peripheral +hardware to determine which of the interrupts are pending, and then call the +appropriate ISR
call all the ISRs and +leave them to determine whether their peripheral is actually signalling an +interrupt.

As usual, it is entirely up to you to choose the ID numbers for these +pseudo-interrupts.

There should be no need to alter the implementations +of Interrupt::Bind() or Interrupt::Unbind() but +you will need some special handling in Interrupt::Enable() to +enable the true interrupt source, and Interrupt::Disable() to +disable this interrupt source.

Dispatching the interrupt can be done +in either of the two ways described in dealing with chained interrupts. Making use of a special case in the main interrupt +dispatcher is acceptable for simple cases, but for more complicated cases +with large numbers of pseudo-interrupts or a combination of chained and pseudo-interrupts, +it is better to use an ISR dispatcher bound to the true interrupt source.