Handle Shared Interrupts (Compact 2013)
3/26/2014
On some hardware platforms, multiple devices might share a single interrupt request line. Sharing is necessary because hardware platforms have a finite number of inputs. When interrupts are shared, the microprocessor is aware of an interruption, but it is not necessarily aware of which device interrupted it. To determine this, the OS exception handler must typically examine device-specific registers that indicate the state of a specified device interrupt line.
You can register routines with the kernel that are automatically invoked when a shared interrupt occurs. The interrupt service routine (ISR) that you hook to an interrupt in OEMInit must call NKCallIntChain, which is a kernel function, to examine a list of installed ISRs for the interrupt that has been signaled.
The following sequence of steps describes how the OS handles shared interrupts:
- Your ISR routine calls NKCallIntChain to examine a list of installed ISRs for the interrupt that a device has signaled.
- If the first ISR in the list determines that its associated device has asserted the interrupt, it performs any necessary work and then returns the SYSINTR that is mapped to the interrupt. If this ISR determines that it is not necessary for the interrupt service thread (IST) to do additional processing, it returns SYSINTR_NOP.
- If the first ISR in the list determines that its associated device has not asserted the interrupt, it returns SYSINTR_CHAIN, which causes NKCallIntChain to call the next ISR in the chain.
The order of installing ISRs is important because it sets priority. The first ISR on the chain has priority over the succeeding ISRs on the chain. For more information about handling shared interrupts, see NKCallIntChain.