硬件和软件的一个重要桥梁:浅谈Linux的中断子系统

仓库地址：https://github.com/Awesome-Embedded-Learning-Studio/imx-forge

静态网页：https://awesome-embedded-learning-studio.github.io/imx-forge/

看着还行？笔者还在优化中！

现在我们具体看看 Linux 的中断子系统是怎么工作的。说实话，中断这个概念在操作系统里挺复杂的，但在驱动开发层面，我们需要掌握的核心 API 其实不多。把这几个 API 用熟了，大部分中断相关的驱动都能搞定。

中断是什么

中断就是计算机系统中一种非常重要的机制，用于处理突发事件或优先级较高的任务。你可以把它想象成一个紧急通知系统。当某个硬件设备或软件需要处理紧急任务时，它会向处理器发送一个中断信号，告诉处理器：“嘿，有重要的事情需要你马上处理！”处理器收到这个信号后，会暂时停下当前的工作，保存好当前的进度，然后去处理这个紧急任务。处理完之后，处理器会回到之前的工作，继续从刚才停下的地方开始。

中断机制的好处是能让计算机同时处理多个任务，并且能及时响应外部设备的请求，比如键盘输入、鼠标点击或者网络数据的到达。如果没有中断，计算机可能会一直忙于某个任务，无法及时响应其他需求，效率会大大降低。值得一提的是——中断自身存在一个优先级衡量，如果在处理中断做响应的时候还发生了更加高优先级的请求，那还的继续脱离出去直接跑过去执行更加高级的中断响应。（这个部分是我在自己手撕操作系统的时候写的，这个地方上我认为可以复用一下~）

GPIO 中断配置

在 i.MX 系列处理器上，GPIO 可以配置成中断源。我们需要配置两件事：触发方式和中断处理函数。

触发方式指的是在什么条件下触发中断：

#define IRQF_TRIGGER_RISING    0x00000001  // 上升沿触发
#define IRQF_TRIGGER_FALLING   0x00000002  // 下降沿触发
#define IRQF_TRIGGER_HIGH      0x00000004  // 高电平触发
#define IRQF_TRIGGER_LOW       0x00000008  // 低电平触发

对于按键这种设备，我们通常用边沿触发，因为按键状态变化是我们关心的。上升沿对应按键松开（如果硬件设计是松开为高电平），下降沿对应按键按下。

我们的驱动用双边沿触发，这样按键按下和松开都能检测：

unsignedlong irq_flags = IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING;

电平触发适合那些需要持续监控的信号，比如外部设备的"忙"信号。边沿触发适合状态变化事件，比如按键、传感器信号。对于按键，边沿触发是更好的选择，因为我们只关心状态变化的那一刻。

从 GPIO 到中断号

GPIO 子系统和中断子系统是紧密集成的。我们可以通过 GPIO 描述符获取对应的中断号：

int irq = gpiod_to_irq(gpio);
if (irq < 0) {
    pr_err("Failed to get IRQ for GPIO: %d\n", irq);
return irq;
}

gpiod_to_irq() 这个函数会在 GPIO 的 irqchip 里查找对应的中断号。如果成功，返回一个正整数（中断号）；如果失败，返回一个负的错误码。

说实话，这个函数的名字可能会让人困惑。它不是真的"转换"什么东西，而是查找 GPIO 对应的中断号。在硬件层面，每个 GPIO（或者一组 GPIO）都对应一个中断线，这个函数就是找出那个中断线的编号。

注册中断处理函数

拿到中断号之后，我们就可以注册中断处理函数了：

ret = devm_request_irq(dev, irq, key_irq_handler, irq_flags,
"imxaes_key_debounce", dev);
if (ret < 0) {
    pr_err("Failed to request IRQ %d: %d\n", irq, ret);
return ret;
}

我们用的是 devm_request_irq()，这是 request_irq() 的托管版本。devm_ 前缀代表"managed resource"，当设备卸载时，内核会自动释放这个中断。不用 devm_ 版本的话，你得在 remove 函数里手动调用 free_irq()，很容易忘。

参数说明：

• dev
  ：设备指针，用于资源管理
• irq
  ：中断号，就是我们刚才用 gpiod_to_irq() 获取的
• key_irq_handler
  ：中断处理函数指针
• irq_flags
  ：中断标志，包括触发方式
• "imxaes_key_debounce"
  ：中断名称，会出现在 /proc/interrupts 里
• dev
  ：传递给中断处理函数的私有数据

你可以通过 /proc/interrupts 文件查看系统中断的统计信息：

