request_irq() | 注册中断服务

参考  : ARM Linux 中断机制分析.pdf

linux-2.6.26内核中ARM中断实现详解(1)

一、中断注册方法

在linux内核中用于申请中断的函数是request_irq(),函数原型在Kernel/irq/manage.c中定义:

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

irq是要申请的硬件中断号

handler是向系统注册的中断处理函数,是一个回调函数,中断发生时,系统调用这个函数,dev_id参数将被传递给它。

irqflags是中断处理的属性,若设置了IRQF_DISABLED (老版本中的SA_INTERRUPT,本版zhon已经不支持了),则表示中断处理程序是快速处理程序,快速处理程序被调用时屏蔽所有中断,慢速处理程序不屏蔽;若设置了IRQF_SHARED (老版本中的SA_SHIRQ),则表示多个设备共享中断,若设置了IRQF_SAMPLE_RANDOM(老版本中的SA_SAMPLE_RANDOM),表示对系统熵有贡献,对系统获取随机数有好处。(这几个flag是可以通过或的方式同时使用的)

devname设置中断名称,通常是设备驱动程序的名称  在cat /proc/interrupts中可以看到此名称。

dev_id在中断共享时会用到,一般设置为这个设备的设备结构体或者NULL。

request_irq()返回0表示成功,返回-INVAL表示中断号无效或处理函数指针为NULL,返回-EBUSY表示中断已经被占用且不能共享。

==================================================================================================================================

request_irq() | 注册中断服务

在 2.4 内核和 2.6内核中都使用 request_irq() 函数来注册中断服务函数。在 2.4 内核中,需要包含的头文件是 #include <linux/sched.h> ,2.6 内核中需要包含的头文件则是
#include <linux/interrupt.h> 。函数原型如下:

  • 2.4 内核
int request_irq ( unsignedint irq , void ( * handler)( int , void * , struct pt_regs * ), unsignedlong frags , constchar * device , void * dev_id);

  • 2.6 内核
request_irq( unsignedint irq , irq_handler_t handler , unsignedlong flags , constchar * name , void * dev);

参数说明

在发生对应于第 1个参数 irq 的中断时,则调用第 2 个参数 handler 为要注册的中断服务函数(也就是把 handler() 中断服务函数注册到内核中 )。

第 3 个参数 flags 指定了 快速中断或中断共享等中断处理属性。在 2.6 教新的内核里(我的是 2.6.27 ~ 2.6.31 ),在 linux/interrupt.h 中定义操作这个参数的宏如下:
引用
/*
 * These correspond to the IORESOURCE_IRQ_* defines in
 * linux/ioport.h to select the interrupt line behaviour.  When
 * requesting an interrupt without specifying a IRQF_TRIGGER, the
 * setting should be assumed to be "as already configured", which
 * may be as per machine or firmware initialisation.

#define IRQF_TRIGGER_NONE0x00000000
#define IRQF_TRIGGER_RISING 0x00000001
#define IRQF_TRIGGER_FALLING 0x00000002   
#define IRQF_TRIGGER_HIGH 0x00000004                  
指定中断触发类型:高电平有效。新增加的标志 
#define IRQF_TRIGGER_LOW 0x00000008
#define IRQF_TRIGGER_MASK (IRQF_TRIGGER_HIGH | IRQF_TRIGGER_LOW | \
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING)
#define IRQF_TRIGGER_PROBE 0x00000010

/*
* These flags used only by the kernel as part of the  irq handling routines.
*                registered first in an shared interrupt is considered for
*                performance reasons)
*/
#define IRQF_DISABLED           0x00000020         * IRQF_DISABLED - keep irqs disabled when calling the action handler
#define IRQF_SAMPLE_RANDOM      0x00000040 * IRQF_SAMPLE_RANDOM - irq is used to feed the random generator
#define IRQF_SHARED             0x00000080* IRQF_SHARED - allow sharing the irq among several devices
#define IRQF_PROBE_SHARED       0x00000100 * IRQF_PROBE_SHARED - set by callers when they expect sharing mismatches to occur
#define IRQF_TIMER              0x00000200 * IRQF_TIMER - Flag to mark this interrupt as timer interrupt
#define IRQF_PERCPU             0x00000400 * IRQF_PERCPU - Interrupt is per cpu
#define IRQF_NOBALANCING        0x00000800 * IRQF_NOBALANCING - Flag to exclude this interrupt from irq balancing
#define IRQF_IRQPOLL            0x00001000 * IRQF_IRQPOLL - Interrupt is used for polling (only the interrupt that is
早期一点的 2.6 内核这里一般以 SA_ 前缀开头,如:
SA_INTERRUPT   表示禁止其他中断;(对应于 IRQF_DISABLED )
SA_SHIRQ             表示共享相同的中断号 (对应于 IRQF_SHARED )
SA_SAMPLE_RANDOM   此宏会影响到 RANDOM 的处理( 对应于 IRQF_SAMPLE_RANDOM )。

