Linux 内核功耗子系统(十六):wakeup source唤醒源框架梳理

三层的关系可以这样理解：L1 决定能不能被抬起，L2 决定抬起时硬件通路是否留着，L3 决定抬起后 PM Core 是否知道该记账给谁。

事件计数模型

单个 ws 内部的状态迁移由三个计数器和一个 active bit 描述：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
初始：active=false, active_count=0, event_count=0, relax_count=0, expire_count=0__pm_stay_awake(ws):  ┌────────────────────────────────────┐  │ active==false?                     │  │   active = true                    │  │   active_count++                   │  │   event_count++                    │  │   last_time = now                  │  │   combined_event_count: inpr += 1  │  └────────────────────────────────────┘pm_wakeup_ws_event(ws, msec):  __pm_stay_awake(ws)  mod_timer(&ws->timer, jiffies + msecs_to_jiffies(msec))Timer 到期:  wakeup_source_timer_fn()  __pm_relax(ws)  expire_count++__pm_relax(ws):  ┌────────────────────────────────────┐  │ active==true?                      │  │   active = false                   │  │   relax_count++                    │  │   total_time += now - last_time    │  │   max_time = max(max_time, delta)  │  │   combined_event_count:            │  │     inpr -= 1                      │  │     event_count(high 16b) += 1     │  └────────────────────────────────────┘

三个计数器 active_count / relax_count / event_count 在稳态下应该是接近的，expire_count 反映了有多少事件是被 timer 强行 relax 的。ws->wakeup_count 是另一个维度：这个 ws 造成了多少次 suspend 抢占（在 pm_wakeup_pending() 检测到 active ws 时递增）。

阻塞窗口模型

suspend 路径上，pm_wakeup_pending() 在两个关键点被调用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// drivers/base/power/wakeup.cbool pm_wakeup_pending(void){    unsigned long flags;    bool ret = false;    raw_spin_lock_irqsave(&events_lock, flags);    if (events_check_enabled) {        unsigned int cnt, inpr;        split_counters(&cnt, &inpr);        ret = (cnt != saved_count || inpr > 0);        events_check_enabled = !ret;    }    raw_spin_unlock_irqrestore(&events_lock, flags);    if (ret) {        pm_pr_dbg("Wakeup pending, aborting suspend\n");        pm_print_active_wakeup_sources();    }    return ret || atomic_read(&pm_abort_suspend) > 0;}

这个函数在 suspend 路径上有两个调用点：suspend_devices_and_enter() 的 dpm_suspend_noirq() 之后，以及 s2idle_loop() 的每次循环里。它构成了一个阻塞窗口：从用户态写 wakeup_count（保存 saved_count）到 suspend 实际进入 suspend_ops->enter()，任何 ws 上的 event 都会让这次 suspend 抢占失败。

窗口关闭点是 syscore_suspend()，此时 IRQ 已经全屏蔽，只有 wakeup IRQ 能进来，pm_wakeup_event 也不再被检查（因为再也没机会检查了）。窗口打开点是用户态的 wakeup_count 读回操作。

数据流

从驱动注册到事件传递到用户态感知，wakeup source 的完整数据流分成四段。

阶段一：注册

驱动初始化时调用：

1
2
device_init_wakeup(&pdev->dev, true);

这个宏展开后做了三件事：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// drivers/base/power/wakeup.cint device_init_wakeup(struct device *dev, bool enable){    int ret = 0;    if (enable) {        device_set_wakeup_capable(dev, true);        ret = device_wakeup_enable(dev);        // 分配 ws    } else {        device_wakeup_disable(dev);        device_set_wakeup_capable(dev, false);    }    return ret;}

device_wakeup_enable() 会：

1. 1. 调 wakeup_source_register(dev, dev_name(dev)) 分配 ws，name 用设备名
2. 2. 把 ws 挂到 wakeup_sources 全局链表
3. 3. 把 ws 指针写入 dev->power.wakeup
4. 4. 在 /sys/devices/.../power/wakeup 下暴露 enabled/disabled 属性除了 device_init_wakeup() 这条路径，PM Core 还提供两种更细的注册方式：

• • wakeup_source_register：不绑定 device，只登记一个 ws。适合子系统级的 wakeup source（如 autosleep_ws）
• • dev_pm_set_wake_irq/ dev_pm_set_dedicated_wake_irq 绑定一根专用 wakeup IRQ。PM Core 会在 suspend 时自动 enable_irq_wake()，resume 时 disable_irq_wake()，驱动不再需要手写这套代码

阶段二：事件触发