cat /proc/interrupts | grep imxaes

这会显示你的驱动触发了多少次中断，调试时很有用。

中断处理函数

中断处理函数是整个中断机制的核心。它的签名是固定的：

staticirqreturn_tkey_irq_handler(int irq, void *dev_id)
{
structkey_debounce_dev* dev = dev_id;

/* 递增中断计数器 */
atomic_inc(&dev->irq_count);

/* 调度工作队列进行消抖处理 */
    schedule_work(&dev->work);

return IRQ_HANDLED;
}

这个函数的第一个参数是中断号，第二个参数是我们在注册时传递的私有数据（dev）。返回值是 irqreturn_t 类型，有两个可能的值：

typedefenumirqreturn {
    IRQ_NONE        = 0,    // 不是这个设备的中断
    IRQ_HANDLED     = 1,    // 已处理
} irqreturn_t;

中断处理函数运行在中断上下文中，这一点从 MCU 开发过来的朋友应该非常熟悉：中断不是普通线程，它不是“想干什么就干什么”的执行环境，而是一段被硬件异步打断后临时插入进来的代码。因此它有很多非常严格的约束。

第一个事情：中断上下文里不能睡眠。也就是说，不能调用 msleep()、schedule() 这一类会主动让出 CPU 的函数，也不能调用 mutex_lock() 这类在拿不到锁时可能睡眠等待的接口。中断处理函数没有普通进程上下文的调度语义，一旦在这里睡眠，就等于让内核在一个不该阻塞的地方阻塞，轻则触发 “sleeping function called from invalid context” 之类的告警，重则导致系统卡死甚至 panic。

这个不费劲吧各位朋友，你可以试试看在您玩STM32的时候的中断HAL_Delay同步阻塞一下，我估计你的同事会提刀找你的（笑）

其次，中断处理函数里也不能调用那些内部可能睡眠的函数。这一点比“不要手写 msleep()”更容易踩坑，因为有些 API 表面上看只是普通函数调用，但内部可能申请内存、等待锁、访问设备、触发 I/O，最终都会导致睡眠。所以在中断处理函数里调用任何内核接口，都要确认它是否允许在 atomic context / interrupt context 中使用。比如内存分配时不能随便用 GFP_KERNEL，因为它可能睡眠；如果确实要在中断中分配内存，也只能考虑 GFP_ATOMIC 这类不会睡眠的方式，但这通常也不应该成为常态。

再次，中断处理函数必须尽可能快地执行完。中断来了以后，CPU 会优先处理这段代码。如果中断处理函数里做了大量计算、复杂逻辑、长时间轮询，或者直接在里面处理完整业务流程，就会影响系统对其他中断和任务的响应。对于 Linux 驱动来说，比较推荐的做法是：在中断上半部里只完成最必要的事情，比如读取状态寄存器、确认中断来源、清除中断标志、保存少量现场信息，然后把耗时操作丢给下半部机制处理，比如 threaded irq、workqueue、tasklet 或 softirq。换句话说，中断处理函数应该像“门铃响应器”，而不是完整的业务处理中心。

最后，中断处理函数里不能直接访问用户空间内存。这一点和 MCU 开发相比需要额外注意，因为 Linux 有用户态和内核态的地址空间隔离。中断发生时，并不一定有一个明确、可靠的用户进程上下文可以使用；即使当前 CPU 上恰好正在运行某个进程，也不能认为它的用户空间地址在中断里可以随便访问。像 copy_from_user()、copy_to_user() 这类接口，本质上是面向进程上下文设计的，可能触发缺页异常或睡眠等待，因此不应该放在普通硬中断处理函数里执行。驱动如果需要和用户空间交换数据，通常应该在 read()、write()、ioctl()、poll() 等文件操作接口中完成，而不是在中断函数中直接处理。（仔细一想，这的确就是，内核只在必要的时候跟用户进行交互）

所以，中断处理函数的基本原则可以概括为一句话：只做必须立刻做的事情，其他事情全部延后处理。违反这些约束，轻则出现内核告警、系统响应变慢、偶发卡顿，重则造成死锁、数据竞争、调度异常，甚至直接把系统打到 panic。对于驱动开发者来说，真正要建立的习惯不是“中断里能不能写某几行代码”，而是看到任何可能阻塞、可能等待、可能访问用户空间、可能耗时的操作时，都要本能地把它从中断上下文中移出去。

中断共享

Linux 支持中断共享，多个设备可以共享同一个中断线。这就是为什么中断处理函数需要返回值——如果返回 IRQ_NONE，内核会把中断传给下一个共享这个中断的处理器。

