arm 架构中断

中断就是在cpu执行程序的过程中，突然发生异常 （包括复位、指令错误等等异常，中断只是异常其中一种），可以打断当前正在执行的程序，临时先处理比较紧急的事情，当处理完成了，再回到原来的程序继续执行。

中断如何发生

首先，在一个cpu中 中断源有很多（比如gpio中断、定时器中断等等），那么为了管理这些中断，就需要一个中断控制器。
当发生中断时，相应的中断源会给中断控制器发出信号，中断控制器再给cpu发信号，最后cpu处理中断。

中断的大概流程

1. 初始化：

• 使能中断源（允许发生中断）
• 中断控制器可以选择屏蔽或不屏蔽中断，设置中断优先级等
• cpu 使能中断总开关

2. 异常跳转：

• cpu 每执行完一条指令就会查看有无异常发生
• 发生异常，cpu 分辩异常类型
• cpu 被强制跳转到异常向量表（汇编）中的跳转地址
• 跳转到相应的异常服务函数

3. IRQ 服务函数（汇编）：

• 保存现场，保证当前执行的程序能完好返回（存储 指令寄存器(PC)，以及存数据的寄存器等等各种寄存器的值，会采用压栈的方式）
• 获取中断id（a7 架构，其中可能还需要切换处理器模式等等），根据id跳转到对应的中断处理函数。
• 中断处理函数可以是我们自己编写的，代表的是中断发生后要处理的事情
• 处理完成，返回中断服务函数。
• 还原现场（将各个寄存器的值还回，指令寄存器需要 -4 再还回，涉及到arm 处理器的3级指令流水线）

arm三级指令流水线：
取指-》译指-》执行
比如有3条指令（因为3条指令的地址肯定时连续的，所以假设它们的偏移地址分别是0、4、8），CPU 正在执行一条指令，下一条指令在译指状态，第3条指令在取指状态。
那么执行当前指令时，指令寄存器中存储的指令地址其实时第3条指令的地址，如果按原模原样返回，就把第二条指令遗漏了，这会造成程序崩溃等等很大的错误。

中断控制器（cotex-a架构 —— GIC）

不了解，先空着

异常向量表

异常向量表 是一个地址表，存储着各大类异常服务函数的首地址，当对应的异常发生时cpu会被强制跳转到该地址。

以下是a7 内核的异常向量表，当不同异常发生时会进入各自的服务函数：

异常向量表在程序的最开始被定义，可以参考uboot arch/arm/cpu/armv7/start.s (这是uboot最开始的代码)，imx6ull的异常向量表如下：

_start:
ldr pc, =Reset_Handler /* 复位中断 */
ldr pc, =Undefined_Handler /* 未定义指令中断 */
ldr pc, =SVC_Handler /* SVC(Supervisor)中断 */
ldr pc, =PrefAbort_Handler /* 预取终止中断 */
ldr pc, =DataAbort_Handler /* 数据终止中断 */
ldr pc, =NotUsed_Handler /* 未使用中断 */
ldr pc, =IRQ_Handler /* IRQ 中断 */
ldr pc, =FIQ_Handler /* FIQ(快速中断)未定义中断 */

异常向量表偏移

之前说异常向量表在程序最开始的地址定义(地址 0x00000000)，但是这是不可取的，地址0x00000000 是arm 内核iROM的起始地址，存放着cpu最早的启动代码，更早于uboot，uboot靠它来引导（初始化时钟等等，有关这部分可以看uboot的启动过程）；iROM 中的代码是由CPU 厂商决定的，用户是不可修改的，所以我们的异常向量表无法放在0x0000_0000 这个地址。

那么它的解决办法是：CPU 厂商已经解决了这个问题，在cpu 的内部ram 中设计一个指向异常向量表地址寄存器Exception Vector Table，只要将异常向量表的首地址写入这个寄存器，发生异常时CPU 就可以通过它找到异常向量表啦。
根据不同处理器设计的不同，它们的异常向量表偏移地址也会不同，比如说 0X87800000（这是内存地址） 这是6ull裸机程序的起始地址，那么中断向量表也就放在这里。

