驱动调试与中断处理故障定位实战工程 - 第2节
2. 中断处理入门
中断处理是操作系统响应硬件事件的基石。在 Linux 内核中，中断子系统被设计为高度模块化、可移植的层次结构，从上到下依次为：通用中断层 (Generic IRQ Layer)、中断控制器驱动层 (IRQ Controller Driver) 以及 硬件平台层 (Hardware)。理解这一架构是定位中断相关故障的前提。
核心观点： 中断子系统通过分层抽象，使得设备驱动开发者无需关心底层中断控制器的具体实现细节，只需通过标准 API 注册中断处理函数即可。
下图展示了 Linux 中断子系统的核心分层与数据流关系：
2.1.1 各层职责与数据流
| 层次 | 核心职责 | 关键数据结构/接口 |
|---|---|---|
| 设备驱动层 | 注册中断处理函数，处理设备特定事件 | request_irq(), free_irq(), irq_handler_t |
| 通用中断层 | 管理中断描述符，维护中断号映射，执行中断流控 | irq_desc, irq_domain, handle_irq() |
| 中断控制器驱动层 | 操作具体中断控制器寄存器，实现中断屏蔽/使能/应答 | irq_chip, irq_mask(), irq_unmask() |
| 硬件平台层 | CPU 中断接口，接收并传递中断信号给内核 | 异常向量表, arch_irq_handler |
调试提示： 当遇到“中断未触发”或“中断风暴”问题时，应首先确认中断号在
irq_domain 中的映射是否正确，这通常是硬件描述文件 (DT/ACPI) 配置错误导致的。
2.2 中断号与中断描述符
中断号 (IRQ Number) 是内核中唯一标识一个中断源的整数。它分为 硬件中断号 (hwirq) 和 Linux 中断号 (virq)。中断描述符 struct irq_desc 是中断子系统的核心管理单元，每个 virq 对应一个 irq_desc 实例。
2.2.1 中断号映射机制
现代 SoC 通常包含多个中断控制器（如 GIC、GPIO 控制器），硬件中断号与 Linux 中断号之间通过 irq_domain 建立映射。映射方式主要有三种：
- 线性映射 (Linear)：适用于硬件中断号连续且数量固定的场景，查找效率高。
- 树形映射 (Tree)：适用于硬件中断号稀疏或动态分配的场景，节省内存。
- 不映射 (No Map)：直接使用硬件中断号作为 Linux 中断号，用于简单平台。
2.2.2 中断描述符状态与生命周期
每个 irq_desc 在生命周期中会经历多个状态，理解这些状态对调试中断挂起、丢失或重复触发问题至关重要。
| 状态标志 | 含义 | 典型故障场景 |
|---|---|---|
IRQ_INPROGRESS | 中断正在被处理中 | 中断处理函数耗时过长，导致后续中断被合并或丢失 |
IRQ_DISABLED | 中断被软件屏蔽 | 驱动未正确调用 enable_irq()，导致中断无法触发 |
IRQ_MASKED | 中断被硬件控制器屏蔽 | 中断控制器驱动存在缺陷，未能正确应答中断 |
IRQ_WAKEUP | 中断可作为系统唤醒源 | 系统休眠后无法唤醒，检查 irq_set_irq_wake() 配置 |
常见陷阱： 在共享中断 (IRQF_SHARED) 场景下，如果某个驱动在中断处理函数中返回
IRQ_NONE 但未正确检查设备中断状态，会导致内核误判为“伪中断 (Spurious IRQ)”，最终可能禁用该中断号。
2.3 上半部与下半部机制
中断处理必须快速完成，以避免阻塞其他中断或导致系统延迟。Linux 将中断处理拆分为两个阶段：上半部 (Top Half) 和 下半部 (Bottom Half)。上半部在中断上下文中执行，要求原子操作、快速完成；下半部在软中断或进程上下文中执行，允许延迟处理。
2.3.1 上半部 (Hard IRQ Handler)
上半部是注册在 request_irq() 中的回调函数，运行在中断上下文，不可睡眠。其典型职责包括：
- 读取硬件状态寄存器，确认中断源。
- 清除设备中断挂起标志。
- 将关键数据从硬件 FIFO 拷贝到内存缓冲区。
- 调度下半部处理剩余工作。
2.3.2 下半部实现方式对比
Linux 提供了多种下半部机制，各有适用场景。选择不当会导致性能瓶颈或功能异常。
| 机制 | 执行上下文 | 可睡眠 | 适用场景 | 调试关注点 |
|---|---|---|---|---|
| 软中断 (SoftIRQ) | 软中断上下文 | 否 | 高吞吐、低延迟 (如网络 RX/TX) | 软中断占比过高会导致 ksoftirqd 满载 |
| Tasklet | 软中断上下文 | 否 | 简单、非紧急的后处理 | Tasklet 串行执行，不可在多 CPU 上并行 |
| 工作队列 (Workqueue) | 进程上下文 | 是 | 需要睡眠或持有锁的复杂操作 | 工作线程被阻塞会导致系统响应变慢 |
| 线程化中断 (Threaded IRQ) | 内核线程 | 是 | 驱动希望将整个处理过程线程化 | 线程优先级设置不当可能造成优先级反转 |
2.3.3 下半部选择决策树
在实际驱动开发中，可参考以下决策流程选择下半部机制：
- 处理函数是否需要睡眠？ 是 → 使用工作队列或线程化 IRQ；否 → 进入下一步。
- 是否对吞吐量和延迟有极高要求？ 是 → 使用软中断 (如网络驱动)；否 → 进入下一步。
- 处理逻辑是否简单且不需要并行？ 是 → 使用 Tasklet；否 → 考虑软中断或重新设计拆分。
实战建议： 对于大多数嵌入式设备驱动，线程化中断 (Threaded IRQ) 是最安全的选择。它通过
request_threaded_irq() 注册，将上半部精简为硬件确认，下半部在线程中完成所有复杂操作，有效避免了中断上下文中的死锁和调度延迟问题。