第 4 个参数 name,通常是 设备驱动程序的名称。改值用在 /proc/interrupt 系统 (虚拟) 文件上,或内核发生中断错误时使用。

第 5 个参数 dev_id 中断名称 可作为共享中断时的中断区别参数,也可以用来指定中断服务函数需要参考的数据地址。建议将 设备结构指针作为 dev_id参数

int request_irq(unsigned int irq, irq_handler_t handler,
        
IRQF_SHARED, const char *devname, void *dev_id)

很多权威资料中都提到,中断共享注册时的注册函数中的dev_id参数是必不可少的,并且dev_id的值必须唯一。那么这里提供唯一的dev_id值的究竟是做什么用的?

根据我们前面中断模型的知识,可以看出发生中断时,内核并不判断究竟是共享中断线上的哪个设备产生了中断,它会循环执行所有该中断线上注册的中断处理函数(即irqaction->handler函数)。因此irqaction->handler函数有责任识别出是否是自己的硬件设备产生了中断,然后再执行该中断处理函数。通常是通过读取该硬件设备提供的中断flag标志位进行判断。那既然kernel循环执行该中断线上注册的所有irqaction->handler函数,把识别究竟是哪个硬件设备产生了中断这件事交给中断处理函数本身去做,那request_irq的dev_id参数究竟是做什么用的?

很多资料中都建议将设备结构指针作为dev_id参数。在中断到来时,迅速地根据硬件寄存器中的信息比照传入的dev_id参数判断是否是本设备的中断,若不是,应迅速返回。这样的说法没有问题,也是我们编程时都遵循的方法。但事实上并不能够说明为什么中断共享必须要设置dev_id。

下面解释一下dev_id参数为什么必须的,而且是必须唯一的。

当调用free_irq注销中断处理函数时(通常卸载驱动时其中断处理函数也会被注销掉),因为dev_id是唯一的,所以可以通过它来判断从共享中断线上的多个中断处理程序中删除指定的一个。如果没有这个参数,那么kernel不可能知道给定的中断线上到底要删除哪一个处理程序。


注销函数定义在Kernel/irq/manage.c中定义: 
    
void free_irq(unsigned int irq, void *dev_id)


返回值
函数运行正常时返回 0 ,否则返回对应错误的负值。

示例代码片段
引用

irqreturn_t xxx_interrupt (intirq,void*dev_id)
{
        ...

        return (IRQ_HANDLED);
}

int xxx_open (struct inode *inode,structfile*filp)
{
        if (!request_irq (XXX_IRQ,xxx_interruppt,IRQF_DISABLED,"xxx",NULL)){

                /*正常注册*/
        }

        return (0);
}

============================================================================

内核中的中断处理模型

内核版本: Linux 2.6.19

Kernel中断处理模型结构图如下:

内核中的中断处理模型

下面简单介绍一下:

1. Linux定义了名字为irq_desc的中断例程描述符表:(include/linux/irq.h)

struct irqdesc irq_desc[NR_IRQS];

