如果我的中断处理程序关中断还是ARM处理器会自动做呢？ [英] Should my interrupt handler disable interrupts or does the ARM processor do it automatically?
问题描述
我们的组使用自定义驱动程序接口4个UART MAX3107共享I2C总线上。四MAX3107的的中断连接（即共享通过逻辑或运算中断））的ARM9处理器（LPC3180模块）上的GPIO引脚。当一个或多个这些设备的中断，它们拉GPIO线，其被配置为电平敏感中断，低。我的问题是，需要，还是不行，禁止在处理程序code中的具体断线。 （我要补充一点，我们运行的是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管脚我们选择）。如果这是真的，那么我们似乎不应该在我们的中断处理程序code要禁用此GPIO引脚中断，因为这样做会显得多余（虽然它似乎工作没关系）。换句话说，在我看来，如果ARM处理器会自动禁用GPIO中断时产生中断发生，那么如果有的话，我们的中断处理程序code应该只需要重新启用，一旦设备被服务的中断。
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.
中断处理程序code，我们使用包括 disable_irq_nosync（irqno）; 在处理程序的开始和一个对应的 enable_irq （）在处理程序结束。如果ARM处理器已经禁用了断线（硬件），什么是这些调用（效果即调用 disable_irq_nosync（）接着调用启用（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被禁止，
$ P $从pventing他们正在处理，直至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）后，它被称为硬件将影响任何东西。由于硬件调用软件调用之前最绝对称得上有机会接手。但是，它可能会更好，从code删除它遵循惯例，而不是混淆的下一个程序员谁在它需要的样子。
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屋！