中断与线程的切换

Linux 中断的演进

硬中断和软中断

Linux 系统把中断的意义扩展了，对于按键中断等硬件产生的中断，称之为“硬件中断” (hard irq)。
每个硬件中断都有对应的处理函数，比如按键中断、网卡中断的处理函数肯定不一样。
为方便理解，你可以先认为对硬件中断的处理是用数组来实现的，数组里存放的是函数指针：

注意：上图是简化的， Linux 中这个数组复杂多了。
当发生 A 中断时，对应的 irq_function_A 函数被调用。硬件导致该函数被调用。

相对的，还可以人为地制造中断：软件中断(soft irq)，如下图所示：

注意：上图是简化的， Linux 中这个数组复杂多了。
问题来了：
a. 软件中断何时生产？
由软件决定，对于 X 号软件中断，只需要把它的 flag 设置为 1 就表示发生了该中断。
b. 软件中断何时处理？
软件中断嘛，并不是那么十万火急，有空再处理它好了。
什么时候有空？不能让它一直等吧？
Linux 系统中，各种硬件中断频繁发生，至少定时器中断每 10ms 发生一次，那取个巧？
在处理完硬件中断后，再去处理软件中断？就这么办！

有哪些软件中断？
查内核源码 include/linux/interrupt.h

enum
{
	HI_SOFTIRQ=0,
	TIMER_SOFTIRQ,
	NET_TX_SOFTIRQ,
	NET_RX_SOFTIRQ,
	BLOCK_SOFTIRQ,
	IRQ_POLL_SOFTIRQ,
	TASKLET_SOFTIRQ,
	SCHED_SOFTIRQ,
	HRTIMER_SOFTIRQ, /* Unused, but kept as tools rely on the
			    numbering. Sigh! */
	RCU_SOFTIRQ,    /* Preferable RCU should always be the last softirq */

	NR_SOFTIRQS
};

怎么触发软件中断？最核心的函数是 raise_softirq，简单地理解就是设置 softirq_veq[nr]的标记位：

extern void raise_softirq(unsigned int nr);

怎么设置软件中断的处理函数：

extern void open_softirq(int nr, void (*action) (struct soft_action*));

硬中断遵循两个规则

1. 不能被打断（不允许被其它线程或中断打断（同一个中断或是优先级更高也不行））。
2. 中断程序必须简洁，精炼，不允许执行太长的时间。

在硬件中断执行过程中，硬件中断使能是被关闭的，中断程序执行完后才会打开。
对于第一点，解释是： 假如中断可以嵌套，当执行A中断时发生了B中断，被B打断，需要保存A的现场到栈里，那么B也有可能被C打断。如果不停的被打断，那么意味着需要若干各栈，最后内存空间不够用了，系统就会崩溃。所以为了简单，中断不允许嵌套。

第二点，在执行中断函数时，其它线程无法执行，如果中断时间过长，就显得系统卡顿，其他中断也无法快速得到处理。

在 Linux 系统中使用中断是挺简单的，为某个中断 irq 注册中断处理函数 handler，可以使用 request_irq 函数：

static inline int __must_check
request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags,
	    const char *name, void *dev)

在 handler 函数中，代码尽可能高效。

但是，处理某个中断要做的事情就是很多，没办法加快。比如对于按键中断，我们需要等待几十毫秒消除机械抖动。难道要在 handler 中等待吗？对于计算机来说，这可是一个段很长的时间。
怎么办？

中断函数耗时长的处理方式

要处理的事情实在太多，拆分为：上半部、下半部

当然，在很多情况下中断程序无奈需要执行耗时的操作，比如网卡中断，接收数据时就很耗时。
Linux系统对中断做出扩展，中断函数可以分为上半部 和下半部 。上半部用于处理 比较紧急且快速 的事情（比如清除中断标志位，防止同一次中断信号不断触发），而下半部则处理耗时长的事。

下半部以软中断的形式处理，软中断根据Linux 系统的不断优化有以下几类：

