OEMInterruptHandler() is a required kernel function for ARM processors. When an interrupt occurs, the kernel calls OEMInterruptHandler() to determine which interrupt needs to be serviced. OEMInterruptHander() then returns the SYSINTR value associated with the interrupt. OEMInterruptHandler() allows Windows CE to handle interrupts on various CPUs and board designs.
There are many ways to write OEMInterruptHandler(), and the implementation will vary based on the CPU being used. Each CPU potentially implements the interrupt handling differently and therefore the software must be different to handle that. On CPUs like the Marvell PXA255 software determines the priority of the interrupt simply by the order that it looks at the interrupt sources (the first one that it looks at is the highest priority.) The PXA320 changed that by allowing software to set a register that controls many of the interrupt priorities.
The implementation of OEMInterruptHandler() takes the form of:
1.       Decode the interrupt to determine the source of the interrupt
2.       Determine the SYSINTR value associated with the interrupt
3.       Mask of the interrupt
4.       Return the SYSINTR value
Of course the first item is the most complex part of the code. This decoding can be handled in many ways depending the CPU and your creativity. The PXA255 has a register with bits set that indicates the pending interrupts, so the bits need to be examined. The PXA320 has a register with the highest priority pending interrupt number set, so the code can quickly jump to a handler for that interrupt.
Then of course the board may have other information that needs to be decoded. An example might be a programmable device like a CPLD or FPGA that multiplexes multiple interrupt sources and presents them through a single CPU interrupt.
The SYSINTR values can be handled as hardcoded settings, or they can be handled programmatically. That will depend on the needs of your system.
The interrupt usually needs to be masked so that it doesn’t continue to cause interrupts while the driver is processing interrupts. The reason is that while the driver is handling the source of the interrupt, the interrupt handling in the kernel will only slow it down. The interrupt is then re-enabled when the driver calls InterruptDone(). 
Copyright © 2009 – Bruce Eitman
All Rights Reserved