NR_IRQS表示中断源的数目。

2. irq_desc[]是一个指向irq_desc结构的数组, irq_desc结构是各个设备中断服务例程的描述符。

struct irq_desc {
irq_flow_handler_t handle_irq;
struct irq_chip *chip;
void *handler_data;
void *chip_data;
struct irqaction *action;
unsigned int status;

unsigned intdepth;
unsigned int wake_depth;
unsigned int irq_count;
unsigned int irqs_unhandled;
spinlock_t lock;
#ifdef CONFIG_SMP
cpumask_t affinity;
unsigned int cpu;
#endif
#if defined(CONFIG_GENERIC_PENDING_IRQ) || defined(CONFIG_IRQBALANCE)
cpumask_t pending_mask;
#endif
#ifdef CONFIG_PROC_FS
struct proc_dir_entry*dir;
#endif
const char *name;
} ____cacheline_aligned;

Irq_desc结构体中的成员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()函数的原型如下:

// kernel/irq/manage.c
int request_irq(unsignedint irq,
irqreturn_t (*handler)(int,void*,struct pt_regs*),
unsignedlong irqflags,
const char *devname,
void *dev_id);

参数irq是设备中断求号,在向irq_desc []数组登记时,它做为数组的下标。把中断号为irq的irqaction结构体的首地址写入irq_desc [irq]->action。这样就把设备的中断请求号与该设备的中断服务例程irqaction联系在一起了。

这样当CPU接收到中断请求后,就可以根据中断号通过irq_desc []找到该设备的中断服务程序。流程如上图所示。

4. 关于共享中断

共享中断的不同设备的iqraction结构体都会添加进该中断号对应的irq_desc结构体的action成员所指向的irqaction链表内。当内核发生中断时,它会依次调用该链表内所有的handler函数。因此,若驱动程序需要使用共享中断机制,其中断处理函数必须有能力识别是否是自己的硬件产生了中断。通常是通过读取该硬件设备提供的中断flag标志位进行判断。