下半部要做的事情耗时不是太长： 小任务 tasklet

当下半部比较耗时但是能忍受，并且它的处理比较简单时，可以用 tasklet 来处理下半部。 tasklet 是使用软件中断来实现。

Linux 中硬件中断与软件中断调用流程图：

注意：在开始处理软中断前后，都会对preempt_count做++ 和-- 处理，preempt_count 保证不会执行其他多余的软中断。
软中断是可以被硬中断所打断的，当执行完硬件中断后会用 !in_interrupt() 判断被打断前是否有软中断正在执行，如果有那么将不会执行其他软中断，而是恢复被打断的软中断现场继续执行。
硬件中断与软件中断，始终保持多对1 的关系。

preempt：抢占。

耗时的下半部中断函数就可以交给软件中断函数来处理。它们是可以被硬件中断函数打断的，不能被普通线程打断。(这里单指软中断的一种方式：小任务；后面介绍的work线程，和软中断线程也属于软中断，它们是可以被调度的)
此种小任务方式的缺点是：如果软中断要处理的事务过多，那么它会一直占用cpu时间，普通线程得不到执行，导致系统卡钝。

下半部要做的事情太多并且很复杂：工作队列（线程化中断处理方式）

在中断下半部 tasklet的执行过程中，虽然是开中断的，期间可以处理各类中断。但是毕竟整个中断的处理还没走完，这期间 APP 是无法执行的。
假设下半部要执行 1、 2 分钟，在这 1、 2 分钟里 APP 都是无法响应的。
这谁受得了？
所以，如果中断要做的事情实在太耗时，那就不能用软件中断来做，而应该用内核线程来做：在中断上半部唤醒内核线程。内核线程和 APP 都一样竞争执行， APP 有机会执行，系统不会卡顿。
这个内核线程是系统帮我们创建的，一般是 kworker 线程，内核中有很多这样的线程：

kworker 线程要去“工作队列” (work queue)上取出一个一个“工作” (work)，来执行它里面的函数。

那我们怎么使用 work、 work queue 呢？
a. 创建 work：
你得先写出一个函数，然后用这个函数填充一个 work 结构体。比如：
static DECLARE_WORK(work_struct,work_func);
b. 要执行这个函数时，把 work 提交给 work queue 就可以了：
schedule_work(work_struct);
上述函数会把 work 提供给系统默认的 work queue： system_wq，它是一个队列。
c. 谁来执行 work 中的函数？
不用我们管， schedule_work 函数不仅仅是把 work 放入队列，还会把 kworker 线程唤醒。此线程抢到
时间运行时，它就会从队列中取出 work，执行里面的函数。
d. 谁把 work 提交给 work queue？
在中断场景中，可以在中断上半部调用 schedule_work 函数。

工作队列相关内核函数被定义在：include/linux/workqueue.h 工作队列的使用

新技术： threaded irq

使用线程来处理中断，并不是什么新鲜事。使用 work 就可以实现，但是需要定义 work、调用schedule_work，好麻烦啊。
太懒了太懒了，就这 2 步你们都不愿意做。
好，内核是为懒人服务的，再杀出一个函数：

你可以只提供 thread_fn，系统会为这个函数创建一个内核线程。发生中断时，内核线程就会执行这个函数。

说你懒是开玩笑，内核开发者也不会那么在乎懒人。
以前用 work 来线程化地处理中断，一个 worker 线程只能由一个 CPU 执行，多个中断的 work 都由同一个 worker 线程来处理，在单 CPU 系统中也只能忍着了。但是在 SMP 系统中，明明有那么多 CPU 空着，你偏偏让多个中断挤在这个 CPU 上？
新技术 threaded irq，为每一个中断都创建一个内核线程；多个中断的内核线程可以分配到多个 CPU上执行，这提高了效率。

Linux 中断系统中的重要数据

本节内容，可以从 request_irq(include/linux/interrupt.h)函数一路分析得到。
能弄清楚下面这个图，对 Linux 中断系统的掌握也基本到位了。

