刚接手一块RISC-V板卡的时候我遇到一个很典型的问题外设的中断死活不触发内核日志里什么都没有/proc/interrupts里也看不到对应的中断计数。查了一圈发现问题是出在设备树里——设备节点没有正确描述自己和中断控制器的关系。后面花了一整天把RISC-V设备树的中断绑定机制彻底理了一遍才发现这块内容其实是个“看着简单、实际全是坑”的地方。这篇文章就来好好聊聊RISC-V设备树中断绑定的规范、节点写法以及很多人会卡住的多父节点路由问题。我会结合一块实际板卡上的配置过程把中断在设备树里是怎么一步步“传”到CPU的整个过程拆开讲适合正在做RISC-V嵌入式驱动开发、或者刚入手RISC-V平台想搞懂中断路由的工程师参考。1. 先搞清楚中断绑定到底在绑什么1.1 设备树里和中断相关的四个核心属性设备树本质上是一棵描述硬件拓扑的树中断绑定就是在这棵树里明确三件事哪个设备能产生中断、哪个设备能接收中断、中断信号走什么路径到达CPU。对应到设备树节点上就是下面这几个属性interrupt-controller这是一个空属性放在某个节点里表示“我这个设备是一个中断控制器”。相当于在硬件树里挂了一个“总机”的牌子。#interrupt-cells用来声明“我这个中断控制器用几个cell来描述一个中断”。它决定了下游设备在写interrupts属性时需要提供几个数字。interrupt-parent挂在设备节点上通过phandle指向这个设备的中断信号要交给哪个中断控制器。相当于告诉系统“我这个设备的中断线接在那台总机上”。interrupts描述设备具体产生哪个中断号、什么触发类型。它包含的数据个数和含义必须和interrupt-parent指向的中断控制器所声明的#interrupt-cells一致。这四个属性是所有中断绑定最底层的约定。无论你是用ARM、RISC-V还是x86设备树里中断描述都离不开这套机制区别只在于中断控制器本身的#interrupt-cells格式不同。1.2 interrupt-cells 常见取值与含义#interrupt-cells的取值直接决定interrupts的写法常见的有三种取值含义典型场景1一个cell表示中断号RISC-V的PLIC、CPU中断控制器2中断号加触发类型GPIO控制器、部分SoC内部中断控制器4包含中断类型和中断号等多段信息ARM GIC等复杂中断控制器以常见的2个cell为例设备节点里通常这样写interrupt-parent gpio0; interrupts 17 IRQ_TYPE_EDGE_RISING;这里的第一个数字是中断源编号对于GPIO控制器来说就是引脚号第二个数字是触发类型。触发类型的取值在设备树头文件里已经定义好了常见的有IRQ_TYPE_EDGE_RISING 1上升沿触发IRQ_TYPE_EDGE_FALLING 2下降沿触发IRQ_TYPE_EDGE_BOTH 3双边沿触发IRQ_TYPE_LEVEL_HIGH 4高电平触发IRQ_TYPE_LEVEL_LOW 8低电平触发这里就有一个非常容易踩的坑你不能想当然地认为所有中断控制器都支持所有触发类型。比如很多RISC-V的PLIC实现对外设上报的中断只有电平触发一种处理方式那你在设备树里即使写了边沿触发PLIC也不会按你想的方式工作。这种情况一般要让中间层的中断控制器比如GPIO控制器来翻译边沿信号PLIC只管接收“有中断来了”这个事实。2. RISC-V中断控制器和ARM GIC到底差在哪2.1 RISC-V中断模型速览CLINT、PLIC、APLIC、IMSIC如果你做过ARM平台的开发一定熟悉GICGeneric Interrupt Controller。RISC-V的中断控制器设计和GIC很不一样它不是把一堆中断全部集中到一个复杂控制器里而是按功能拆分成了几个部分。CLINTCore Local Interruptor负责处理器本地中断主要是定时器中断和软件中断。每个CPU核都有一份。PLICPlatform-Level Interrupt Controller负责平台级外部中断也就是外设中断的统一入口。APLICAdvanced Platform-Level Interrupt ControllerPLIC的进化版在最新的RISC-V中断规范里定义功能更丰富。IMSICIncoming MSI Controller配合APLIC处理消息信号中断MSI主要用于多核中断投递。从设备树角度看CLINT节点和PLIC节点是RISC-V设备树里必须要有的两类中断控制器。CLINT管内部PLIC管外部两个各司其职。这种拆分带来一个直接后果外设的中断路径比ARM平台多一跳。在ARM平台上外设中断直接连到GIC然后由GIC分发给CPU。在RISC-V平台上外设中断通常先连到PLICPLIC再连到CPU的中断控制器riscv,cpu-intc由CPU核内部逻辑最终决定是走M模式还是S模式的中断入口。2.2 PLIC的全局中断号与contextPLIC维护了一个全局中断号表从1开始编号0保留表示无中断。SoC里每个外设的中断线都对应PLIC中的一个中断源号。举个例子一块RISC-V SoC的设备树里UART中断可能是PLIC全局中断号3GPIO控制器中断可能是4到7一组。那么UART设备节点就会写成uart0: serial10013000 { compatible snps,dw-apb-uart; reg 0x0 0x10013000 0x0 0x1000; interrupt-parent plic; interrupts 3; };这里的3就是PLIC全局中断号。你需要从SoC手册的中断表里查到这个号码而不是自己随意定的。PLIC还有“context”的概念你可以把它理解成PLIC输出中断信号的“通道”。每个context对应一个CPU核的某个特权模式。常见的配置是每个CPU核分配一个S-mode外部中断context和一个M-mode外部中断context。PLIC把全局中断号映射到不同的context上从而决定这个中断最终被哪个CPU核接收。设备树里描述这种映射关系用的是interrupts-extended属性这在RISC-V的PLIC节点上非常典型plic: interrupt-controllerc000000 { compatible sifive,plic-1.0.0; reg 0x0 0xc000000 0x0 0x4000000; interrupts-extended cpu0_intc 11, cpu0_intc 9; interrupt-controller; #interrupt-cells 1; };这段代码的意思是这个PLIC的中断输出同时连接到了cpu0的S-mode外部中断异常号11和M-mode外部中断异常号9。CPU节点里的cpu0_intc是riscv,cpu-intc类型的中断控制器。这里出现了一个很多初学者会忽略的点PLIC本身也是一个“设备”它自己也要声明自己的中断输出接到哪里。interrupts-extended在这里正好体现了RISC-V中断模型中“多父节点路由”的第一层——一个控制器可以把自己的中断信号同时送到多个接收方。2.3 设备树中RISC-V中断控制器的典型写法看一段典型RISC-V设备树的中断控制器部分cpu0: cpu0 { compatible riscv; reg 0; cpu0_intc: interrupt-controller { compatible riscv,cpu-intc; interrupt-controller; #interrupt-cells 1; }; }; clint: clint2000000 { compatible sifive,clint0; reg 0x0 0x2000000 0x0 0x10000; interrupts-extended cpu0_intc 3, cpu0_intc 7; }; plic: interrupt-controllerc000000 { compatible sifive,plic-1.0.0; reg 0x0 0xc000000 0x0 0x4000000; interrupts-extended cpu0_intc 11, cpu0_intc 9; interrupt-controller; #interrupt-cells 1; };注意riscv,cpu-intc的#interrupt-cells是1这个数字不是外设中断号而是RISC-V异常号。在RISC-V规范里异常号11对应S-mode外部中断9对应M-mode外部中断7对应M-mode软件中断3对应M-mode机器定时器中断。这就是RISC-V设备树中断绑定和ARM差异最大的一点ARM设备树里CPU的中断控制器通常不参与具体外设中断的绑定外设直接挂到GIC上。RISC-V设备树里CPU的riscv,cpu-intc节点是实际参与中断路径描述的但它只接收那几个异常号不接受外设中断号。外设中断必须先到PLIC再由PLIC按context分发到CPU intc的11号异常。3. 多父节点路由interrupt-parent、interrupt-extended与interrupt-map3.1 什么时候会用到多父节点多父节点路由听起来很玄妙实际就是“一个设备的中断信号可以不止送往一个地方或者一个总线上挂的设备需要通过中间节点转接中断”。结合RISC-V平台的实际情况遇到最多的是下面三种场景。第一种是设备直连PLIC这是最简单也最常见的。设备节点的interrupt-parent直接指向PLIC中断号就是PLIC全局中断号。第二种是设备先连到一个中间中断控制器比如GPIO控制器再由这个中间控制器连到PLIC。这种级联方式在按键、传感器、扩展IO这类设备上很普遍。因为这一类外设的中断线通常和GPIO复用PLIC只认识GPIO控制器上报的“组中断”不认识具体哪个引脚触发了中断。第三种是PCIe这类总线设备它们挂在总线上总线桥负责把下游设备的中断映射到上游中断控制器。这种映射用interrupt-map实现。3.2 interrupt-extended 解决什么问题interrupts-extended和interrupt-parent加interrupts做的事情类似但有一个关键区别interrupts-extended允许在一个属性里描述多个父节点来源的中断而interrupt-parent只能指定一个父节点。我们还是看PLIC节点interrupts-extended cpu0_intc 11, cpu0_intc 9;这个写法表示PLIC同时把中断信号送给了cpu0的S-mode和M-mode外部中断入口。如果换成interrupt-parent加interrupts只能描述一个接收方interrupt-parent cpu0_intc; interrupts 11;那M-mode那边的连接就描述不了了。虽然大多数情况下我们用interrupts-extended主要是在中断控制器节点上但它本质上就是一个通用的多父节点描述手段。什么时候该用interrupts-extended什么时候该用interrupt-parent我的经验是设备只有一个中断父节点时用interrupt-parent加interrupts清晰直观。设备有多个中断父节点或者需要跨父节点描述多个中断时用interrupts-extended。中断控制器节点向上连接多个CPU时几乎总是用interrupts-extended因为每个CPU intc都是一个独立的中断控制器。3.3 interrupt-map 在总线桥上的应用interrupt-map是另一种多父节点路由机制它比interrupts-extended更复杂一点因为它要参与地址翻译。最简单理解interrupt-map的方式是把它看成一个转发表下游设备在子总线上有一个中断标识通常是子地址加中断号这个表负责把它翻译成上游中断控制器的中断标识。PCIe设备树节点是一个经典例子不过RISC-V平台范围内的SoC内部总线桥也会用到这个机制。interrupt-map的格式是interrupt-map 子设备地址 子设备中断号 父中断控制器phandle 父中断控制器地址 父中断号;这里面“子设备地址”的单位是cell数由父节点总线节点的#address-cells决定“子设备中断号”的格式由总线节点的#interrupt-cells决定。而interrupt-map-mask则是一个掩码用来剔除子设备地址中不参与匹配的位。实际操作中如果只是把外设直接连到PLIC或GPIO控制器基本用不到interrupt-map。但一旦开始做PCIe转接、或者总线桥后面挂的设备需要中断路由interrupt-map就是绕不开的配置项。这个属性在RISC-V设备树里越来越多地出现因为很多RISC-V SoC都集成PCIe控制器。4. 实战在一块RISC-V板卡上配置一个带中断的外设接下来我以手头一块RISC-V双核板卡为例完整走一遍设备树中断路由的配置过程。硬件情况是这样一个外设按键模块中断线接在GPIO控制器第17号引脚上按下按键时产生一个上升沿。系统里已经有的设备树片段如下gpio0: gpio10002000 { compatible sifive,gpio0; reg 0x0 0x10002000 0x0 0x1000; interrupt-controller; #interrupt-cells 2; interrupts 4, 5, 6, 7; };GPIO控制器的interrupts属性声明了它占用了PLIC的4到7号中断源但注意这一段并不是用来描述“GPIO收到哪个引脚的中断”而是描述“GPIO控制器本身向PLIC上报中断时用的是哪个中断号”。这是中断级联里非常容易混淆的地方。4.1 确认硬件中断路径第一步要搞清楚硬件上的中断连接关系。按键的中断信号流向是按键引脚 - GPIO引脚17 - GPIO控制器内部中断逻辑 - PLIC全局中断源 - CPU0的S-mode外部中断对应到设备树就是按键节点要挂到GPIO控制器上用GPIO控制器的引脚号和触发方式。GPIO控制器节点要挂到PLIC上用PLIC的全局中断号。PLIC节点要挂到CPU intc上用异常号11。4.2 编写外设设备树节点下面这个节点是放到根节点下的一个按键设备key0 { compatible gpio-keys; #address-cells 1; #size-cells 0; status okay; button17 { label user-key; linux,code KEY_ENTER; interrupt-parent gpio0; interrupts 17 IRQ_TYPE_EDGE_RISING; }; };关键就两行interrupt-parent gpio0表示这个按键的中断信号送进GPIO控制器interrupts 17 IRQ_TYPE_EDGE_RISING表示用的是17号引脚上升沿触发。注意这里的中断号填写的是GPIO控制器的引脚号不是PLIC的全局中断号。因为GPIO控制器的#interrupt-cells是2第一段是引脚号第二段是触发类型。如果你填成PLIC的全局中断号驱动在request_irq阶段就会直接失败因为GPIO控制器里根本找不到这个中断源。4.3 级联场景下中断如何向上传递按键中断被GPIO控制器接收到以后GPIO控制器需要向PLIC上报。在设备树里GPIO控制器通过它自己的interrupts属性描述这个上报关系gpio0: gpio10002000 { compatible sifive,gpio0; reg 0x0 0x10002000 0x0 0x1000; interrupt-parent plic; interrupts 4; interrupt-controller; #interrupt-cells 2; };这里有两个容易出错的细节。第一个interrupt-parent plic不能少。如果漏掉GPIO控制器就不知道自己应该向哪个上层控制器上报中断。有些SoC在设备树的根节点上会写一个默认的interrupt-parent比如/ { interrupt-parent plic; };这时候子节点如果没指定interrupt-parent就会继承这个默认值。很多坑就是这么来的——你以为某个节点的interrupt-parent指向了正确的地方其实它沿用的是根节点的默认值。第二个GPIO控制器的interrupts 4只能描述一个中断源。但GPIO控制器可能有多组引脚需要分别上报所以一些SoC会给GPIO的每个中断组分配独立的PLIC中断号设备树里就会写多个interrupts 4, 5, 6, 7;这表示GPIO控制器内部有四组中断信号分别对应PLIC的4到7号。驱动的中断域irq domain会负责把这些组中断映射成具体的GPIO引脚中断。这部分逻辑由GPIO驱动和中断控制器驱动处理设备树层面只要保证中断号对应关系准确就行。4.4 从 /proc/interrupts 验证路由结果设备树改完编译、替换内核设备树镜像、重新启动之后可以用确认一下中断路由是否走通了。先看系统里有没有注册对应的中断cat /proc/interrupts正常情况下可以看到类似下面的输出CPU0 CPU1 4: 0 0 SiFive PLIC 4 Edge gpio0这说明PLIC的4号中断源已经被GPIO控制器驱动注册了。然后再按一下按键再看一次计数如果数字在涨说明GPIO控制器收到中断并且上报上去了。不过这里还有一个容易被忽略的环节GPIO子中断的注册是在GPIO驱动里完成的所以你还得确认按键对应的GPIO子中断有没有正确注册到系统中。这里可以通过/proc/interrupts里gpio0相关的条目查看不过键驱动注册之后通常会显示为gpio-keys或者按键对应的irq描述。不同内核版本显示方式不一样我一般习惯用中断调试接口来精确确认。5. 常见问题与排查技巧5.1 排查中断不触发的顺序遇到RISC-V设备树中断不触发我建议按下面的顺序排查这个顺序是从我实际调试中摸索出来的。第一步确认硬件中断号。打开SoC的数据手册或参考手册的中断事件表确认你的外设中断到底接的是PLIC的几号中断源。这一步不能省也不能只看设备树里别的主板是怎么写的因为同一个外设IP在不同SoC上的中断号经常不一样。第二步确认设备树属性完整。检查interrupt-parent有没有写、指向是否正确、#interrupt-cells是否和父节点匹配、interrupts里的数字数量和类型是否对得上。第三步确认中断控制器节点本身配置正确。PLIC节点有没有挂到CPU intc上interrupts-extended里写的异常号是不是11。如果PLIC没有连到CPU的S-mode外部中断外设中断配置得再正确也不会触发。第四步确认驱动有没有正确申请中断。设备树里中断路由对了驱动也要在初始化时调用platform_get_irq或者request_irq。这一步如果出错内核日志里通常会有irq ... nobody cared之类的提示。第五步打开内核中断调试选项比如CONFIG_DEBUG_IRQ用/proc/irq下的调试接口进一步确认中断是否进入内核。5.2 常见问题速查表现象最可能原因排查方法中断完全不触发外设节点interrupt-parent写错或漏写检查设备树节点确认phandle指向正确中断触发一次后不再触发触发类型和硬件实际不匹配电平触发写成边沿触发确认SoC PLIC是否支持电平触发必要时改用GPIO控制器中转系统启动时中断风暴触发类型配置为电平触发但硬件信号一直保持有效电平检查外部电路是否持续拉低/拉高中断线能注册中断但响应的是错误设备PLIC全局中断号写错对照SoC中断表核实中断号多核环境下中断总是集中在一个CPUPLIC context配置没有指定分发策略确认PLIC设备和CPU intc的interrupts-extended是否覆盖所有CPU级联外设中断丢失GPIO中断子域的触发方式与外设实际信号不匹配检查GPIO控制器的interrupt-cells定义和引脚号填写5.3 一些文档上不写的经验最后分享几条实际操作中总结出来的经验这些在标准文档里大多找不到但遇到问题的时候非常管用。第一尽量别给RISC-V的PLIC直连设备写边沿触发。很多PLIC实现按电平触发方式处理外部中断你在设备树里写IRQ_TYPE_EDGE_RISINGPLIC可能直接把它当高电平处理。如果外设信号确实是边沿最好经过GPIO这类二级中断控制器做一次转换。第二interrupts-extended比interrupt-extended更容易写错成别人的格式。RISC-V设备树里向上连接中断控制器的写法是interrupts-extendedpull on the s是复数形式加ed。我见过不少人在PLIC节点里写成interrupts-extend然后编译期不报错运行期就是收不到中断排查起来非常痛苦。第三设备树的interrupt-parent可以在多个层级继承。根节点、父节点、子节点都可以指定interrupt-parent子节点没写时会向上找最近的一个。这种继承机制方便但容易埋雷。建议在实际编写时给每个有中断的设备节点都显式写上interrupt-parent不要依赖继承。第四GPIO控制器同时作为中断控制器时它的interrupts属性和interrupt-controller子节点的关系要理清楚。GPIO控制器“消耗”的是PLIC中断号它自身“产生”的是引脚中断。设备树里前者用interrupts表示后者用#interrupt-cells和interrupt-controller声明。搞混这两层基本就是级联中断调试最常见的翻车现场。根据我个人的经验RISC-V设备树中断绑定这块最核心的其实是“中断信号路径”思维。每当你看到一个设备节点先不要急着查中断号是多少先在草稿纸上画出它的中断信号经过哪几个节点最后落到哪个CPU的哪个异常号上。路径画清楚了设备树怎么写、中断号怎么填都会变得特别自然。这种思维方式在我调试过的几乎所有RISC-V平台上都适用无论是单核还是多核无论PLIC还是APLIC底层逻辑都是相通的。
