Shared Interrupts
Interrupt lines run from a signaling device, through prioritization logic, to a microprocessor. There are a finite number of inputs on the interrupt controllers and as such, lines might be shared. The hardware designer determines this.
When interrupts are shared, all the microprocessor knows is that it was interrupted, but does not necessarily know what interrupted it.
To determine which device caused the interrupt, the operating system's exception handler may need to examine device-specific registers that indicate the state of a given device's interrupt line. The Microsoft® Windows® CE .NET OS provides a mechanism to register routines with the kernel that will be invoked automatically when a shared interrupt occurs. This routine is exposed as an entry point in a DLL that the kernel loads into its NK.exe process. This entry point is called during interrupt processing so it has all of the same restrictions as device power up and power down handlers do. For security reasons, the kernel will not allow the DLL to depend on imports on other DLLs so it cannot link, for example, with Coredll.
Because most devices indicate interrupt activity in a single register, possibly modified by a mask, the sample installable ISR handler, GIISR.dll, is adequate for many devices in practice. If necessary, you can write your own installable ISR handler to implement more complex interrupt detection.
The ISR routine hooked to an interrupt at OEMInit time needs to call NKCallIntChain, a kernel function, to walk a list of installed ISRs for the interrupt that is being signaled. If the first ISR determines that its associated device is asserting the interrupt, it performs any work it needs to and then returns the SYSINTR mapped to the interrupt. Alternatively, the ISR may decide that no further processing by the IST is necessary, in which case it returns SYSINTR_NOP. Otherwise, if the ISR determines that its associated device is not asserting 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 implies priority. The ISR first on the chain has priority over the succeeding ISRs on the chain.
See Also
PCI Device Support | Installable ISRs | Installable ISRs with Drivers | Interrupt Processing Components | Interrupt Notifications | Nested Interrupts | Interrupt Masking | Interrupt Handler Registration | Interrupt Processing | Interrupt Handler Deregistration | Real-Time Priority System
Last updated on Tuesday, May 18, 2004
© 1992-2003 Microsoft Corporation. All rights reserved.