按键驱动看似简单，要写得稳却得跨过两道坎：机械抖动让一次按压变成一串中断、并发访问让共享数据随时可能被踩烂。本文把消抖算法（延时读取 + 状态比较）和同步机制（自旋锁 / 等待队列 / 原子变量）合在一起，顺着工作队列的执行路径一次讲透。
第一部分 · 消抖算法
前面几章我们讲了中断子系统和工作队列机制，现在终于可以开始实现真正的消抖算法了。这个算法的原理非常简单，但实现细节上有很多需要注意的地方。
消抖的核心思想
消抖的核心思想就一句话：等待抖动结束后再读取 GPIO。
机械按键在按下或松开的瞬间，触点会有一段时间的抖动。如果在这个抖动期读取 GPIO，可能会读到错误的值。更糟糕的是，抖动会触发多次中断，导致应用程序收到一堆无意义的事件。
解决方法是：当中断触发时，我们不立即读取 GPIO，而是等一段时间（比如 20ms），让抖动自然结束，然后再读取。这时候读到的值就是稳定的按键状态。
// 工作队列处理函数
static void key_work_handler(struct work_struct* work) {
msleep_interruptible(DEBOUNCE_MS); // 等待抖动结束
int state = key_get_state(gpio); // 读取稳定的状态
// 报告事件...
}
💡 20ms 从哪来
20ms 是一个经验值，大部分机械按键的抖动期在 5-20ms 之间。你可以根据实际按键的特性调整这个值。太短可能消抖不干净，太长会影响响应速度。
工作处理函数的完整实现
让我们看一下完整的工作处理函数：
static void key_work_handler(struct work_struct* work)
{
struct key_debounce_dev *dev =
container_of(work, struct key_debounce_dev, work);
int current_state;
unsigned long flags;
/* 消抖延时 - 等待机械抖动稳定 */
msleep_interruptible(DEBOUNCE_MS);
/* 读取稳定的 GPIO 状态：0=按下，1=松开 */
current_state = key_get_state(dev->gpio);
spin_lock_irqsave(&dev->lock, flags);
/* 只有状态真的变了才生成事件 */
if (current_state != dev->last_gpio_state) {
dev->last_gpio_state = current_state;
/* 返回应用层约定：1=按下，0=松开 */
dev->key_value = !current_state;
dev->event_ready = true;
wake_up_interruptible(&dev->waitq);
atomic_inc(&dev->event_count);
} else {
/* 状态没变，跳过这次事件（抖动） */
atomic_inc(&dev->debounce_skipped);
}
spin_unlock_irqrestore(&dev->lock, flags);
}
这个函数是整个驱动最核心的部分，让我们一步步拆解。
步骤一：延时等待抖动结束
msleep_interruptible(DEBOUNCE_MS);
DEBOUNCE_MS 在我们的驱动里定义为 20ms。这个延时是消抖的关键。
你可能会问：为什么不用 usleep() 或者 ndelay()？因为按键抖动是毫秒级别的，用 msleep() 就够了。usleep() 或 ndelay() 提供的微秒级精度在这里没有意义，反而增加了不必要的开销。
ℹ️ msleep_interruptible 的选择
我们用 msleep_interruptible() 而不是 msleep()，因为前者可以被信号中断。这对于用户交互的设备是个好特性——用户按 Ctrl+C 时，工作队列能快速响应。
步骤二：读取 GPIO 状态
current_state = key_get_state(dev->gpio);
延时之后，我们读取 GPIO 状态。这时候按键应该已经稳定了，读到的就是真实的状态。
key_get_state() 是一个简单的封装函数：
static int key_get_state(struct gpio_desc* gpio)
{
return gpiod_get_value(gpio); // 0=按下，1=松开
}
这里有个约定：GPIO 返回 0 表示按下，1 表示松开。这是硬件决定的（按键连接到 GND）。但用户空间的约定通常是 1 表示按下，0 表示松开，所以我们在后面做了转换。
步骤三：比较状态变化
if (current_state != dev->last_gpio_state) {
// 状态真的变了，报告事件
} else {
// 状态没变，这是抖动，跳过
}
这是消抖算法的核心逻辑。我们不是无条件地报告事件，而是比较当前状态和上一次状态。只有状态真的变化了，才报告事件。
为什么要这样？考虑这个场景：
t=0ms: 按键按下，GPIO 从 1 变成 0，中断触发
t=0ms: 工作队列调度，开始延时
t=5ms: 抖动，GPIO 从 0 变成 1，中断触发
t=5ms: 工作队列重新调度，开始延时
t=10ms: 抖动，GPIO 从 1 变成 0，中断触发
t=10ms: 工作队列重新调度，开始延时
t=20ms: 延时结束，读取 GPIO = 0（按下）
如果没有 last_gpio_state 比较，我们会报告多次按下事件。但有了这个比较，我们可以看到：
- 第一次工作队列执行：
current_state=0 ≠ last_gpio_state=1，报告事件
- 第二次工作队列执行：
current_state=0 = last_gpio_state=0，跳过（抖动）
💡 状态比较的妙处
这个状态比较不仅过滤了抖动，还自然地实现了“边沿检测”。只有当 GPIO 状态真正变化时才报告事件，而不是每次中断都报告。这比单纯延时更可靠。
步骤四：更新状态和唤醒等待队列
dev->last_gpio_state = current_state;
dev->key_value = !current_state; // 转换约定：1=按下，0=松开
dev->event_ready = true;
wake_up_interruptible(&dev->waitq);
atomic_inc(&dev->event_count);
如果状态真的变化了，我们做这些事情：
- 更新
last_gpio_state，下次比较用
- 转换约定：硬件 0=按下，软件 1=按下
- 设置
event_ready 标志
- 唤醒等待队列（如果有进程在等待）
- 递增事件计数器
key_value 的转换是因为硬件和软件的约定不同。硬件上，按键按下时 GPIO 为 0（连接到 GND）。但在软件层面，我们通常用 1 表示按下，0 表示松开。所以这里做了取反操作。
步骤五：统计抖动次数
} else {
/* 状态没变，这是抖动，跳过 */
atomic_inc(&dev->debounce_skipped);
}
如果状态没有变化，我们递增 debounce_skipped 计数器。这个计数器可以帮助我们验证消抖效果。如果 debounce_skipped 很高，说明消抖在工作，成功过滤了很多抖动。
💡 统计信息的作用
驱动维护了三个计数器：
irq_count：中断触发次数event_count：实际事件次数debounce_skipped：被过滤的抖动次数
正常情况下，event_count << irq_count，debounce_skipped 应该比较高。这能证明消抖在有效工作。
完整的时序图
让我们看一个完整的时序，假设用户按下按键：
时间 GPIO状态 中断 工作队列 动作
------------------------------------------------------------
t=0 1→0 ✓ 调度 开始延时20ms
t=1 0→1 ✓ 重新调度 延时重置，再等20ms
t=2 1→0 ✓ 重新调度 延时重置，再等20ms
t=3 0 - (仍在延时) ...
t=5 0 - (仍在延时) ...
t=22 0 - 执行 读取GPIO=0
last_state=1
状态变化→报告事件
last_state更新为0
注意 t=1ms 和 t=2ms 的抖动会触发新的中断，新的中断会重新调度工作队列，重置延时。最终工作队列在 t=22ms 执行，此时 GPIO 已经稳定在 0，状态从上次的 1 变成了 0，所以报告按下事件。
为什么用 schedule_work 而不是 schedule_delayed_work
你可能会问，为什么不直接用 schedule_delayed_work() 延时调度，而是立即调度然后在工作函数里 msleep()？
// 方式一：立即调度 + 工作函数里延时
schedule_work(&dev->work);
// 工作函数里：msleep(20);
// 方式二：延时调度
schedule_delayed_work(&dev->work, msecs_to_jiffies(20));
两种方式都能实现 20ms 延时，但第一种方式有个好处：每次中断触发都会重新调度工作队列，重置延时。这对于消抖是个很好的特性——如果抖动持续触发中断，延时会被不断重置，直到抖动真正结束。
💡 工作队列的重调度
schedule_work() 可以重复调用，如果工作已经在队列里，会被移动到队列末尾（相当于重置延时）。这个特性对于消抖很有用。
消抖算法小结
消抖算法的核心是延时读取 + 状态比较。中断触发时不立即读取，而是调度工作队列，等 20ms 后再读取稳定的 GPIO 状态。只有当前状态和上一次状态不同时，才报告事件。
这个算法简单但有效。它利用了工作队列的重调度特性——抖动期间的每个中断都会重新调度工作队列，重置延时。最终工作队列执行时，抖动早已结束，读到的就是稳定的按键状态。
状态比较的加入使得算法更加可靠。即使工作队列多次执行，只有状态真正变化时才报告事件。这有效地过滤了所有抖动，只保留真实的按键事件。
下一章我们会讲同步机制，看看为什么需要自旋锁和等待队列，它们是如何保证多线程安全的。
第二部分 · 同步机制
讲完消抖算法，现在来看一个容易被忽视但极其重要的主题：同步机制。内核里有很多并发的场景——多个 CPU 可能同时执行代码，中断可能随时打断进程，工作队列和进程可能同时访问数据。如果没有合适的同步机制，你的代码会在某个随机的时刻崩溃，而且很难复现和调试。
为什么需要同步
让我们看看我们的驱动里有哪些并发场景：
// 场景一：中断处理函数和工作队列同时访问 dev->last_gpio_state
static irqreturn_t key_irq_handler(int irq, void *dev_id) {
atomic_inc(&dev->irq_count); // 中断上下文
schedule_work(&dev->work);
return IRQ_HANDLED;
}
static void key_work_handler(struct work_struct *work) {
dev->last_gpio_state = current_state; // 进程上下文
// ...
}
// 场景二：多个进程同时调用 read()
static ssize_t key_read(struct file* filp, char __user* buf, ...) {
wait_event_interruptible(dev->waitq, dev->event_ready); // 进程 A
// ...
dev->event_ready = false; // 进程 B
}
如果没有同步保护，这些场景可能导致数据竞争、状态不一致、甚至内核 panic。
⚠️ 踩坑经历
我第一次写这个驱动的时候，就没加同步保护。大部分时间运行正常，但偶尔会读到奇怪的值，或者事件丢失。查了好久才发现是并发问题。这种 bug 最难调试，因为它不是每次都出现，而且很难复现。
自旋锁（Spinlock）
自旋锁是最基本的同步机制。它的原理很简单：一个线程尝试获取锁，如果锁已经被占用，就“自旋”（在一个循环里等待），直到锁被释放。
spinlock_t lock;
unsigned long flags;
// 获取锁（同时关闭中断）
spin_lock_irqsave(&dev->lock, flags);
// 临界区：访问共享数据
dev->last_gpio_state = current_state;
dev->key_value = !current_state;
// 释放锁（恢复中断）
spin_unlock_irqrestore(&dev->lock, flags);
为什么用 _irqsave 版本
你可能见过好几种自旋锁函数：spin_lock()、spin_lock_irq()、spin_lock_irqsave()。我们用 _irqsave 版本，这是最安全的选择。
spin_lock(&lock); // 不关闭中断
spin_lock_irq(&lock); // 关闭本地中断
spin_lock_irqsave(&lock, flags); // 关闭本地中断，保存之前的状态
_irqsave 版本不仅获取锁，还关闭本地中断，并保存之前的中断状态。为什么需要关闭中断？因为中断处理函数可能也会访问这个锁。如果中断在持有锁的时候发生，中断处理函数尝试获取同一个锁，就会死锁——中断处理函数自旋等待锁释放，但锁的持有者（被打断的代码）要等中断结束才能继续，互相等待。
💡 死锁场景
进程上下文持有锁 → 中断触发 → 中断处理函数尝试获取同一个锁 → 死锁
使用 spin_lock_irqsave() 可以避免这个场景，因为获取锁时中断已被关闭，中断不会在持有锁的时候发生。
临界区要尽可能短
自旋锁的临界区必须尽可能短，不能有睡眠操作。
spin_lock_irqsave(&dev->lock, flags);
// ✅ 快速操作
dev->last_gpio_state = current_state;
dev->event_ready = true;
// ❌ 不能睡眠
// msleep(20); // 绝对不行！
spin_unlock_irqrestore(&dev->lock, flags);
如果临界区里有睡眠操作，其他等待锁的 CPU 会空转浪费 CPU 时间，而且可能导致系统响应变慢。
我们在哪里使用自旋锁
在我们的驱动里，工作处理函数里访问共享数据时使用了自旋锁：
static void key_work_handler(struct work_struct* work) {
// ... 读取 GPIO ...
spin_lock_irqsave(&dev->lock, flags);
if (current_state != dev->last_gpio_state) {
dev->last_gpio_state = current_state;
dev->key_value = !current_state;
dev->event_ready = true;
wake_up_interruptible(&dev->waitq);
atomic_inc(&dev->event_count);
} else {
atomic_inc(&dev->debounce_skipped);
}
spin_unlock_irqrestore(&dev->lock, flags);
}
这里需要保护 last_gpio_state、key_value、event_ready 这些字段，因为它们可能被其他地方（比如 read 函数）同时访问。
等待队列（Wait Queue）
等待队列用于让进程睡眠等待某个事件，当事件发生时再唤醒它。这是实现阻塞 I/O 的标准方式。
wait_queue_head_t waitq;
// 初始化
init_waitqueue_head(&dev->waitq);
// 在 read() 里等待
wait_event_interruptible(dev->waitq, dev->event_ready);
// 在工作函数里唤醒
wake_up_interruptible(&dev->waitq);
wait_event_interruptible 宏
wait_event_interruptible() 是一个宏，它的作用是：如果条件为假，让进程睡眠；如果条件为真，立即返回。
wait_event_interruptible(dev->waitq, dev->event_ready);
展开后大致是这样：
while (!dev->event_ready) {
// 把当前进程加入等待队列
// 让进程进入睡眠状态
// 调度器选择其他进程运行
}
当某个地方调用 wake_up_interruptible(&dev->waitq) 时，睡眠的进程会被唤醒，重新检查条件。如果条件为真，返回；如果条件仍为假，继续睡眠。
我们的 read 函数
static ssize_t key_read(struct file* filp, char __user* buf,
size_t cnt, loff_t* offt)
{
struct key_debounce_dev *dev = filp->private_data;
int key_value;
unsigned long flags;
/* 等待事件就绪 */
if (wait_event_interruptible(dev->waitq, dev->event_ready)) {
return -ERESTARTSYS;
}
/* 读取数据 */
spin_lock_irqsave(&dev->lock, flags);
key_value = dev->key_value;
dev->event_ready = false;
spin_unlock_irqrestore(&dev->lock, flags);
/* 拷贝到用户空间 */
if (copy_to_user(buf, &key_value, sizeof(key_value))) {
return -EFAULT;
}
return sizeof(key_value);
}
这个函数的核心是 wait_event_interruptible()。如果没有新事件，进程会睡眠在这里。当工作队列调用 wake_up_interruptible() 时，进程被唤醒，读取数据并返回给用户空间。
💡 为什么用 _interruptible 版本
_interruptible 版本可以被信号中断，这对于用户交互的设备是个好特性。用户按 Ctrl+C 时，read() 会返回 -ERESTARTSYS，而不是傻等。
原子变量（Atomic）
原子变量是硬件保证原子性的整数类型，不需要锁就能安全地读写和递增。
atomic_t irq_count;
// 递增
atomic_inc(&dev->irq_count);
// 读取
int count = atomic_read(&dev->irq_count);
原子变量内部使用特殊的 CPU 指令（比如 ARM 的 LDXR/STXR），确保操作的原子性。即使是多 CPU 同时递增，结果也是正确的。
我们在哪里使用原子变量
我们的驱动用原子变量来统计信息：
// 中断处理函数里
atomic_inc(&dev->irq_count);
// 工作函数里
atomic_inc(&dev->event_count);
atomic_inc(&dev->debounce_skipped);
这些统计信息不需要严格的同步，但也不能出现错误的值（比如两个中断同时递增，结果只加了 1）。原子变量正好满足这个需求。
💡 原子变量 vs 自旋锁
原子变量适用于简单的计数和标志位。如果操作比较复杂（比如多个字段需要一起更新），还是用自旋锁更合适。我们的驱动两者都用：原子变量用于统计，自旋锁用于状态保护。
各种同步机制的选择
内核提供了多种同步机制，选择合适的很重要：
| 机制 |
适用场景 |
能否睡眠 |
| 自旋锁 |
短期临界区，多 CPU |
否 |
| 互斥锁（Mutex） |
长期临界区，单线程上下文 |
是 |
| 读写锁（RW Lock） |
读多写少的临界区 |
否 |
| 完成量（Completion） |
等待一次性事件 |
是 |
| 等待队列（Wait Queue） |
等待事件，阻塞 I/O |
是 |
| 原子变量 |
简单计数和标志位 |
N/A |
对于我们的按键驱动，选择是明确的：自旋锁保护状态，等待队列实现阻塞 I/O，原子变量统计信息。
ℹ️ 为什么不用互斥锁
互斥锁可以睡眠，所以不能在中断上下文使用。我们的中断处理函数需要递增 irq_count，只能用原子变量。工作队列可以用互斥锁，但自旋锁已经足够了。
调试并发问题
并发问题是最难调试的，因为它们是非确定性的——不一定每次都出现。这里有一些技巧：
- 开启内核并发检测：
echo 1 > /proc/sys/kernel/lockdep
Lockdep 可以检测死锁风险，虽然它有运行时开销，但对于调试很有用。
-
使用 KCSAN 检测数据竞争：内核配置里开启 CONFIG_KCSAN，可以检测未同步的并发访问。
-
代码审查：仔细检查所有共享数据的访问，确保都有合适的同步保护。
⚠️ 难以复现的 bug
并发问题往往在压力测试或多 CPU 系统上才出现。单 CPU 或轻负载时可能一切正常，但多 CPU 高负载时就崩溃了。所以测试时要覆盖各种场景。
更多嵌入式开发技术交流，欢迎访问云栈社区。
发表于 昨天 22:43
|
查看: 3|
回复: 0
