分类: LINUX
2009-10-11 16:46:09
Kernel中断处理模型结构图如下:
下面简单介绍一下:
1. Linux定义了名字为irq_desc的中断例程描述符表:(include/linux/irq.h)
struct irqdesc irq_desc[NR_IRQS];
NR_IRQS表示中断源的数目。
2. irq_desc[]是一个指向irq_desc_t结构的数组, irq_desc_t结构是各个设备中断服务例程的描述符。Irq_desc_t结构体中的成员action指向该中断号对应的irqaction结构体链表。Irqaction结构体定义如下:
/* include/linux/interrupt.h */
struct irqaction {
irq_handler_t handler; /* 指向中断服务程序 */
unsigned long flags; /* 中断标志 */
unsigned long mask; /* 中断掩码 */
const char *name; /* I/O设备名
void *dev_id; /* 设备标识 */
struct irqaction *next; /* 指向下一个描述符 */
int irq; /* IRQ线 */
struct proc_dir_entry *dir; /* 指向IRQn相关的/proc/irq/n目录的描述符 */
};
其中关键的handler成员指向了该设备的中断服务程序,由执行request_irq时建立。
3. 在驱动程序初始化时,若使用到中断,通常调用函数request_irq()建立该驱动程序对应的irqaction结构体,并把它登记到irq_desc [irq_num]->action链表中。Iqr_num为驱动程序申请的中断号。
request_irq()函数的原型如下:
|
参数irq是设备中断求号,在向irq_desc []数组登记时,它做为数组的下标。把中断号为irq的irqaction结构体的首地址写入irq_desc [irq]->action。这样就把设备的中断请求号与该设备的中断服务例程irqaction联系在一起了。
这样当CPU接收到中断请求后,就可以根据中断号通过irq_desc []找到该设备的中断服务程序。流程如上图所示。
4. 关于共享中断
共享中断的不同设备的iqraction结构体都会添加进该中断号对应的irq_desc结构体的action成员所指向的irqaction链表内。当内核发生中断时,它会依次调用该链表内所有的handler函数。因此,若驱动程序需要使用共享中断机制,其中断处理函数必须有能力识别是否是自己的硬件产生了中断。通常是通过读取该硬件设备提供的中断flag标志位进行判断。
----------------------
当使用内核共享中断时,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的代码:
000ff">unsigned long flags; /* Make sure it's not being used on another CPU */
二.将使用该中断处理程序的设备结构体传递给该中断处理程序 首先看两个基础条件: 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传递给中断服务程序
使用方法如下:
因此,我们可以通过将设备结构传递给request_irq的dev_id参数这种机制,在中断处理函数中使用该设备结构体,这是大部分驱动程序通用的一种手法。 2)前面我们讲了若使用共享中断,那么中断处理函数自身需要能识别是否是自己的设备产 生了中断。通常这是通过读取该硬件设备提供的中断flag标志位进行判断的。 而往往驱动程序里定义的设备结构体通常包含了该设备的IO地址,加上偏移就可以算出中断状态寄存器及中断flag标志位的IO地址信息。因此将设备结构体通过dev_id传递给设备中断处理程序的另一个作用就是使用共享中断时,可以在中断处理函数内通过读取该设备结构 (dev_id) 中提供的中断Flag标志位地址信息进行判断,是否是该设备产生了中断,然后再进一步判断是否继续往下执行还是跳到下一个irqaction->handler函数再判断执行。当然,如果本来就知道该设备中断状态寄存器的IO地址,也可以选择直接readl该地址信息进行判断。 |