我的中断处理程序应该禁用中断还是 ARM 处理器自动执行? [英] Should my interrupt handler disable interrupts or does the ARM processor do it automatically?
问题描述
我们的小组正在使用自定义驱动程序来连接共享 I2C 总线上的四个 MAX3107 UART.四个 MAX3107 的中断连接(即通过逻辑或'ing 共享中断)到 ARM9 处理器(LPC3180 模块)上的 GPIO 引脚.当这些设备中的一个或多个中断时，它们会将配置为电平敏感中断的 GPIO 线拉低.我的问题涉及是否需要禁用处理程序代码中的特定中断线.(我应该补充一点，我们正在运行 Linux 2.6.10).
Our group is using a custom driver to interface four MAX3107 UARTs on a shared I2C bus. The interrupts of the four MAX3107's are connected (i.e. shared interrupt via logic or'ing)) to a GPIO pin on the ARM9 processor (LPC3180 module). When one or more of these devices interrupt, they pull the GPIO line, which is configured as a level-sensitive interrupt, low. My question concerns the need, or not, to disable the specific interrupt line in the handler code. (I should add that we are running Linux 2.6.10).
根据我对中断的几个 ARM 特定应用笔记的阅读，似乎当 ARM 处理器收到中断时，它会自动禁用(屏蔽?)相应的中断线(在我们的例子中这似乎是线对应于我们选择的 GPIO 引脚).如果这是真的，那么我们似乎不必在我们的中断处理程序代码中禁用此 GPIO 引脚的中断，因为这样做似乎是多余的(尽管它似乎工作正常).换句话说，在我看来，如果 ARM 处理器在发生中断时自动禁用 GPIO 中断，那么如果有的话，我们的中断处理程序代码应该只需要在设备得到服务后重新启用中断.
Based on my reading of several ARM-specific app notes 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 the line corresponding to the GPIO pin we selected). If this is true, then it seems that we should not have to disable interrupts for this GPIO pin in our interrupt handler code as doing so would seem redundant (though it seems to work okay). Stated differently, it seems to me that if the ARM processor automatically disables the GPIO interrupt upon an interrupt occurring, then if anything, our interrupt handler code should only have to re-enable the interrupt once the device is serviced.
我们使用的中断处理程序代码包括处理程序开头的disable_irq_nosync(irqno);和处理程序末尾的相应enable_irq().如果 ARM 处理器已经禁用了中断线(在硬件中)，这些调用的效果是什么(即调用 disable_irq_nosync() 然后调用 enable(irq())?
The interrupt handler code that we are using includes disable_irq_nosync(irqno); at the very beginning of the handler and a 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. a call to disable_irq_nosync() followed by a call to enable(irq())?
推荐答案
来自 Arm 信息中心文档:
From the Arm Information Center Documentation:
进入异常(中断):
针对所有异常禁用中断请求 (IRQ)
interrupt requests (IRQs) are disabled for all exceptions
针对 FIQ 和重置异常禁用快速中断请求 (FIQ).
fast interrupt requests (FIQs) are disabled for FIQ and Reset exceptions.
接着说:
处理 FIQ 会导致 IRQ 和后续 FIQ 被禁用，在 FIQ 处理程序启用之前阻止它们被处理他们.这通常是通过从 SPSR 恢复 CPSR 来完成的.处理程序结束.
Handling an FIQ causes IRQs and subsequent FIQs to be disabled, preventing them from being handled until after the FIQ handler enables them. This is usually done by restoring the CPSR from the SPSR at the end of the handler.
因此您不必担心禁用它们，但您必须担心重新启用它们.
So you do not have to worry about disabling them, but you do have to worry about re-enabling them.
您需要在例程结束时包含 enable_irq()，但您不需要在开始时禁用任何内容.我不认为在硬件中调用 disable_irq_nosync(irqno) 后在软件中调用它会影响任何事情.由于硬件调用在软件调用有机会接管之前绝对被调用.但是最好将它从代码中删除以遵循约定，而不是让下一位查看它的程序员感到困惑.
You will need to include enable_irq() at the end of your routine, but you shouldn't need to disable anything at the beginning. I wouldn't think that calling disable_irq_nosync(irqno) in software after it has been called in hardware would effect anything. Since the hardware call is most definitely called before the software call has a chance to take over. But it's probably better to remove it from the code to follow convention and not confuse the next programmer who takes a look at it.
更多信息在这里:
这篇关于我的中断处理程序应该禁用中断还是 ARM 处理器自动执行?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