最核心的结构体是 irq_desc，之前为了易于理解，我们说在 Linux 内核中有一个中断数组，对于每一个硬件中断，都有一个数组项，这个数组就是 irq_desc 数组。
注意：如果内核配置了 CONFIG_SPARSE_IRQ，那么它就会用基数树(radix tree)来代替 irq_desc 数组。SPARSE 的意思是“稀疏”，假设大小为 1000 的数组中只用到 2 个数组项，那不是浪费嘛？所以在中断比较 “稀疏” 的情况下可以用基数树来代替数组。

1、irq_desc 数组

irq_desc 结构体在 include/linux/irqdesc.h 中定义，主要内容如下图：

每一个 irq_desc 数组项中都有一个函数： handle_irq，还有一个 action 链表。要理解它们，需要先看中断结构图：

外部设备 1、外部设备 n 共享一个 GPIO 中断 B，多个 GPIO 中断汇聚到 GIC(通用中断控制器)的 A 号中断， GIC 再去中断 CPU。那么软件处理时就是反过来，CPU先读取 GIC 获得中断号 A（哪一个模块发生了中断），再细分出 GPIO 中断 B（哪一个GPIO 发生了中断），最后判断是哪一个外部芯片发生了中断。

所以，中断的处理函数来源有三：
① GIC 的处理函数：
当CPU 从GIC 中读出中断号A后，就会调用irq_desc[A].handle_irq。
假设 irq_desc[A].handle_irq 是 XXX_gpio_irq_handler(XXX 指厂家)，这个函数需要读取芯片的 GPIO控制器，细分发生的是哪一个 GPIO 中断(假设是 B)，再去调用 irq_desc[B]. handle_irq。
注意： irq_desc[A].handle_irq 细分出中断号 B，调用对应的 irq_desc[B].handle_irq。
显然中断 A 是 CPU 感受到的顶层的中断， GIC 中断 CPU 时， CPU 读取 GIC 状态得到中断 A。

② 模块的中断处理函数：
比如对于 GPIO 模块向 GIC 发出的中断 B，它的处理函数是 irq_desc[B].handle_irq。
BSP 开发人员会设置对应的处理函数，一般是 handle_level_irq 或 handle_edge_irq，从名字上看是用来处理电平触发的中断、边沿触发的中断。
注意： 导致 GPIO 中断 B 发生的原因很多，可能是外部设备 1，可能是外部设备 n，可能只是某一个设备，也可能是多个设备。所以 irq_desc[B].handle_irq 会调用某个链表里的函数，这些函数由外部设备提供。这些函数自行判断该中断是否自己产生，若是则处理。

③ 外部设备提供的处理函数：
这里说的“外部设备”可能是芯片，也可能总是简单的按键。它们的处理函数由自己驱动程序提供，这是最熟悉这个设备的“人”：它知道如何判断设备是否发生了中断，如何处理中断。
对于共享中断，比如 GPIO 中断 B，它的中断来源可能有多个，每个中断源对应一个中断处理函数。所以 irq_desc[B]中应该有一个链表，存放着多个中断源的处理函数。
一旦程序确定发生了 GPIO 中断 B，那么就会从链表里把那些函数取出来，一一执行。这个链表就是 action 链表。

对于我们举的这个例子来说， irq_desc 数组如下：

2、irqaction 结构体

irqaction 结构体在 include/linux/interrupt.h 中定义，主要内容如下图：

当调用 request_irq、 request_threaded_irq 注册中断处理函数时，内核就会构造一个 irqaction 结
构体。
在里面保存 name、 dev_id 等，最重要的是 handler、 thread_fn、 thread。
handler 是中断处理的上半部函数，用来处理紧急的事情。
thread_fn 对应一个内核线程 thread，当 handler 执行完毕， Linux 内核会唤醒对应的内核线程。在内核线程里，会调用 thread_fn 函数。
可以提供 handler 而不提供 thread_fn，就退化为一般的 request_irq 函数。
可以不提供 handler 只提供 thread_fn，完全由内核线程来处理中断。
也可以既提供 handler 也提供 thread_fn，这就是中断上半部、下半部。

