linux驱动request_threaded_irq

内核开始支持中断线程(threaded interrupt handler)，使用接口request_threaded_irq；原来的request_irq也继续支持。使用时可根据实际情况选择合适的接口，可使用request_threaded_irq的地方没必要继续使用request_irq加tasklet/workqueue或者内核线程的方式；如果中断处理简单时也不要执着使用request_threaded_irq。

在linux里，中断处理分为顶半（top half），底半(bottomhalf)，在顶半里处理优先级比较高的事情，要求占用中断时间尽量的短，在处理完成后，就激活底半，有底半处理其余任务。底半的处理方式主要有soft_irq,tasklet,workqueue三种，他们在使用方式和适用情况上各有不同。soft_irq用在对底半执行时间要求比较紧急或者非常重要的场合，主要为一些subsystem用，一般driver基本上用不上。tasklet和work queue在普通的driver里用的相对较多，主要区别是tasklet是在中断上下文执行,而workqueue是在process上下文，因此可以执行可能sleep的操作。

2.6.30里，在ingo molnar的RT tree里存在有一段时间的interruptthread终于merge到mainline了。此时如果使用request_threaded_irq申请的中断，handler不是在中断上下文里执行，而是在新创建的线程里执行，这样，该handler非常像执行workqueue，拥有所有workqueue的特性，但是省掉了创建,初始化，调度workqueue的繁多步骤。处理起来非常简单。让我们看看这个接口。

int request_threaded_irq(unsigned int irq, irq_handler_t handler, irq_handler_t thread_fn,
                         unsigned long irqflags, const char *devname, void *dev_id)

和request_irq非常类似，irq是中断号， handler是在发生中断时，首先要执行的code，非常类似于顶半，该函数最后会return IRQ_WAKE_THREAD来唤醒中断线程，
一般设为NULL，用系统提供的默认处理。thread_fn，是要在线程里执行的handler，非常类似于底半。 后三个参数基本和request_irq相同。irqsflags新增加了一
个标志，IRQF_ONESHOT，用来标明是在中断线程执行完后在打开该中断，该标志非常有用，否则中断有可能一直在顶半执行，而不能处理中断线程。例如对于
gpio level中断，如果不设置该位，在顶半执行完成后，会打开中断，此时由于电平没有变化，马上有执行中断，永远没有机会处理线程。

下边一个实际例子来说明它的应用。在手机平台中，检测耳机的插入一般是通过耳机插孔中机械变化导致一个baseband gpio的电平的变化，
在该gpio中断里进行耳机插入处理。但是耳机插入一般都有个抖动的过程，需要消抖处理。最简单的办法是在中断发生后，延时一段时间（例如200ms），然后再检
查GPIO状态是否稳定来确定是否有效插入。如果用老的中断方式，不得不用workqueue的方式，你需要在顶半里激活一个delay 200ms的workqueue，然后在workqueue
里检查。用线程化的处理方式，你仅仅需要在thread_fn里sleep 200ms，然后在检查即可。看，事情就这么简单！

 

 

函数 request_threaded_irq( ) 首先对传入的参数进行 正确性 检查，根据传入的 irq 号获得数组 irq_desc 中以 irq 为下标的元素，然后动态的创建一个 irqaction 描述符，根据传入的参数初始化新生成的 irqaction 描述符，最后调用函数 __setup_irq(   ) 把该描述符加入到 IRQ 链表中 ，完成中断的动态申请及注册 。

如果返回值是0则说明申请成功，如果申请不成功，则返回的值非零，一般为负数，可能的取值-16、-38。例如，如果返回值是-16，则说明申请的中断号在内核中已被占用。

附注：此函数申请一个中断处理函数（若赋值为NULL，则使用默认的）和线程，当中断发生时，中断处理函数运行于中断上下文，判断是否是自己所属的中断，若是则关闭自身中断并返回IRQ_WAKE_THREAD来唤醒线程函数的执行。在线程执行中，可以睡眠，执行后返回IRQ_HANDLE