深入分析request_irq的dev_id参数作用 转
Author : Dongas
Data : 08-07-12
注：若对kernel中断处理模型不是很清楚的话(如:irqaction的作用)可以先参考一下这篇文档：
http://blog.chinaunix.net/u2/60011/showart.php?id=1079281
这里主要讲request_irq的参数dev_id的作用，内容会涉及到少许上面文档提到的内容。
Request_irq的作用是申请使用IRQ并注册中断处理程序。
request_irq（）函数的原型如下：
|
|
我们知道，当使用内核共享中断时，request_irq必须要提供dev_id参数，并且dev_id的值必须唯一。那么这里提供唯一的dev_id值的究竟是做什么用的？
起先我以为dev_id的值是提供给kernel进行判断共享中断线上的哪一个设备产生了中断（即哪个irqaction产生中断）,然后执行相应的中断处理函数(irqaction->handler)。实际上不是的，我们来看看《Linux Kernel Development – Second Edition》第六章中Shared Handlers这一节,其中有段总结性的文字如下：
When the kernel receives an interrupt, it invokes sequentially each registered handler on the line. Therefore, it is important that the handler be capable of distinguishing whether it generated a given interrupt. The handler must quickly exit if its associated device did not generate the interrupt. This requires the hardware device to have a status register (or similar mechanism) that the handler can check. Most hardware does indeed have such a feature.
这段话的大概意思是，发生中断时，内核并不判断究竟是共享中断线上的哪个设备产生了中断，它会循环执行所有该中断线上注册的中断处理函数（即irqaction->handler函数）。因此irqaction->handler函数有责任识别出是否是自己的硬件设备产生了中断，然后再执行该中断处理函数。通常是通过读取该硬件设备提供的中断flag标志位进行判断。
那既然kernel循环执行该中断线上注册的所有irqaction->handler函数，把识别究竟是哪个硬件设备产生了中断这件事交给中断处理函数本身去做，那request_irq的dev_id参数究竟是做什么用的？
我总结了一下，实际上dev_id作用主要有两点：
一．在中断处理程序释放时使用到dev_id
When your driver unloads, you need to unregister your interrupt handler and potentially disable the interrupt line. To do this, call
void free_irq(unsigned int irq, void *dev_id)
……
The fifth parameter, dev_id, is used primarily for shared interrupt lines. When an interrupt handler is freed (discussed later), dev_id provides a unique cookie to allow the removal of only the desired interrupt handler from the interrupt line. Without this parameter, it would be impossible for the kernel to know which handler to remove on a given interrupt line.
这里《LKD2》讲了很清楚，当调用free_irq注销中断处理函数时（通常卸载驱动时其中断处理函数也会被注销掉）,因为dev_id是唯一的，所以可以通过它来判断从共享中断线上的多个中断处理程序中删除指定的一个。如果没有这个参数，那么kernel不可能知道给定的中断线上到底要删除哪一个处理程序。
下面我们来看一下free_irq的代码：
|
|
二．将使用该中断处理程序的设备结构体传递给该中断处理程序
首先看两个基础条件：
1) 内核中的各个设备结构体肯定是唯一的，因此满足dev_id唯一这个要求
2) dev_id参数会在发生中断时传递给该中断的服务程序。
典型的中断服务程序定义如下：
static irqreturn_t intr_handler(int irq, void *dev_id, struct pt_regs *regs);
即request_irq的dev_id参数会传递给该中断服务程序的dev_id。因此也可以将驱动程序的设备结构体通过dev_id传递给中断服务程序。
这样做作用主要有两个：
1) 中断服务程序可能使用到设备结构体中的信息
如s3c2410的iis音频驱动,它是将DMA Channel结构体通过dev_id传递给中断服务程序
|
|
目的是中断处理函数s3c2410_dma_irq内需要用到chan结构体的duf成员和load_state成员等。
使用方法如下：
|
|
因此，我们可以通过将设备结构传递给request_irq的dev_id参数这种机制，在中断处理函数中使用该设备结构体，这是大部分驱动程序通用的一种手法。
2）前面我们讲了若使用共享中断，那么中断处理函数自身需要能识别是否是自己的设备产
生了中断。通常这是通过读取该硬件设备提供的中断flag标志位进行判断的。
而往往驱动程序里定义的设备结构体通常包含了该设备的IO地址,加上偏移就可以算出中断状态寄存器及中断flag标志位的IO地址信息。因此将设备结构体通过dev_id传递给设备中断处理程序的另一个作用就是使用共享中断时，可以在中断处理函数内通过读取该设备结构 (dev_id) 中提供的中断Flag标志位地址信息进行判断，是否是该设备产生了中断，然后再进一步判断是否继续往下执行还是跳到下一个irqaction->handler函数再判断执行。当然，如果本来就知道该设备中断状态寄存器的IO地址，也可以选择直接readl该地址信息进行判断。