里面还有一个名为 sedondary 的 irqaction 结构体，它的作用以后再分析。
在 reqeust_irq 时可以传入 dev_id，为何需要 dev_id？作用有 2：
① 中断处理函数执行时，可以使用 dev_id
② 卸载中断时要传入 dev_id，这样才能在 action 链表中根据 dev_id 找到对应项所以在共享中断中必须提供 dev_id，非共享中断可以不提供。

3、irq_data 结构体

irq_data 结构体在 include/linux/irq.h 中定义，主要内容如下图：

它就是个中转站，里面有 irq_chip 指针 irq_domain 指针，都是指向别的结构体。
比较有意思的是 irq、 hwirq， irq 是软件中断号（并非上面所讲的软中断）， hwirq 是硬件中断号。比如上面我们举的例子，在 GPIO中断 B 是软件中断号，可以找到 irq_desc[B]这个数组项； GPIO 里的第 x 号中断，这就是 hwirq。
谁来建立 irq、 hwirq 之间的联系呢？由 irq_domain 来建立。 irq_domain 会把本地的 hwirq 映射为全局的 irq ，什么意思？比如 GPIO 控制器里有第 1 号中断， UART 模块里也有第 1 号中断，这两个“第 1 号中断”是不一样的，它们属于不同的“域”──irq_domain。

4、irq_domain 结构体

irq_domain 结构体在 include/linux/irqdomain.h 中定义，主要内容如下图：

当我们后面从设备树讲起，如何在设备树中指定中断，设备树的中断如何被转换为 irq 时， irq_domain将会起到极大的作为。
这里基于入门的解度简单讲讲，在设备树中你会看到这样的属性：

interrupt-parent = <&gpio1>;
interrupts = <5 IRQ_TYPE_EDGE_RISING>;

它表示要使用 gpio1 里的第 5 号中断， hwirq 就是 5。
但是我们在驱动中会使用 request_irq(irq, handler)这样的函数来注册中断， irq 是什么？它是软件中断号，它应该从“ gpio1 的第 5 号中断”转换得来。
谁把 hwirq 转换为 irq？由 gpio1 的相关数据结构，就是 gpio1 对应的 irq_domain 结构体。
irq_domain 结构体中有一个 irq_domain_ops 结构体，里面有各种操作函数，主要是：
① xlate
用来解析设备树的中断属性，提取出 hwirq、 type 等信息。
② map
把 hwirq 转换为 irq

5、irq_chip 结构体

irq_chip 结构体在 include/linux/irq.h 中定义，主要内容如下图：

这个结构体跟“ chip”即芯片相关，里面各成员的作用在头文件中也列得很清楚，摘录部分如下：

* @irq_startup: start up the interrupt (defaults to ->enable if NULL)
* @irq_shutdown: shut down the interrupt (defaults to ->disable if NULL)
* @irq_enable: enable the interrupt (defaults to chip->unmask if NULL)
* @irq_disable: disable the interrupt
* @irq_ack: start of a new interrupt
* @irq_mask: mask an interrupt source
* @irq_mask_ack: ack and mask an interrupt source
* @irq_unmask: unmask an interrupt source
* @irq_eoi: end of interrupt

我们在 request_irq 后，并不需要手工去使能中断，原因就是系统调用对应的 irq_chip 里的函数帮我们使能了中断。
我们提供的中断处理函数中，也不需要执行主芯片相关的清中断操作，也是系统帮我们调用 irq_chip中的相关函数。
但是对于外部设备相关的清中断操作，还是需要我们自己做的。
就像上面图里的“外部设备 1“、“外部设备 n”，外设备千变万化，内核里可没有对应的清除中断操作。

在设备树中指定中断_在代码中获得中断

1、设备树里中断节点的语法

参考文档：
内核 Documentation\devicetree\bindings\interrupt-controller\interrupts.txt

设备树里的中断控制器

中断的硬件框图如下：

