我们的小组使用定制驱动程序在共享 I2C 总线上连接四个 MAX3107 UART。四个 MAX3107 的中断连接（即通过逻辑或运算共享中断））到 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 信息中心文档：
进入异常（中断）时：
然后它接着说：
处理 FIQ 会导致 IRQ 和后续 FIQ 被禁用，
在 FIQ 处理程序启用之前阻止它们被处理
他们。这通常是通过从 SPSR 恢复 CPSR 来完成的。
处理程序结束。
因此，您不必担心禁用它们，但您必须担心重新启用它们。
您需要在例程末尾包含enable_irq()，但不需要在开始时禁用任何内容。我不认为在硬件中调用disable_irq_nosync(irqno)后在软件中调用它不会产生任何影响。由于硬件调用肯定是在软件调用有机会接管之前调用的。但最好将其从代码中删除以遵循约定，并且不要让下一个查看它的程序员感到困惑。
更多信息请点击这里：
Arm 信息中心 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/BABGCFHB.html
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
