Service Interrupts (Compact 2013)
3/26/2014
The following figure shows how the interrupt handling components interact with each other and the device hardware during interrupt processing. Note that you implement only some of the components that are shown in this diagram: you typically provide the device driver interrupt service routine (ISR), platform dependent driver (PDD) lower-layer routines, and OAL routines, and Microsoft provides the kernel exception and interrupt handling functionality in addition to a model device driver (MDD) library that includes the device driver interrupt service thread (IST).
.png "Interrupt Handling Components")
When an interrupt occurs, interrupt handling typically occurs in the following sequence, although the details can vary depending on the CPU architecture:
- When your device generates an interrupt, the microprocessor jumps to the kernel exception handler.
- The exception handler disables all interrupts of an equal or lower priority at the microprocessor and then calls the appropriate ISR for that interrupt request (IRQ). If this IRQ is associated with your device, the exception handler calls your driver ISR.
- Your ISR services the interrupt. Typically, your ISR also masks the board-level device interrupt so that the OS does not respond to the interrupt signal from your device during interrupt processing.
- After servicing the interrupt, your ISR returns a logical interrupt identifier to the kernel interrupt handler.
- The kernel interrupt handler receives the return value from your ISR, reenables all interrupts at the microprocessor except for the current interrupt (which remains masked at the board), and then signals the appropriate IST event.
- The OS schedules the IST.
- When the IST wakes, it works to complete the interrupt processing by calling various lower-level driver routines to access the hardware. This process could include moving data into a device buffer or interpreting status data from the device.
- When the IST completes interrupt processing, it calls the InterruptDone function, which in turn calls the OEMInterruptDone function in the OAL.
- OEMInterruptDone reenables (unmasks) the current interrupt.
As described in step 4, your ISR services the device interrupt and translates the interrupt into a SYSINTR. It then passes this logical identifier to the kernel as its return value. Your ISR returns one of the return codes listed in the following table to notify the kernel how to handle the interrupt.
ISR return code |
Description |
|---|---|
SYSINTR_NOP |
The kernel does nothing. |
SYSXINTR_XXX |
The kernel schedules interrupt processing so that the IST wakes and does its work. XXX specifies the logical interrupt value for the specific interrupt source. |
SYSINTR_RESCHED |
The kernel reschedules the IST. |
Each IRQ is associated with an ISR, and an ISR can respond to multiple IRQ sources. When interrupts are enabled and an interrupt occurs, the kernel calls the registered ISR for that interrupt. When finished, the ISR returns an interrupt identifier. The kernel examines the returned interrupt identifier and sets the associated event. When the kernel sets the event, the IST starts processing.