在硬件上，“中断控制器” 只有 GIC 这一个，但是我们在软件上也可以把上图中的“ GPIO”称为“中断控制器”。很多芯片有多个 GPIO 模块，比如 GPIO1、 GPIO2 等等。所以软件上的“中断控制器”就有很多个：GIC、 GPIO1、 GPIO2 等等。

GPIO1 连接到 GIC， GPIO2 连接到 GIC，所以 GPIO1 的父亲是 GIC， GPIO2 的父亲是 GIC。
假设 GPIO1 有 32 个中断源（一组gpio中有32个引脚），但是它把其中的 16 个汇聚起来向 GIC 发出一个中断（16个gpio引脚共享一个软件中断号，可以查看imx6ull参考手册 ），把另外 16 个汇聚起来向 GIC 发出另一个中断。这就意味着 GPIO1 会用到 GIC 的两个中断，会涉及 GIC 里的 2 个 hwirq。

这些层级关系、中断号(hwirq)，都会在设备树中有所体现。

在设备树中，中断控制器节点中必须有一个属性： interrupt-controller，表明它是“中断控制器”。
还必须有一个属性： #interrupt-cells，表明引用这个中断控制器的话需要多少个 cell。
#interrupt-cells 的值一般有如下取值：
① #interrupt-cells=<1>
别的节点要使用这个中断控制器时，只需要一个 cell 来表明使用“哪一个中断”。
② #interrupt-cells=<2>
别的节点要使用这个中断控制器时，需要一个 cell 来表明使用“哪一个中断”；
还需要另一个 cell 来描述中断，一般是表明触发类型：

第 2 个 cell 的 bits[3:0] 用来表示中断触发类型(trigger type and level flags)：
1 = low-to-high edge triggered，上升沿触发
2 = high-to-low edge triggered，下降沿触发
4 = active high level-sensitive，高电平触发
8 = active low level-sensitive，低电平触发

示例如下：

vic: intc@10140000 {
	compatible = "arm,versatile-vic";
	interrupt-controller;
	#interrupt-cells = <1>;
	reg = <0x10140000 0x1000>;
};

如果中断控制器有级联关系，下级的中断控制器还需要表明它的“ interrupt-parent”是谁（使用了哪个一中断控制器），用了interrupt-parent”中的哪一个“ interrupts”，请看下一小节。

2、设备树里使用中断

一个外设，它的中断信号接到哪个“中断控制器”的哪个“中断引脚”，这个中断的触发方式是怎样的？
这 3 个问题，在设备树里使用中断时，都要有所体现。

① interrupt-parent=<&XXXX>
你要用哪一个中断控制器里的中断？
② interrupts
你要用哪一个中断？
Interrupts 里要用几个 cell，由 interrupt-parent 对应的中断控制器决定。在中断控制器里有“ #interrupt-cells”属性，它指明了要用几个 cell 来描述中断。
比如：

i2c@7000c000 {
	gpioext: gpio-adnp@41 {
		compatible = "ad,gpio-adnp";		//保证驱动程序与之匹配
		interrupt-parent = <&gpio>;			//说明它所使用的中断属于该中断控制器
		interrupts = <160 1>;				//表明使用了该中断控制器中的160 号中断，触发类型是上升沿触发
		
		gpio-controller;					//表明它是一个中断控制器
		#gpio-cells = <1>;					//如果有要使用它的中断，需要用一个 cell来描述所使用的中断
		interrupt-controller;
		#interrupt-cells = <2>;
	};
	......
};

③ 新写法： interrupts-extended
一个“ interrupts-extended”属性就可以既指定“ interrupt-parent”，也指定“ interrupts”，比如：

interrupts-extended = <&intc1 5 1>, <&intc2 1 0>;		//表明了所属中断控制器的同时，亦表明描述了所使用的中断

3、设备树里中断节点的示例

以 100ASK_IMX6ULL 开发板为例，在 arch/arm/boot/dts 目录下可以看到 2 个文件： imx6ull.dtsi、100ask_imx6ull-14x14.dts，把里面有关中断的部分内容抽取出来。
设备树节点中需要一个 compatible 属性来标注，让驱动程序能找到对应的节点。

