关于Linux3.0驱动里面是否需要关中断的探讨

81 阅读 0 评论 54 点赞

我是靠谱客的博主仁爱航空，最近开发中收集的这篇文章主要介绍关于Linux3.0驱动里面是否需要关中断的探讨，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

最近和同事讨论一个问题，Linux3.0驱动里面有没有调用disable_irq_nosync()的必要。有同事说没必要调用该接口，因为在中断产生后中断线会被屏蔽掉；也有同事说必须添加那个接口，因为这种做法已经很成熟了。大家都有自己的观点，但是都拿不出确凿的证据，于是我就花时间研究了下Linux的关中断和开中断。

我们从C代码讲起，汇编部分略过。当外设产生中断时，与之相连的中断控制器上会产生电信号，并通知CPU有中断源产生。此时CPU会停止当前工作，保存当前的环境到CPSR中，然后跳转到预先设置的中断地址。C代码的入口是asm_do_IRQ()（我使用的CPU是ARM架构的，代码路径为arch/arm/kernel/irq.c），然后执行里面的接口handle_IRQ()。

handle_IRQ的代码如下：

void handle_IRQ(unsigned int irq, struct pt_regs *regs) { struct pt_regs *old_regs = set_irq_regs(regs); perf_mon_interrupt_in(); irq_enter(); /* * Some hardware gives randomly wrong interrupts. Rather * than crashing, do something sensible. */ if (unlikely(irq >= nr_irqs)) { if (printk_ratelimit()) printk(KERN_WARNING "Bad IRQ%un", irq); ack_bad_irq(irq); } else { generic_handle_irq(irq); } /* AT91 specific workaround */ irq_finish(irq); irq_exit(); set_irq_regs(old_regs); perf_mon_interrupt_out(); }

首先调用set_irq_regs()将中断现场保存到old_regs里面，然后调用generic_handle_irq()进行正常的中断处理，中断处理完毕后再调用set_irq_regs(old_regs)，恢复到之前的中断现场。

generic_handle_irq_desc调用中断描述符的handle_irq回调函数。对于不同的中断类型，handle_irq回调函数可能是handle_simple_irq、handle_level_irq、handle_fasteoi_irq、handle_edge_irq、handle_edge_eoi_irq、handle_percpu_irq。我们常用的电平触发使用的是handle_level_irq，边沿触发使用的是handle_edge_irq，这里我以电平触发方式为例解释中断处理流程，handle_level_irq()的代码路径为kernel/irq/chip.c。

handle_level_irq的代码如下：

void handle_level_irq(unsigned int irq, struct irq_desc *desc) { raw_spin_lock(&desc->lock); mask_ack_irq(desc); if (unlikely(irqd_irq_inprogress(&desc->irq_data))) if (!irq_check_poll(desc)) goto out_unlock; desc->istate &= ~(IRQS_REPLAY | IRQS_WAITING); kstat_incr_irqs_this_cpu(irq, desc); /* * If its disabled or no action available * keep it masked and get out of here */ if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) goto out_unlock; handle_irq_event(desc); cond_unmask_irq(desc); out_unlock: raw_spin_unlock(&desc->lock); }

首先加自旋锁，然后调用mask_ack_irq(desc)，将产生该中断信号的中断线屏蔽掉，接着判断该中断是否正在处理，如果是则退出，否则继续往下执行。在执行中断处理之前，会判读当前是否被屏蔽或者是否设置了触发方式，如果当前中断已经被关掉了或者没有设置该中断的触发方式，则直接退出，不对中断进行处理。真正的中断处理函数是handle_irq_event()，这个函数一步步的往下调用，最终会调用到注册中断时的中断处理函数。在处理完中断后会调用cond_unmask_irq()取消对该中断线的屏蔽。

至此，中断的处理流程已经清楚了，既然中断产生的时候中断线已经被屏蔽了，那么到底需不需要在驱动里面执行关中断操作呢？

为了验证此问题，我作了一些测试。首先将驱动里面的disable_irq_nosync和enable_irq这个两个接口注释掉，然后将cond_unmask_irq()函数注释掉，编译后发现驱动里面收不到中断，因此断定mask_ack_irq()确实将中断线给屏蔽掉了。接着，我去掉了对cond_unmask_irq()的注释，编译后发现驱动里面有中断进来，但是中断下半部的处理很不稳定，经常被打断，严重影响外设的使用。有兴趣的童鞋可以做以上实验试试。

于是我得到了如下结论：中断产生时，产生该中断的中断线会被屏蔽掉，中断上半部处理完毕后（注意，仅仅是上半部），中断线的屏蔽就会被取消；在屏蔽中断线之后，进入中断处理函数之前，会判断该中断是否被关掉，如果已经关了则跳过，否则执行中断处理，为了不使中断下半部不被频繁的打断，我们需要在驱动的中断处理函数里面添加disable_irq_nosync()接口将中断关掉，在下半部执行完毕后再打开。因此，在驱动里面调用disable_irq_nosync()和enable_irq()是非常有必要的，它能确保驱动有序、稳定的执行。

以上是我的拙见，有不妥之处欢迎大家指出！