Should my interrupt handler disable interrupts or will the ARM processor do this automatically?

Question

Our group uses a special driver for the interface of the four MAX3107 UART controllers on the I2C common bus. The interrupts of the four MAX3107s are connected (that is, together with the interrupt via logic or)) to the GPIO output on the ARM9 processor (LPC3180 module). When one or more of these devices is interrupted, they draw the GPIO line, which is configured as a level-sensitive interrupt, low. My question is whether or not it is necessary to disable a specific interrupt line in the handler code. (I have to add that we are running Linux 2.6.10).

Based on my reading of a few notes on ARM-related applications on interrupts, it seems that when the ARM processor receives an interrupt, it automatically disables (masks?) The corresponding interrupt line (in our case, this would seem to be a line corresponding to the GPIO output, which we chose). If this is the case, then it seems that we do not need to disable interrupts for this GPIO output in our interrupt handler code, as this may seem redundant (although this seems to work fine). In other words, it seems to me that if the ARM processor automatically disables the GPIO interrupt when an interrupt occurs, then, if anything, our interrupt handler code should only restart the interrupt after servicing the device.

The interrupt handler code we use includes disable_irq_nosync(irqno); at the very beginning of the handler and the corresponding enable_irq() at the end of the handler. If the ARM processor has already disabled the interrupt line (in hardware), what is the effect of these calls (i.e., the disable_irq_nosync() call, followed by the enable(irq()) call?

Answer 1

From the document of the weapon information center:

When entering an exception (interrupt):

• interrupt requests (IRQs) are disabled for all exceptions

• fast interrupt requests (FIQ) are disabled for FIQ and Reset exceptions.

Followed by:

FIQ processing disables IRQs and subsequent FIQs, preventing them from being processed until the FIQ handler turns them on. This is usually done by restoring the CPSR from the SPSR to the end of the handler.

Therefore, you do not need to worry about disabling them, but you need to worry about re-enabling them.

You will need to enable enable_irq () at the end of your subroutine, but first you do not need to disable anything. I would not have thought that calling disable_irq_nosync (irqno) in the software after it was called by the hardware will affect everything. Because a hardware call is most definitely called before the software can take control. But it's probably best to remove it from the code to follow the convention, rather than confuse the next programmer who is looking at it.

More details here:

Weapons Information Center