观察图中所见：

1. intc 节点描述了顶级中断控制器 GIC，#interrupt-cells = <3> 表明 使用GIC 中断控制器需要用 3个cells 来描述一个中断。
   为什么是三个？
   中断类型：第一个cells 用来表明中断类型。在一个SOC 中允许有多个核，在这种情况下，就会有多种中断类型：SPI（Shared Peripheral Interrupt 共享外设中断）中断信号可以发到多个核、PPI（Private Peripheral Interrupt 私有外设中断）外设中断信号只允许发到指定内核、SGI (Software Generated Interrupt 软件通用中断) 用于多个核之间互发信号。
   其它两个 cells 分别表明 是哪一号中断（软件中断号，参考手册可查看）和 中断触发类型。

2. gpc 描述了它使用GIC 的中断。

3. 观察gpio1 节点可以发现它并没有标注自己的父节点时谁，此时它会继承父节点的一些属性，比如“ interrupt-parent”：
   在SOC 节点中 写到 “interrupt-parent = <&gpc>” ，所以它的父亲是gpc，于是中断结构图有了如下的变化。

4. 以上都是BSP 工程师写好的，只需要了解，我们使用的例如 spidev 节点。

从以上设备树反推 IMX6ULL 的中断体系，如下，比之前的框图多了一个“ GPC INTC”：

GPC INTC 的英文是： General Power Controller, Interrupt Controller。它提供中断屏蔽、中断状态查询功能，实际上这些功能在 GIC 里也实现了，个人觉得有点多余。除此之外，它还提供唤醒功能 ，这才是保留它的原因。

在代码中获得中断

对于 platform_device
对于注册在platform 总线下的驱动，可以使用platform_get_resource 来获取：
一 个 节 点 能 被 转 换 为 platform_device ， 如 果它 的 设 备 树 里 指 定 了中 断 属 性 ， 那 么 可 以 从platform_device 中获得“中断资源”，函数如下，可以使用下列函数获得 IORESOURCE_IRQ 资源，即中断号：

/**
* platform_get_resource - get a resource for a device
* @dev: platform device
* @type: resource type // 取哪类资源？ IORESOURCE_MEM、 IORESOURCE_REG
* // IORESOURCE_IRQ 等
* @num: resource index // 这类资源中的哪一个？
*/
struct resource *platform_get_resource(struct platform_device *dev,unsigned int type, unsigned int num);

对于 I2C 设备、 SPI 设备
对于 I2C 设备节点， I2C 总线驱动在处理设备树里的 I2C 子节点时，也会处理其中的中断信息。一个I2C 设备会被转换为一个 i2c_client 结构体，中断号会保存在 i2c_client 的 irq 成员里，代码如下(drivers/i2c/i2c-core.c)：

对于 SPI 设备节点， SPI 总线驱动在处理设备树里的 SPI 子节点时，也会处理其中的中断信息。一个SPI 设备会被转换为一个 spi_device 结构体 ，中断号会保存在 spi_device 的 irq 成员里，代码如下(drivers/spi/spi.c)：

调用 of_irq_get 获得中断号
如果你的设备节点既不能转换为 platform_device，它也不是 I2C 设备，不是 SPI 设备，那么在驱动程序中可以自行调用 of_irq_get 函数去解析设备树，得到中断号。

对于 GPIO
参考： drivers/input/keyboard/gpio_keys.c
可以使用 gpio_to_irq 或 gpiod_to_irq 获得中断号。
举例，假设在设备树中有如下节点：

gpio-keys {
	compatible = "gpio-keys";
	pinctrl-names = "default";
	user {
		label = "User Button";
		gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
		gpio-key,wakeup;
		linux,code = <KEY_1>;
	};
};

那么可以使用下面的函数获得引脚和 flag：
button->gpio = of_get_gpio_flags(property_name, 0, &flags); bdata->gpiod = gpio_to_desc(button->gpio);
再去使用 gpiod_to_irq 获得中断号：
irq = gpiod_to_irq(bdata->gpiod);