我们组正在使用自定义驱动程序在共享I2C总线上连接四个MAX3107 uart。四个MAX3107的中断连接(即通过逻辑或'ing共享中断)到ARM9处理器(LPC3180模块)上的GPIO引脚。当这些设备中的一个或多个中断时，它们将配置为电平敏感中断的GPIO线拉低。我的问题涉及是否需要在处理程序代码中禁用特定的中断行。(我应该补充一下，我们运行的是Linux 2.6.10)。
根据我对几个ARM特定应用程序关于中断的说明的阅读，似乎当ARM处理器接收到中断时，它会自动禁用(掩码?)相应的中断线(在我们的情况下，这似乎是与我们选择的GPIO引脚对应的线)。如果这是真的，那么似乎我们不应该在中断处理程序代码中禁用这个GPIO引脚的中断，因为这样做似乎是多余的(尽管它似乎工作得很好)。换句话说，在我看来，如果ARM处理器在中断发生时自动禁用GPIO中断，那么如果有的话，我们的中断处理程序代码应该只在设备被服务后重新启用中断。
我们正在使用的中断处理程序代码包括处理程序最开始的disable_irq_nosync(irqno);和处理程序末尾相应的enable_irq()。如果ARM处理器已经禁用了中断线(在硬件中)，这些调用的效果是什么(即调用disable_irq_nosync()之后调用enable(irq())) ?
来自Arm信息中心文档:
进入异常(中断)时:
中断请求(IRQs)在所有异常情况下被禁用
快速中断请求(FIQ)在FIQ和Reset异常时被禁用。
它接着说:
处理一个FIQ导致irq和随后的FIQ被禁用，防止它们在FIQ处理程序启用之前被处理他们。这通常是通过从节点的SPSR恢复CPSR来完成的处理程序结束。
所以你不必担心禁用它们，但你必须担心重新启用它们。
你需要在例程的末尾包含enable_irq()，但你不需要在开始时禁用任何东西。我不认为在硬件中调用disable_irq_nosync(irqno)后在软件中调用它会产生任何影响。因为硬件调用肯定是在软件调用有机会接管之前被调用的。但是最好将它从代码中删除以遵循约定，而不会使下一个查看它的程序员感到困惑。
更多信息在这里:
军情信息中心