在注册共享中断时，需要设置 IRQF_SHARED 标志：

request_irq(irq, handler, IRQF_SHARED, "name", dev);

共享中断时，所有注册的处理器都会被调用，每个处理器需要判断是否是自己的中断。如果不是，返回 IRQ_NONE。GPIO 中断通常不需要共享，因为每个 GPIO 有自己独立的中断号。但在 PCI 设备中，中断共享很常见，因为多个设备可能连接到同一个 IRQ 引脚。（但是笔者玩的少，这个是查的资料。这样说的）

中断处理的时机

你可能会问，中断处理函数什么时候被调用？是在中断触发后立即调用吗？

答案是：几乎立即。中断触发后，CPU 会完成当前指令，然后保存当前状态，跳转到中断处理函数。这个过程通常在几微秒内完成。

但要注意的是，中断处理函数运行在中断上下文，而不是进程上下文。这意味着：

• 它没有进程控制块（没有 current 指针）
• 它不能被调度（不能睡眠）
• 它运行在高优先级，会打断普通进程

内核的中断管理

在内核内部，中断管理比我们看到的要复杂得多。request_irq() 最终会调用到中断核心代码，在 /kernel/irq/manage.c 里：

intrequest_threaded_irq(unsignedint irq, irq_handler_t handler,
irq_handler_t thread_fn, unsignedlong irqflags,
constchar *devname, void *dev_id)
{
/* 分配 irq_desc 结构 */
/* 设置 handler 和 thread_fn */
/* 启用中断线 */
/* ... */
}

内核维护了一个 irq_desc 数组，每个中断号对应一个 irq_desc。这个结构体包含了中断的所有信息：处理函数、状态、锁等。当硬件触发中断时，内核会查找对应的 irq_desc，调用注册的处理函数。

顶半部和底半部

你可能会听到"顶半部"（top half）和"底半部"（bottom half）这两个词。这是 Linux 中断处理的一种设计模式。

顶半部就是中断处理函数本身，必须快速执行，不能睡眠。底半部可以推迟执行，可以睡眠，可以做耗时操作。

我们的驱动就是典型的顶半部/底半部分离：

• 顶半部：中断处理函数，只是调度一个工作队列
• 底半部：工作队列处理函数，延时读取 GPIO，报告事件

// 顶半部（中断处理函数）
staticirqreturn_tkey_irq_handler(int irq, void *dev_id) {
    schedule_work(&dev->work);  // 只是调度，立即返回
return IRQ_HANDLED;
}

// 底半部（工作队列处理函数）
staticvoidkey_work_handler(struct work_struct *work) {
    msleep(20);  // 可以睡眠！
// 做实际的处理...
}

如果你的中断处理需要做以下事情之一，就需要底半部：

1. 耗时操作（超过几十微秒）
2. 需要睡眠（比如等待互斥锁）
3. 需要访问可能睡眠的 API

对于按键这种低速设备，几乎总是需要底半部的。

中断的调试技巧

中断相关的问题有时候很难调试，因为涉及到硬件和时序。这里有几个实用的技巧：

1. 查看中断统计
   ：

cat /proc/interrupts

这会显示每个中断线的触发次数，可以用来验证中断是否真的触发了。

1. 打印调试
   ： 在中断处理函数里加个打印：

pr_info("IRQ %d triggered\n", irq);

但要注意，打印操作本身很慢，不要在生产代码里保留。

1. ftrace 追踪
   ： 内核的 ftrace 可以追踪中断的延迟：

echo 1 > /sys/kernel/debug/tracing/events/irq/enable
cat /sys/kernel/debug/tracing/trace

::: warning 调试中断的坑 别在中断处理函数里加太多打印，这会让系统变慢甚至死锁。中断处理函数必须快速返回，打印操作可能需要几十微秒，对于高频中断来说是不可接受的。 :::

本章小结

这一章我们深入了解了 Linux 的中断子系统。核心 API 其实就两个：gpiod_to_irq() 获取中断号，devm_request_irq() 注册中断处理函数。中断处理函数必须快速返回，不能睡眠，所以我们需要用工作队列来实现底半部，做实际的处理。

中断机制是操作系统里的经典设计，它解决了硬件事件如何及时通知 CPU 的问题。Linux 的中断子系统经过了多年演进，既保证了性能，又提供了简洁的 API。理解这个机制，对于编写高效的驱动程序至关重要。

下一章我们会详细讲工作队列机制，看看为什么中断里不能睡眠，以及如何安全地推迟执行。