<think> 首先,用户的问题是:挂载中断时应该选择使用request_irq还是devm_request_irq?我需要基于提供的引用内容来回答。 回顾引用内容: - [^1] 描述了devm_request_threaded_irq()函数的工作流程,包括如何注册中断顶半部和底半部,以及其自动释放资源的特点。 - [^2] 解释了中断标志如IRQF_TRIGGER_RISING等,并比较了request_irq和devm_request_irqrequest_irq需要手动释放,而devm_request_irq是自动管理的资源,不需要手动free_irq。 - [^3] 讨论了irq domain机制,但这不是直接相关的。 - [^4] 展示了使用request_irq和tasklet的中断处理模板,包括模块加载和卸载函数中的中断申请和释放。 用户的问题焦点是选择request_irq还是devm_request_irq。 关键点: - request_irq:需要手动调用free_irq来释放中断资源。 - devm_request_irq:自动管理资源,当设备移除时自动释放中断资源,减少了资源泄露的风险。 根据引用[^2],devm_request_irq的优势在于它是“managed”资源,避免了手动资源管理错误。 在回答时,我需要: - 使用中文。 - 结构化清晰:逐步解释,帮助用户理解。 - 确保真实可靠,基于引用。 - 生成相关问题。 - 在引用段落末尾添加引用标识,如[^1]。 回答结构: 1. 介绍两种函数。 2. 比较它们的区别。 3. 给出选择建议。 4. 解释理由,基于引用。 5. 生成相关问题。 最后,添加相关问题。 最终输出格式: - 用户可见层:回答清晰。 - 在末尾添加相关问题。 确保LaTeX语法正确:用户问题中没有数学表达式,所以可能不需要。 现在,草拟回答: - 开头解释两者。 - 区别:手动 vs 自动管理。 - 建议:优先使用devm_request_irq以简化代码和避免泄露。 - 引用来源:[^2]明确指出devm_request_irq自动回收资源。 - 示例:引用[^4]使用request_irq,但可以提到devm版本。 相关问题: 1. devm_request_irq是如何实现自动资源管理的? 2. 在共享中断时,request_irq和devm_request_irq有什么注意事项? 3. 如何使用devm_request_threaded_irq注册线程化中断? </think>### 挂载中断request_irq和devm_request_irq的选择 在Linux内核驱动开发中,挂载中断(即注册中断处理程序)是常见任务。`request_irq`和`devm_request_irq`都是用于申请中断资源的函数,但它们在资源管理方式上有显著区别。下面我将逐步解释两者的区别、选择建议和实际考量。 #### 1. **核心区别:资源管理机制** - **`request_irq`**: - 这是传统的中断申请函数。 - 需要**手动管理资源释放**:在驱动模块卸载或设备移除时,必须显式调用`free_irq`来释放中断资源。 - 使用场景:适用于资源管理需要精确控制的场景,例如在非设备模型驱动或复杂生命周期管理中。 - 示例:引用[^4]展示了在模块卸载函数中手动调用`free_irq`的模板: ```c /*设备驱动模块卸载函数*/ void __exit xxx_exit(void) { ...... /*释放中断*/ free_irq(xxx_irq, xxx_interrupt); // 必须手动释放 } ``` [^4] - **`devm_request_irq`**: - 这是“设备管理”(devres)版本的函数,基于Linux的设备资源管理框架。 - **自动管理资源释放**:当设备(`struct device`)被移除或驱动模块卸载时,内核自动调用释放函数,无需手动`free_irq`。这减少了资源泄露的风险。 - 使用场景:推荐在大多数设备驱动中使用,尤其是支持热插拔或资源管理简化的场景。 - 关键优势:如引用[^2]所述,`devm_request_irq`是申请内核“managed”资源,自动回收资源: > devm_request_irqrequest_irq区别在于前者是申请内核“managed”资源,不需要自己手动释放,会自动回收资源,而后者需要手动调用free_irq来释放中断资源 [^2]。 #### 2. **选择建议** - **优先选择`devm_request_irq`**: - 在大多数现代驱动开发中,`devm_request_irq`是更好的选择,因为它简化了代码并降低了资源泄露的可能性。尤其当驱动与设备模型(如`platform_device`)集成时,它能自动处理资源释放,提高代码可靠性。 - 例如,在热插拔设备或动态加载模块的场景中,自动管理能避免忘记释放中断导致的系统不稳定。 - **何时使用`request_irq`**: - 在以下情况下可能需要手动管理: - 驱动不依赖Linux设备模型(例如,某些旧式或自定义驱动)。 - 需要精细控制中断生命周期(例如,在运行时动态启用/禁用中断多次)。 - 共享中断(`IRQF_SHARED`标志)时,某些复杂场景可能需要手动介入 [^2]。 - **性能与兼容性**: - 两者在中断处理性能上无显著差异,因为核心处理逻辑相同。 - `devm_request_irq`内部调用`request_irq`,但添加了资源跟踪机制 [^1]。 #### 3. **实际使用注意事项** - **中断标志设置**:无论选择哪个函数,都需要正确设置中断标志(如`IRQF_TRIGGER_RISING`用于上升沿触发),这些标志定义在引用[^2]中 [^2]。 - **错误处理**: - `devm_request_irq`在错误时自动清理,而`request_irq`需在失败时手动回滚资源。 - 示例:使用`devm_request_irq`时,驱动模块卸载函数可以省略`free_irq`,代码更简洁。 - **线程化中断**:如果使用线程化中断(顶半部+底半部),`devm_request_threaded_irq`是更安全的自动管理版本 [^1]。 #### 总结 - **推荐`devm_request_irq`**:除非有特定需求(如精细资源控制),否则优先使用它以简化开发和维护。 - **理由**:自动资源管理减少了常见错误(如资源泄露),并符合现代Linux驱动的最佳实践。 如果您有具体代码上下文或驱动类型,我可以提供更针对性的建议。
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值