新板子拿回来外设中断死活不触发驱动代码翻了几遍设备树也改了又改最后发现连中断号都没映射对——这种事在BSP和驱动移植的日常里太常见了。很多刚转来做Linux驱动的人一上来就对着厂商SDK里的demo抄中断相关的代码能跑就完事一旦平台换了、内核版本升了或者中断控制器从GIC换成了别的立刻抓瞎。说到底缺的不是某段代码而是对中断子系统整体框架的认识。这篇文章就把这条链路从头到尾拆开硬件中断源怎么到CPU软件层怎么管理中断号irq_chip和irq_domain干的是什么活驱动里request_irq背后发生了什么以及移植时最容易踩的坑都在哪。适合正在做新平台驱动移植、老驱动跨内核版本迁移的工程师也适合想把中断机制真正搞明白的人。1. 中断子系统全景图从外设到CPU的一条完整链路1.1 硬件链路外设、中断控制器、CPU三级跳中断这件事硬件上不是外设直接把一根线连到CPU引脚就完事。现代SoC里外设数量几十上百中断源也多所以中间一定有一个中断控制器做汇聚和仲裁。以ARM平台最常见的GICGeneric Interrupt Controller为例外设产生中断信号沿中断线送到GIC的distributor侧GIC根据优先级、使能状态、CPU亲和性配置决定把这个中断分发给哪个CPU核然后CPU核才会通过异常向量表进入中断处理流程。GIC的中断源分成三类SGISoftware Generated Interrupt用于核间通信PPIPrivate Peripheral Interrupt是每个CPU核私有的比如CPU核自己的定时器、温度传感器这类SPIShared Peripheral Interrupt才是大家平时打交道最多的共享外设中断串口、网卡、I2C、SPI控制器基本都挂在SPI上。这个分类直接影响设备树里interrupts属性的写法后文会专门讲。在实际移植中链路任何一个环节断了都不行。我遇到过一种情况硬件工程师把某个外设的中断信号接到了GIC的某个SPI上但SoC参考设计里这个SPI又被别的模块占着结果两个设备往同一个中断号上凑驱动一注册就冲突。这种问题不把“外设——GIC——CPU”整条硬件路径理清楚光靠软件层面查非常难定位。所以第一步永远是看原理图和SoC手册确认外设中断到底挂在哪个控制器、哪个通道上。1.2 软件链路genirq、irq_chip、irq_domain、设备驱动四层分工硬件链路是三段软件链路分层更细但核心可以归纳成四层。第一层是中断控制器驱动它要和硬件寄存器直接打交道注册一个irq_chip结构体提供mask、unmask、ack、set_type这类底层回调。第二层是irq_domain负责把硬件中断号“翻译”成Linux全局的逻辑中断号irq number。第三层是内核通用中断框架也就是kernel/irq/目录下那套genirq代码它管理irq_desc、action链表、中断状态机这些和具体硬件无关的逻辑。第四层才是设备驱动用request_irq注册中断处理函数处理具体的业务。一次完整的中断从触发到处理完流程大致是外设拉高或拉低中断线GIC检测到后把中断号放进CPU interface的IAR寄存器CPU跳转到异常向量表内核读取IAR取得hwirq通过irq_domain换算成Linux中断号找到对应的irq_desc调用该irq_desc上注册的流处理函数handle_irq流处理函数再遍历action链表逐个调用设备驱动挂上来的handler。如果handler里标记了下半部还会触发softirq或tasklet等中断上下文退出后再执行。理解这个流程对排查问题的意义在于你能判断当前卡在哪一层。如果/proc/interrupts里中断计数一直不涨问题可能在硬件信号没到GIC也可能在irq_domain映射不对如果计数在涨但handler没执行到你的打印语句问题可能在action链表上比如你的handler根本没注册成功或者被别的处理函数抢在前面。2. 驱动移植最容易翻车的环节中断号与irq_domain映射2.1 设备树里的interrupts属性到底怎么读设备树对中断的描述几乎每个平台都不一样这恰恰是移植时第一个大坑。最常见的ARM GIC写法是这样uart0 { status okay; interrupts GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH; };三个cell分别是中断类型GIC_SPI还是GIC_PPI、中断编号、触发类型。GIC_SPI后面这个32许多人以为是GIC硬件中断号就是32拿着手册去对发现手册上写的UART0中断号可能是64瞬间懵了。这里的门道在于GIC手册里把中断编号编成了统一空间SGI占0到15PPI占16到31SPI从32开始编号。设备树里写GIC_SPI 32其实说的是“SPI类型里的第32号”落到GIC硬件中断号上就是32加32等于64。而irq_domain映射时用的hwirq到底偏不偏取决于GIC驱动怎么实现。不同厂商的GIC驱动有的可能在映射时做偏移有的直接用统一编号这就导致同一个设备树在不同内核版本上拿到的中断号不一样。我建议移植时别凭记忆猜直接做两件事一是看参考板子的设备树厂商验证过的写法比手册靠谱二是在内核起来以后用下面的命令看看设备真正拿到的中断号cat /proc/interrupts以及cat /sys/kernel/debug/irq/irqs/xxx把设备树里的interrupts和实际运行时的irq号对一遍能少走很多弯路。2.2 irq_domain的映射机制与hwirq换算irq_domain本质是一张翻译表输入是硬件中断号hwirq输出是Linux逻辑中断号irq number。内核里有好几种domain实现常见的包括线性映射linear domainhwirq直接当作数组下标适合中断号连续且不多的情况GIC这类控制器常用。基数树映射radix tree domain支持稀疏的hwirq映射适合中断号不连续的中断控制器。级联映射hierarchy domain支持父子控制器嵌套比如GPIO控制器挂在GIC下面GPIO的某个bank的某个引脚要通过两级domain才能翻译成最终irq号。映射的时机也有讲究。有些domain在初始化时一次性把全部中断号都映射完GIC就是这样也有懒映射的设备驱动第一次request_irq时才创建映射。这个差异会造成一种现象驱动probe之前/proc/interrupts里可能看不到某些中断号这不一定是坏事只是还没映射。对于挂在GPIO控制器上的中断hwirq的换算更绕。比如一个GPIO控制器有4个bank每个bank 32个引脚设备树里interrupts gpio2 5 IRQ_TYPE_EDGE_FALLINGhwirq可能就要算成2乘以32加5。gpiolib的irq_domain会自动处理这层换算但前提是设备树里interrupt-parent指对了GPIO控制器而且控制器驱动注册了irq_domain。曾经有个项目设备树interrupt-parent写成了gpio1实际硬件接在gpio2上中断自然全乱套。2.3 三个经典的错位案例案例一platform_get_irq返回的数字和预期对不上。设备驱动用platform_get_irq拿中断号返回的其实是Linux逻辑中断号。假设设备树写的是GIC_SPI 32 ...在某个GIC驱动实现下返回的可能是64而不是32。新手一看返回值不对以为是驱动没配对其实是因为hwirq经过了GIC的偏移。案例二中断号写错了一位。设备树里多写一个或少写一个数字中断可能就串到别的外设上去了。表现是注册A设备的中断后B设备一工作A的handler也被调用而且/proc/interrupts里两个设备挂到同一个irq号上。排查方向应该先看设备树把interrupts属性和硬件手册逐一比对。案例三级联的中断控制器没注册父domain。GPIO控制器挂在GIC下面如果GPIO控制器的irq_domain没有正确指定parent或者父domain初始化顺序不对子中断永远路由不上去。解决办法是检查设备树里GPIO控制器的interrupt-parent是否指向GIC节点同时确认内核启动日志里irqchip的初始化顺序是否正常。3. 中断控制器驱动irq_chip和handle_irq是底层的两块基石3.1 irq_chip回调逐个说每个中断控制器驱动都要填充一个irq_chip结构体注册到对应的irq_desc上。这个结构体提供的回调函数相当于中断控制器硬件操作的“接口抽象”。平时移植最常打交道的几个回调struct irq_chip { const char *name; void (*irq_mask)(struct irq_data *data); void (*irq_unmask)(struct irq_data *data); void (*irq_ack)(struct irq_data *data); void (*irq_set_type)(struct irq_data *data, unsigned int flow_type); int (*irq_set_wake)(struct irq_data *data, unsigned int on); int (*irq_set_affinity)(struct irq_data *data, const struct cpumask *dest, bool force); };irq_mask和irq_unmask负责屏蔽和使能某一条中断。GIC里的实现就是去操作distributor的使能寄存器一个bit控制一路中断。irq_ack用于应答中断GIC里通常在读IAR寄存器时已经顺带完成了ack。irq_set_type是设置触发方式电平触发还是边沿触发高电平还是低电平上升沿还是下降沿。irq_set_wake配置中断能否把系统从休眠中唤醒做低功耗时特别关键。irq_set_affinity则决定这个中断发给哪个CPU核对性能调优有用。这里有一个必须牢记的原则irq_chip里的所有回调都在中断上下文或关闭本地中断的上下文中执行绝对不能睡眠。别在mask/unmask里加mutex别调kmalloc(GFP_KERNEL)否则就是现成的内核crash现场。我看到有人为了调试方便在irq_ack里加了个printk结果打印太慢导致中断风暴系统直接卡死这类教训一次就能让人长记性。3.2 中断流处理函数handle_irq不同类型的不同“消费”方式irq_desc里有一个handle_irq成员它决定了某一条中断在软件层面的“消费方式”。同样是中断来了电平触发和边沿触发在软件上处理策略完全不同。handle_level_irq电平触发专用。中断处理期间会先把中断mask掉防止同一个中断在handler还没处理完时再次触发处理完再unmask。刚进入handler时需要判断当前是否还有pending中断。handle_edge_irq边沿触发专用。硬件边沿是瞬时的软件要在第一次触发时记录pending状态防止在mask期间漏掉边沿。如果边沿来了但mask中irq_pending会被置位unmask后再次进入处理。handle_fasteoi_irq快速EOI型GIC这类支持EOI机制的中断控制器常用。进入处理时不需要显式ack读完IAR已经相当于ack了处理完要写EOIR告诉硬件处理结束。handle_simple_irq最简化的处理流程适合那些硬件行为很“直白”的中断控制器。GIC为什么偏好handle_fasteoi_irq因为GIC在CPU interface层面读到IAR的那一刻硬件已经认为中断被应答了不需要软件再去ack一次。如果误用了handle_level_irq电平触发的中断可能会重复进入在/proc/interrupts里看到计数飞快增长CPU占用被中断打满系统看起来像死机了一样。3.3 GIC驱动初始化流程梳理中断控制器驱动的初始化时间点非常早通常在设备驱动probe之前。GIC驱动的初始化大致走这几步解析设备树中GIC节点的寄存器地址初始化distributor和CPU interface创建irq_domain把每个中断源对应的irq_desc设置好irq_chip和handle_irq最后注册一个全局的中断入口处理函数。内核里有个irqchip_init机制会遍历设备树里所有compatible为interrupt-controller的节点按依赖顺序初始化。所以设备树里GIC节点必须是interrupt-controller而且interrupt-controller节点的位置、phandle引用不能出错。很多新人在裁剪设备树时把GIC节点删了或者没加interrupt-controller属性结果整个内核起来后所有中断全废一个irq都注册不上问题极其隐蔽。移植时如果是在旧内核上适配新平台还要检查irq_domain的创建方式。老内核里可能直接用irq_domain_add_linear新内核推荐用irq_domain_create_hierarchy或者带fwnode的方式。API变了写法和行为都会有差异照抄老代码经常编不过。4. 驱动侧请求中断request_irq背后发生了什么4.1 request_irq、request_threaded_irq的选用逻辑设备驱动请求中断最常用的是request_irqint request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags, const char *name, void *dev);这个函数背后干了不少事先检查irq号是否有效irq_desc上有没有初始化好的irq_chip然后创建或者复用irqaction把handler挂到action链表上再根据flags配置中断触发类型。如果中断号无效返回-EINVAL如果中断被独占且设置了IRQF_SHARED不匹配返回-EBUSY。问题在于很多驱动场景下handler里需要访问慢速设备比如在GPIO中断里通过I2C去读触摸屏的坐标或者在外设中断里等待硬件完成某个操作。这些都可能需要睡眠但中断上下文不允许睡眠。这时就要用request_threaded_irqint request_threaded_irq(unsigned int irq, irq_handler_t handler, irq_handler_t thread_fn, unsigned long flags, const char *name, void *dev);handler是上半部跑在中断上下文要求快速返回thread_fn是下半部内核会为它创建一个线程跑在进程上下文可以睡眠。很多驱动直接用request_threaded_irq(irq, NULL, my_thread_fn, ...)只提供thread_fn上半部由内核默认处理irqaction的handler是irq_default_primary_handler直接返回IRQ_WAKE_THREAD唤醒线程。4.2 上半部与下半部的拆分写中断处理函数时先想清楚哪些事必须立刻做哪些可以缓一缓。必须立刻做的比如从FIFO里读数据防止硬件溢出、清设备中断标志、更新硬件状态这些放上半部。可以延后做的比如数据解析、协议处理、通知用户态这些放下半部。内核提供几种下半部机制各有使用场景softirq处理时机最早执行在中断返回路径上不能睡眠网络收发路径大量使用普通驱动一般不直接碰。tasklet基于softirq实现的机制推后执行不能睡眠适合比较快、不宜延迟太多的处理。workqueue在工作线程里执行进程上下文可以睡眠适合耗时操作。threaded irq直接为中断创建一个内核线程简单直观适合那些handler本身就要做较多处理的驱动。选择建议很直接handler里只需要做少量快速操作就用普通request_irqhandler里要访问慢速总线或可能睡眠就用request_threaded_irq如果不希望中断处理抢CPU太多时间可以选择把大量逻辑放到workqueue。很多驱动项目犯的错误是所有事情都在硬中断里做完包括耗时的大块数据拷贝和解析导致中断占用时间过长影响系统实时性。正确做法是上半部只做“最小必要操作”把剩余工作推到下半部。4.3 flags参数与设备树触发类型的配合request_irq的flags里有一组触发类型选项IRQF_TRIGGER_RISING、IRQF_TRIGGER_FALLING、IRQF_TRIGGER_HIGH、IRQF_TRIGGER_LOW另外还有IRQF_SHARED共享中断、IRQF_ONESHOT等。一个常见的坑设备树里已经通过interrupts属性指定了触发类型驱动代码里又在flags里指定类型两者一旦冲突就会出问题。GIC这类控制器在设备树解析时就会调用irq_set_type配置硬件驱动里再传一个不同的IRQF_TRIGGER_*轻则触发类型被覆盖重则内核报WARNING。我建议的做法是设备树里写清楚触发类型驱动代码里flags直接用0或者只加IRQF_SHARED这类非触发型标志触发类型完全交给设备树管理。这样既符合设备树描述硬件的设计思想也减少一处出错的可能。IRQF_SHARED还有一个细节共享中断的所有设备必须都设置IRQF_SHARED标志而且request_irq的dev_id参数绝对不能传NULL。dev_id是共享时区分不同设备的关键内核在handler里会用这个参数回调对应的处理函数。多个设备共享同一个irq号时如果dev_id传NULL中断来了内核没法判断是哪个设备触发的共享机制就失效了。5. 移植调试实录三次真实的排查过程5.1 排查方法总流程从哪里下手最快中断不工作别急着改代码按顺序做这几步第一步硬件层面确认。看原理图外设中断信号接到了中断控制器的哪个通道电平极性对不对是否经过电平转换芯片。第二步查看中断是否分配成功。执行cat /proc/interrupts看对应的irq号是否存在设备名是否注册触发次数是否是0。第三步确认handler是否被挂上。执行cat /sys/kernel/debug/irq/irqs/xxx能看到irq_desc详细信息包括chip name、handler name、action链表里的设备。第四步抓trace确认中断触发路径。使能irq事件跟踪echo 1 /sys/kernel/debug/tracing/events/irq/irq_handler_entry/enable echo 1 /sys/kernel/debug/tracing/events/irq/irq_handler_exit/enable cat /sys/kernel/debug/tracing/trace看到irq_handler_entry说明硬件中断已经到达内核irq_handler_exit说明handler已经执行完这两条之间看不到你的设备说明handler没被调用。第五步如果以上都正常问题就在中断上下文之外比如下半部没有正确调度或者设备的中断状态没有清干净。这套流程走一遍绝大多数中断问题都能定位到具体层次不会一头扎进代码里瞎猜。5.2 实录一GPIO按键中断不触发问题出在触发类型某个项目里GPIO按键按下无反应。先看/proc/interrupts按键对应的irq号存在但计数一直是0。说明中断从来没有从硬件上来问题不在软件handler而在硬件触发条件不满足。用示波器量GPIO引脚按下按键时电平确实变化了而且变化方向是下降沿。再看设备树写的是interrupts IRQ_TYPE_LEVEL_LOW;这里配置成了低电平触发而按键按下只是一瞬间的下降沿不是持续低电平所以中断控制器根本没捕获到稳定的低电平。把触发类型改成IRQ_TYPE_EDGE_FALLING后中断正常。这个案例很典型原理图上的“按下接地”很容易让人想当然配成低电平触发但按键的机械特性决定了它是一个脉冲应该用边沿触发。触发类型配错是GPIO中断类问题里最高频的故障。5.3 实录二中断风暴另一个设备抢了我的中断还有一次是MIPI CSI摄像头中断把系统CPU占到99%看起来像死机。打开/proc/interrupts发现中断计数暴涨每秒几万次而irq号上挂的不是摄像头驱动而是另一个模块。展开action链表排查发现两个设备在设备树里被配到了同一个SPI中断上其中一个驱动没有正确清除硬件pending标志中断服务返回后中断线仍然有效导致中断反复触发形成风暴。处理办法分两步第一步临时把嫌疑设备的handler直接返回IRQ_NONE不处理逐个验证谁在捣乱第二步根据硬件手册修改清pending的代码确保每次中断处理完毕设备侧的中断状态寄存器确实被写回清零。这里要强调一个细节电平触发的中断设备侧的中断清标志动作尤其重要。很多外设的中断状态寄存器是写1清除的驱动里如果用了写0的方式标志永远清不掉中断就一直触发。这种问题在共享中断里最容易被忽略因为你会看到别人的handler在跑但其实是你的设备没清干净。5.4 实录三休眠唤醒失效irq_set_wake被漏掉了做低功耗适配时一个外设要从suspend状态唤醒系统但发现唤醒不生效。排查过程很有意思cat /proc/interrupts中断号正常唤醒源配置也写了suspend也能进入。但就是外部事件来了系统不醒。最后发现是中断控制器驱动在系统suspend时会把大多数中断mask掉只有调用了irq_set_wake的中断才会被保留使能。而设备驱动里只注册了request_irq没有调用enable_irq_wakeenable_irq_wake(irq);漏掉这一步中断在suspend时就被mask了外部事件自然无法唤醒系统。对应的禁用唤醒时调用disable_irq_wake。这个点很容易被忽略因为它在正常运行时看不出任何影响只有实测suspend/resume才能暴露。6. 中断子系统移植避坑速查6.1 高频问题速查表现象可能原因排查手段request_irq返回-EINVALirq号无效或者irq_desc还没配置好irq_chip检查设备树interrupts属性看/proc/interrupts里有没有这个号request_irq返回-EBUSY中断被独占且未设置IRQF_SHARED查看该irq号上已注册的设备确认共享标志中断只触发一次后不再触发电平触发中设备未清pending标志读取设备中断状态寄存器按硬件手册写1清除中断计数暴涨系统卡顿中断风暴通常是共享中断某个设备没清状态或者没mask查看action链表用IRQ_NONE逐个排除内核报scheduling while atomichandler里调用了可能睡眠的函数改用request_threaded_irq或把慢速操作移到workqueue系统无法被外部事件唤醒缺少enable_irq_wake或设备树唤醒源配置不对检查驱动是否调用enable_irq_wake查看唤醒源配置同一个中断被多个设备同时触发设备树中断号重复或者hwirq映射错误逐个比对原理图和设备树查看irq_domain映射6.2 几条BSP老手的独家经验经验一中断控制器驱动的移植永远排在外设驱动之前。新平台bring-up时先把GIC或GPIO中断控制器跑通确认所有PPI和关键SPI都能正确映射再去做外设驱动。顺序反了遇到问题你会分不清是控制器没弄好还是外设驱动写错。经验二中断号绝对不要硬编码。驱动里用platform_get_irq或of_irq_get拿中断号而不是从某个旧平台代码里抄一个数字下来。硬编码的后果是换平台或者改设备树后中断号错位时间全耗在排查上。经验三调试中断时先加dynamic_debug而不是printk。在irq_chip回调里无脑加printk等于给中断处理函数人为加了巨大延迟。尤其在高频中断场景下printk会让中断处理慢到触发电平中断风暴。正确做法是用pr_debug然后在需要时打开dynamic_debug。经验四设备树里interrupt-parent一定要检查清楚。一个设备只能有一个有效的中断父节点多个interrupt-parent混用或者指错映射一定乱。裁剪设备树时砍掉一个节点后顺手把别的节点里对它的phandle引用也处理掉否则残留的引用会让中断解析失败。经验五遇到中断问题先看两层信息再谈改代码。第一层是/proc/interrupts第二层是/sys/kernel/debug/irq/。这两层看完问题范围能收敛到很小。千万不要拿着驱动代码从头读到尾那样效率太低。经验六驱动卸载时释放中断记得传和request时一样的dev_id。否则资源共享和释放都会出问题。还要配合free_irq的时机避免中断处理函数还在跑时模块已经被卸载造成use-after-free。我个人在实际操作中最深的体会是中断子系统框架本身并不复杂复杂的是它跨越了硬件和软件两层任何一个环节的理解有偏差都会表现为千奇百怪的症状。把框架整体图刻在脑子里——外设、中断控制器、irq_domain、irq_desc、action链表、下半部再配合/proc/interrupts和trace这套排查手段移植路上绝大多数中断问题都能在半小时内定到根因。最后一个小建议新板子第一次跑起来别急着优化先把所有外设中断按默认方式注册一遍打印出各自的irq号、触发类型和handler地址留一份完整的映射存档。这活儿看起来不起眼但在后续调试中能帮你省下大把时间。