设备驱动在 ISR / workqueue / 网络接收路径里，产生这个事件需要唤醒或保持系统的信号：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// 一次性事件，允许用户态 500ms 时间处理static irqreturn_t mydev_wakeup_isr(int irq, void *data){struct mydev *d = data;    pm_wakeup_event(&d->pdev->dev, 500);    schedule_work(&d->event_work);    return IRQ_HANDLED;}// 持续性事件，显式 stay/relaxstatic void mydev_rx_start(struct mydev *d){    __pm_stay_awake(d->rx_ws);}static void mydev_rx_done(struct mydev *d){    __pm_relax(d->rx_ws);}

pm_wakeup_event() 内部的原子操作序列：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// drivers/base/power/wakeup.cvoid __pm_wakeup_event(struct wakeup_source *ws, unsigned int msec){    unsigned long flags;    unsigned long expires;    if (!ws)        return;    spin_lock_irqsave(&ws->lock, flags);    wakeup_source_report_event(ws, false);   // active_count++, event_count++, combined_event_count.inpr++    if (!msec) {        wakeup_source_deactivate(ws);        // 立刻 relax        goto unlock;    }    expires = jiffies + msecs_to_jiffies(msec);    if (!expires)        expires = 1;    if (!ws->timer_expires || time_after(expires, ws->timer_expires)) {        mod_timer(&ws->timer, expires);        ws->timer_expires = expires;    }unlock:    spin_unlock_irqrestore(&ws->lock, flags);}

关键点是 mod_timer 只在过期时间需要延长时才改，如果一个 ws 短时间内被多次 pm_wakeup_event(dev, 500)，timer 只会指向最晚那次的过期时刻，避免了 timer 抖动。

阶段三：suspend 路径的记账检查

系统进入 suspend 前，用户态 autosleep daemon 会：

1
2
3
4
5
// 用户态 pseudo coderead("/sys/power/wakeup_count", &count);   // 内核 saved_count = combined_event_count.event_countwrite("/sys/power/wakeup_count", count);   // 若 saved_count 仍等于当前 event_count 且 inpr==0，通过write("/sys/power/state", "mem");           // 触发 pm_suspend()

内核在 pm_suspend() 走到 suspend_devices_and_enter()，最后要调 pm_wakeup_pending()：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// drivers/base/power/wakeup.cbool pm_save_wakeup_count(unsigned int count){    unsigned int cnt, inpr;    unsigned long flags;    events_check_enabled = false;    raw_spin_lock_irqsave(&events_lock, flags);    split_counters(&cnt, &inpr);    if (cnt == count && inpr == 0) {        saved_count = count;        events_check_enabled = true;    }    raw_spin_unlock_irqrestore(&events_lock, flags);    return events_check_enabled;}

从用户态写回 wakeup_count 成功到 suspend 进入 suspend_ops->enter()，中间任何 ws 上的 __pm_stay_awake 都会让 pm_wakeup_pending() 返回 true，suspend 被中止，控制权回到 suspend_devices_and_enter() 的错误路径，反向 resume 所有已经 suspend 的设备。

阶段四：用户态感知

用户态感知系统被唤醒有三条路：

1. 1. /sys/power/wakeup_count 变化：autosleep daemon 下一次读会拿到新的 count
2. 2. /sys/kernel/debug/wakeup_sources 表格：active_count / event_count / wakeup_count / max_time_ms 每一列都是诊断输入
3. 3. /sys/class/wakeup/wakeupN/*：每个 ws 一个 kobject，方便按名字定点查

第三条在 Android 上被 SystemServer 直接消费，它会周期性读 wakeup source stats，把哪个 ws 阻止了 doze 记录到 battery stats 里。

运行

驱动实现三条正确姿势

姿势一：一次性事件（最常见）

按键、RTC alarm、传感器阈值等短事件，用 pm_wakeup_event(dev, msec)：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
static int mykey_probe(struct platform_device *pdev){    device_init_wakeup(&pdev->dev, true);    request_threaded_irq(irq, NULL, mykey_isr, IRQF_ONESHOT, "mykey", pdev);    ...}static irqreturn_t mykey_isr(int irq, void *data){struct platform_device *pdev = data;    /* 通知 PM Core：产生了一个事件，请给用户态 500ms 处理 */    pm_wakeup_event(&pdev->dev, 500);    input_report_key(...);    input_sync(...);    return IRQ_HANDLED;}static int mykey_suspend(struct device *dev){    if (device_may_wakeup(dev))        enable_irq_wake(to_platform_device(dev)->irq);    return 0;}static int mykey_resume(struct device *dev){    if (device_may_wakeup(dev))        disable_irq_wake(to_platform_device(dev)->irq);    return 0;}

姿势二：持续性事件

