Showing changes from revision #3 to #4:
Added | Removed | Changed
void HAL_IRQClear(int device)
Entry | |
---|---|
device | Device number to clear interrupt state for |
Exit | |
---|---|
- |
This If call the has interrupt a controller dual does purpose: not latch interrupt sources, and theHAL Video API is not implemented, this call does not need to be implemented.
If the interrupt controller does latch interrupt sources, this call must be implemented, to provide a way for those latches to be reset once the device has been serviced. Otherwise the ARM may receive spurious IRQs for devices which are no longer interrupting, or the system may become completely stuck attempting to serve the phantom IRQ.
Because of point 2, this means that all interrupt service routines RISCmust OS code which uses IRQs must make sure to call HAL_IRQClear once they have serviced the interrupting device – the OS will not call it for you. call this routine after servicing the device. Current versions of the kernel will not call HAL_IRQClear for you – it is your responsibility to do so yourself. This is new functionality added for the Cortex/OMAP3 port, to account for the behaviour of the OMAP3 interrupt controller.
If the HAL Video API is implemented, this call is expected to be capable of clearing any VSync IRQ that’s latched in the video controller. Previously, HAL_IRQClear was also responsible for clearing latched timer IRQs, but that responsibility has now fully shifted to HAL_TimerIRQClear (Note, however, that because interrupts may be latched in both the timer and the IRQ controller, timer code must call both entry points to ensure the interrupt state is cleared).