网络接收、大文件写入这类事件时长不确定的场景，显式配对 stay/relax：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
static void net_rx_pending(struct mydev *d){    __pm_stay_awake(d->rx_ws);        /* 进入活跃期 */    napi_schedule(&d->napi);}static int mydev_poll(struct napi_struct *napi, int budget){    ...    if (rx_done_and_queue_empty) {        napi_complete(napi);        __pm_relax(d->rx_ws);         /* 离开活跃期 */    }    return work_done;}

姿势三：dedicated wake irq

有些 SoC 提供一根专用的 wakeup 中断线（比如 PMIC 的 mux 输出），suspend 时主 IRQ 被关掉，wakeup IRQ 保留。这类场景用 dev_pm_set_dedicated_wake_irq()：

1
2
3
4
5
6
7
8
9
static int mydev_probe(struct platform_device *pdev){    int wake_irq = platform_get_irq_byname(pdev, "wakeup");    device_init_wakeup(&pdev->dev, true);    dev_pm_set_dedicated_wake_irq(&pdev->dev, wake_irq);    ...}

PM Core 会在 dpm_suspend_noirq 阶段自动 enable_irq_wake()，dpm_resume_noirq 阶段自动 disable_irq_wake()，驱动完全不用管。

与 Runtime PM 的交互

Runtime PM 和 wakeup source 是正交的：Runtime PM 关心设备 idle 时能不能 suspend，wakeup source 关心设备事件能不能抢占 system sleep。但驱动实现时经常要同时考虑：

• • Runtime PM suspend 时，如果 device_may_wakeup(dev)，要保留唤醒通路（不能关那根 IRQ）
• • System suspend 回调里通常先 pm_runtime_force_suspend(dev) 把 Runtime PM 状态推到 suspended，再走 system sleep 特有的操作

Runtime PM 自己也会用到 wakeup source：pm_runtime_get_sync() 触发 resume 时，如果发现设备是被 wakeup 事件叫醒的（比如 USB 上游端口检测到设备插入），会通过 pm_wakeup_event(dev, 100) 抢占正在进行的 system sleep。

autosleep 的完整循环

Android 和部分 embedded Linux 用 autosleep 让系统在空闲时自动进 suspend：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// kernel/power/autosleep.cstatic void try_to_suspend(struct work_struct *work){    unsigned int initial_count, final_count;    if (!pm_get_wakeup_count(&initial_count, true))        goto out;    mutex_lock(&autosleep_lock);    if (!pm_save_wakeup_count(initial_count) ||        system_state != SYSTEM_RUNNING) {        mutex_unlock(&autosleep_lock);        goto out;    }    if (autosleep_state == PM_SUSPEND_ON) {        mutex_unlock(&autosleep_lock);        return;    }    if (autosleep_state >= PM_SUSPEND_MAX)        hibernate();    else        pm_suspend(autosleep_state);    mutex_unlock(&autosleep_lock);    if (!pm_get_wakeup_count(&final_count, false))        goto out;    /*     * 如果 suspend 期间产生的 wakeup events 数超过 saved_count，     * 说明有活跃事件在处理，暂缓下一次尝试     */    if (final_count == initial_count)        schedule_timeout_uninterruptible(HZ / 2);out:    queue_up_suspend_work();}

这个循环把 wakeup source 的所有机制都用上了：

• • pm_get_wakeup_count() 拿快照
• • pm_save_wakeup_count() 提交快照，失败说明有事件正在处理
• • pm_suspend() 进入 suspend，路径上再次 pm_wakeup_pending()
• • suspend 返回后再拿一次 count，如果没变说明这次唤醒是被中断本身触发的，不是被 event 触发的，退避半秒再试

总结

wakeup source 子系统做的三件事：登记谁可能唤醒系统、记账事件发生了多少次、抢占正在进行的 suspend。这三件事分别对应三层模型：

• • 登记 = wakeup_source_register / device_init_wakeup 建立 ws → 挂 wakeup_sources 链表 → sysfs 暴露 kobject
• • 记账 = pm_wakeup_event / __pm_stay_awake 更新 combined_event_count → sysfs/debugfs 表格化输出
• • 抢占 = pm_wakeup_pending 对比 saved_count、in_progress → 让 suspend_devices_and_enter 走错误路径

按调试目标划分，每一层都有对应的排查手段：

wakeup source 的复杂度不在于任何一个函数，而在于它是内核里唯一同时被中断、驱动、PM Core 遍历、用户态 daemon 四方消费的对象。任何一方对语义理解偏差，都会体现为 suspend 进不去或进去了叫不醒，两个方向都可能，而且现象容易互相掩盖。

到这一篇为止，功耗子系统从进入低功耗到低功耗态里被唤醒回来这一条闭环终于合上了：DPM + system sleep 讲了怎么睡下去、wakeup source 讲了怎么醒来。