Linux电源管理(7)_Wakeup events framework
作者：wowo 发布于：2014-9-9 22:43 分类：电源管理子系统
1. 前言
本文继续“Linux电源管理(6)_Generic PM之Suspend功能”中有关suspend同步以及PM wakeup的话题。这个话题，是近几年Linux kernel最具争议的话题之一，在国外Linux开发论坛，经常可以看到围绕该话题的辩论。辩论的时间跨度和空间跨度可以持续很长，且无法达成一致。
wakeup events framework是这个话题的一个临时性的解决方案，包括wake lock、wakeup count、autosleep等机制。它们就是本文的话题。
2. wakeup events framework要解决的问题
我们知道，系统处于suspend状态，可通过wakeup events唤醒。具体的wakeup events可以是按键按下，可以是充电器插入，等等。但是，如果在suspend的过程中，产生了wakeup events，怎么办？答案很肯定，"wakeup"系统。由于此时系统没有真正suspend，所以这的"wakeup"是个假动作，实际上只是终止suspend。
但由于系统在suspend的过程中，会进行process freeze、 device suspend等操作，而这些操作可能导致内核或用户空间程序不能及时获取wakeup events，从而使系统不能正确wakeup，这就是wakeup events framework要解决的问题：system suspend和system wakeup events之间的同步问题。
3. wakeup events framework的功能总结
仔细推敲一下，上面所讲的同步问题包括两种情况：
情况1：内核空间的同步
wakeup events产生后，通常是以中断的形式通知device driver。driver会处理events，处理的过程中，系统不能suspend。
注1：同步问题只存在于中断开启的情况，因为若中断关闭，就不会产生wakeup events，也就不存在同步的概念。
情况2：用户空间的同步
一般情况下，driver对wakeup events处理后，会交给用户空间程序继续处理，处理的过程，也不允许suspend。这又可以分为两种情况：
1）进行后续处理的用户进程，根本没有机会被调度，即该wakeup events无法上报到用户空间。
2）进行后续处理的用户进程被调度，处理的过程中（以及处理结束后，决定终止suspend操作），系统不能suspend。
因此，wakeup events framework就包括3大功能：
解决内核空间同步问题（framework的核心功能）；
解决用户空间同步问题的情景1（wakeup count功能）；
解决用户空间同步问题的情景2（wake lock功能） 。
注2：
用户空间同步的两种情况，咋一看，非常合乎情理，kernel你得好好处理！但事实上，该同步问题牵涉到了另外一个比较有争议的话题：日常的电源管理机制。是否要基于suspend实现？系统何时进入低功耗状态，应该由谁决定？kernel还是用户空间程序？
这最终会决定是否存在用空间同步问题。但是，在当前这个时间点，对这个话题，Linux kernel developers和Android developers持相反的观点。这也造成了wakeup events framework在实现上的撕裂。Kernel的本意是不愿处理用户空间同步问题的，但为了兼容Android平台，不得不增加相关的功能（Wakeup count和Wake lock）。
蜗蜗会在下一篇文章和大家探讨该话题，本文就先focus在wakeup events framework上。
4. wakeup events framework architecture
下面图片描述了wakeup events framework的architecture：
图片中红色边框的block是wakeup events相关的block：
1）wakeup events framework core，在drivers/base/power/wakeup.c中实现，提供了wakeup events framework的核心功能，包括：
抽象wakeup source和wakeup event的概念；
向各个device driver提供wakeup source的注册、使能等接口；
向各个device driver提供wakeup event的上报、停止等接口；
向上层的PM core（包括wakeup count、auto sleep、suspend、hibernate等模块）提供wakeup event的查询接口，以判断是否可以suspend、是否需要终止正在进行的suspend。
2）wakeup events framework sysfs，将设备的wakeup信息，以sysfs的形式提供到用户空间，供用户空间程序查询、配置。在drivers/base/power/sysfs.c中实现。
3）wake lock/unlock，为了兼容Android旧的wakeup lock机制而留下的一个后门，扩展wakeup events framework的功能，允许用户空间程序报告/停止wakeup events。换句话说，该后门允许用户空间的任一程序决定系统是否可以休眠。
4）wakeup count，基于wakeup events framework，解决用户空间同步的问题。
5）auto sleep，允许系统在没有活动时（即一段时间内，没有产生wakeup event），自动休眠。
注3：在Linux kernel看来，power是系统的核心资源，不应开放给用户程序随意访问（wake lock机制违背了这个原则）。而在运行时的电源管理过程中，系统何时进入低功耗状态，也不是用户空间程序能决定的（auto sleep中枪了）。因此，kernel对上述功能的支持，非常的不乐意，我们可以从kernel/power/main.c中sysfs attribute文件窥见一斑（只要定义了PM_SLEEP，就一定支持wakeup count功能，但autosleep和wake lock功能，由另外的宏定义控制）：
1: static struct attribute * g[] = {
2: &state_attr.attr,
3: #ifdef CONFIG_PM_TRACE
4: &pm_trace_attr.attr,
5: &pm_trace_dev_match_attr.attr,
6: #endif
7: #ifdef CONFIG_PM_SLEEP
8: &pm_async_attr.attr,
9: &wakeup_count_attr.attr,
10: #ifdef CONFIG_PM_AUTOSLEEP
11: &autosleep_attr.attr,
12: #endif
13: #ifdef CONFIG_PM_WAKELOCKS
14: &wake_lock_attr.attr,
15: &wake_unlock_attr.attr,
16: #endif
17: #ifdef CONFIG_PM_DEBUG
18: &pm_test_attr.attr,
19: #endif
20: #ifdef CONFIG_PM_SLEEP_DEBUG
21: &pm_print_times_attr.attr,
22: #endif
23: #endif
24: #ifdef CONFIG_FREEZER
25: &pm_freeze_timeout_attr.attr,
26: #endif
27: NULL,
28: };
5. 代码分析
5.1 wakeup source和wakeup event
在kernel中，可以唤醒系统的只有设备(struct device)，但并不是每个设备都具备唤醒功能，那些具有唤醒功能的设备称作wakeup source。是时候回到这篇文章中了（Linux设备模型(5)_device和device driver），在那里，介绍struct device结构时，涉及到一个struct dev_pm_info类型的power变量，蜗蜗说留待后面的专题讲解。我们再回忆一下struct device结构：
1: struct device {
2: ...
3: struct dev_pm_info power;
4: ...
5: };
该结构中有一个power变量，保存了和wakeup event相关的信息，让我们接着看一下struct dev_pm_info数据结构（只保留和本文有关的内容）：
1: struct dev_pm_info {
2: ...
3: unsigned int can_wakeup:1;
4: ...
5: #ifdef CONFIG_PM_SLEEP
6: ...
7: struct wakeup_source *wakeup;
8: ...
9: #else
10: unsigned int should_wakeup:1;
11: #endif
12: };
can_wakeup，标识本设备是否具有唤醒能力。只有具备唤醒能力的设备，才会在sysfs中有一个power目录，用于提供所有的wakeup信息，这些信息是以struct wakeup_source的形式组织起来的。也就是上面wakeup指针。具体有哪些信息呢？让我们看看struct wakeup_source的定义。
1: /* include\linux\pm_wakeup.h */
2: struct wakeup_source {
3: const char *name;
4: struct list_head entry;
5: spinlock_t lock;
6: struct timer_list timer;
7: unsigned long timer_expires;
8: ktime_t total_time;
9: ktime_t max_time;
10: ktime_t last_time;
11: ktime_t start_prevent_time;
12: ktime_t prevent_sleep_time;
13: unsigned long event_count;
14: unsigned long active_count;
15: unsigned long relax_count;
16: unsigned long expire_count;
17: unsigned long wakeup_count;
18: bool active:1;
19: bool autosleep_enabled:1;
20: };
因此，一个wakeup source代表了一个具有唤醒能力的设备，也称该设备为一个wakeup source。该结构中各个字段的意义如下：
name，该wakeup source的名称，一般为对应的device name（有个例外，就是wakelock）；
entery，用于将所有的wakeup source挂在一个链表中；
timer、timer_expires，一个wakeup source产生了wakeup event，称作wakeup source activate，wakeup event处理完毕后（不再需要系统为此保持active），称作deactivate。activate和deactivate的操作可以由driver亲自设置，也可以在activate时，指定一个timeout时间，时间到达后，由wakeup events framework自动将其设置为deactivate状态。这里的timer以及expires时间，就是用来实现该功能；
total_time，该wakeup source处于activate状态的总时间（可以指示该wakeup source对应的设备的繁忙程度、耗电等级）；
max_time，该wakeup source持续处于activate状态的最大时间（越长越不合理）；
last_time，该wakeup source上次active的开始时间；
start_prevent_time，该wakeup source开始阻止系统自动睡眠（auto sleep）的时间点；
prevent_sleep_time，该wakeup source阻止系统自动睡眠的总时间；
event_count，wakeup source上报的event个数；
active_count，wakeup source activate的次数；
relax_count， wakeup source deactivate的次数；
expire_count，wakeup source timeout到达的次数；
wakeup_count，wakeup source终止suspend过程的次数；
active，wakeup source的activate状态；
autosleep_enabled，记录系统auto sleep的使能状态（每个wakeup source都重复记录这样一个状态，这种设计真实不敢恭维！）。
wakeup source代表一个具有唤醒能力的设备，该设备产生的可以唤醒系统的事件，就称作wakeup event。当wakeup source产生wakeup event时，需要将wakeup source切换为activate状态；当wakeup event处理完毕后，要切换为deactivate状态。因此，我们再来理解一下几个wakeup source比较混淆的变量：event_count, active_count和wakeup_count：
event_count，wakeup source产生的wakeup event的个数；
active_count，产生wakeup event时，wakeup source需要切换到activate状态。但并不是每次都要切换，因此有可能已经处于activate状态了。因此active_count可能小于event_count，换句话说，很有可能在前一个wakeup event没被处理完时，又产生了一个。这从一定程度上反映了wakeup source所代表的设备的繁忙程度；
wakeup_count，wakeup source在suspend过程中产生wakeup event的话，就会终止suspend过程，该变量记录了wakeup source终止suspend过程的次数（如果发现系统总是suspend失败，检查一下各个wakeup source的该变量，就可以知道问题出在谁身上了）。
5.2 几个counters
在drivers\base\power\wakeup.c中，有几个比较重要的计数器，是wakeup events framework的实现基础，包括：
1）registered wakeup events和saved_count
记录了系统运行以来产生的所有wakeup event的个数，在wakeup source上报event时加1。
这个counter对解决用户空间同步问题很有帮助，因为一般情况下（无论是用户程序主动suspend，还是auto sleep），由专门的进程（或线程）触发suspend。当这个进程判断系统满足suspend条件，决定suspend时，会记录一个counter值(saved_count)。在后面suspend的过程中，如果系统发现counter有变，则说明系统产生了新的wakeup event，这样就可以终止suspend。
该功能即是wakeup count功能，会在后面更详细的说明。
2）wakeup events in progress
记录正在处理的event个数。
当wakeup source产生wakeup event时，会通过wakeup events framework提供的接口将wakeup source设置为activate状态。当该event处理结束后，设置为deactivate状态。activate到deactivate的区间，表示该event正在被处理。
当系统中有任何正在被处理的wakeup event时，则不允许suspend。如果suspend正在进行，则要终止。
思考一个问题：registered wakeup events在什么时候增加？答案是在wakeup events in progress减小时，因为已经完整的处理完一个event了，可以记录在案了。
基于这种特性，kernel将它俩合并成一个32位的整型数，以原子操作的形式，一起更新。这种设计巧妙的让人叫绝，值得我们学习。具体如下：
1: /*
2: * Combined counters of registered wakeup events and wakeup events in progress.
3: * They need to be modified together atomically, so it's better to use one
4: * atomic variable to hold them both.
5: */
6: static atomic_t combined_event_count = ATOMIC_INIT(0);
7:
8: #define IN_PROGRESS_BITS (sizeof(int) * 4)
9: #define MAX_IN_PROGRESS ((1 << IN_PROGRESS_BITS) - 1)
10:
11: static void split_counters(unsigned int *cnt, unsigned int *inpr)
12: {
13: unsigned int comb = atomic_read(&combined_event_count);
14:
15: *cnt = (comb >> IN_PROGRESS_BITS);
16: *inpr = comb & MAX_IN_PROGRESS;
17: }
定义和读取。
1: cec = atomic_add_return(MAX_IN_PROGRESS, &combined_event_count);
wakeup events in progress减1，registered wakeup events加1，这个语句简直是美轮美奂，读者可以仔细品味一下，绝对比看xxx片还过瘾，哈哈。
1: cec = atomic_inc_return(&combined_event_count);
wakeup events in progress加1。
5.3 wakeup events framework的核心功能
wakeup events framework的核心功能体现在它向底层的设备驱动所提供的用于上报wakeup event的接口，这些接口根据操作对象可分为两类，具体如下。
类型一（操作对象为wakeup source，编写设备驱动时，一般不会直接使用）：
1: /* include/linux/pm_wakeup.h */
2: extern void __pm_stay_awake(struct wakeup_source *ws);
3: extern void __pm_relax(struct wakeup_source *ws);
4: extern void __pm_wakeup_event(struct wakeup_source *ws, unsigned int msec);
__pm_stay_awake，通知PM core，ws产生了wakeup event，且正在处理，因此不允许系统suspend（stay awake）；
__pm_relax，通知PM core，ws没有正在处理的wakeup event，允许系统suspend（relax）；
__pm_wakeup_event，为上边两个接口的功能组合，通知PM core，ws产生了wakeup event，会在msec毫秒内处理结束（wakeup events framework自动relax）。
注4：__pm_stay_awake和__pm_relax应成对调用。
注5：上面3个接口，均可以在中断上下文调用。
类型二（操作对象为device，为设备驱动的常用接口）：
1: /* include/linux/pm_wakeup.h */
2: extern int device_wakeup_enable(struct device *dev);
3: extern int device_wakeup_disable(struct device *dev);
4: extern void device_set_wakeup_capable(struct device *dev, bool capable);
5: extern int device_init_wakeup(struct device *dev, bool val);
6: extern int device_set_wakeup_enable(struct device *dev, bool enable);
7: extern void pm_stay_awake(struct device *dev);
8: extern void pm_relax(struct device *dev);
9: extern void pm_wakeup_event(struct device *dev, unsigned int msec);
device_set_wakeup_capable，设置dev的can_wakeup标志（enable或disable，可参考5.1小节），并增加或移除该设备在sysfs相关的power文件；
device_wakeup_enable/device_wakeup_disable/device_set_wakeup_enable，对于can_wakeup的设备，使能或者禁止wakeup功能。主要是对struct wakeup_source结构的相关操作；
device_init_wakeup，设置dev的can_wakeup标志，若是enable，同时调用device_wakeup_enable使能wakeup功能；
pm_stay_awake、pm_relax、pm_wakeup_event，直接调用上面的wakeup source操作接口，操作device的struct wakeup_source变量，处理wakeup events。
5.3.1 device_set_wakeup_capable
该接口位于在drivers/base/power/wakeup.c中，代码如下：
1: void device_set_wakeup_capable(struct device *dev, bool capable)
2: {
3: if (!!dev->power.can_wakeup == !!capable)
4: return;
5:
6: if (device_is_registered(dev) && !list_empty(&dev->power.entry)) {
7: if (capable) {
8: if (wakeup_sysfs_add(dev))
9: return;
10: } else {
11: wakeup_sysfs_remove(dev);
12: }
13: }
14: dev->power.can_wakeup = capable;
15: }
该接口的实现很简单，主要包括sysfs的add/remove和can_wakeup标志的设置两部分。如果设置can_wakeup标志，则调用wakeup_sysfs_add，向该设备的sysfs目录下添加power文件夹，并注册相应的attribute文件。如果清除can_wakeup标志，执行sysfs的移除操作。
wakeup_sysfs_add/wakeup_sysfs_remove位于drivers/base/power/sysfs.c中，对wakeup events framework来说，主要包括如下的attribute文件：
1: static struct attribute *wakeup_attrs[] = {
2: #ifdef CONFIG_PM_SLEEP
3: &dev_attr_wakeup.attr,
4: &dev_attr_wakeup_count.attr,
5: &dev_attr_wakeup_active_count.attr,
6: &dev_attr_wakeup_abort_count.attr,
7: &dev_attr_wakeup_expire_count.attr,
8: &dev_attr_wakeup_active.attr,
9: &dev_attr_wakeup_total_time_ms.attr,
10: &dev_attr_wakeup_max_time_ms.attr,
11: &dev_attr_wakeup_last_time_ms.attr,
12: #ifdef CONFIG_PM_AUTOSLEEP
13: &dev_attr_wakeup_prevent_sleep_time_ms.attr,
14: #endif
15: #endif
16: NULL,
17: };
18: static struct attribute_group pm_wakeup_attr_group = {
19: .name = power_group_name,
20: .attrs = wakeup_attrs,
21: };
1）wakeup
读，获得设备wakeup功能的使能状态，返回"enabled"或"disabled"字符串。
写，更改设备wakeup功能的使能状态，根据写入的字符串（"enabled"或"disabled"），调用device_set_wakeup_enable接口完成实际的状态切换。
设备wakeup功能是否使能，取决于设备的can_wakeup标志，以及设备是否注册有相应的struct wakeup_source指针。即can wakeup和may wakeup，如下：
1: /*
2: * Changes to device_may_wakeup take effect on the next pm state change.
3: */
4:
5: static inline bool device_can_wakeup(struct device *dev)
6: {
7: return dev->power.can_wakeup;
8: }
9:
10: static inline bool device_may_wakeup(struct device *dev)
11: {
12: return dev->power.can_wakeup && !!dev->power.wakeup;
13: }
2）wakeup_count
只读，获取dev->power.wakeup->event_count值。有关event_count的意义，请参考5.1小节，下同。顺便抱怨一下，这个attribute文件的命名简直糟糕透顶了！直接用event_count就是了，用什么wakeup_count，会和wakeup source中的同名字段搞混淆的！
3）wakeup_active_count，只读，获取dev->power.wakeup->active_count值。
4）wakeup_abort_count，只读，获取dev->power.wakeup->wakeup_count值。
5）wakeup_expire_count，只读，获dev->power.wakeup->expire_count取值。
6）wakeup_active，只读，获取dev->power.wakeup->active值。
7）wakeup_total_time_ms，只读，获取dev->power.wakeup->total_time值，单位为ms。
8）wakeup_max_time_ms，只读，获dev->power.wakeup->max_time取值，单位为ms。
9）wakeup_last_time_ms，只读，获dev->power.wakeup->last_time取值，单位为ms。
10）wakeup_prevent_sleep_time_ms，只读，获取dev->power.wakeup->prevent_sleep_time值，单位为ms。
注6：阅读上述代码时，我们可以看到很多类似“!!dev->power.can_wakeup == !!capable”的、带有两个“！”操作符的语句，是为了保证最后的操作对象非0即1。这从侧面反映了内核开发者的严谨程度，值得我们学习。
5.3.2 device_wakeup_enable/device_wakeup_disable/device_set_wakeup_enable
以device_wakeup_enable为例（其它类似，就不浪费屏幕了）：
1: int device_wakeup_enable(struct device *dev)
2: {
3: struct wakeup_source *ws;
4: int ret;
5:
6: if (!dev || !dev->power.can_wakeup)
7: return -EINVAL;
8:
9: ws = wakeup_source_register(dev_name(dev));
10: if (!ws)
11: return -ENOMEM;
12:
13: ret = device_wakeup_attach(dev, ws);
14: if (ret)
15: wakeup_source_unregister(ws);
16:
17: return ret;
18: }
也很简单：
a）若设备指针为空，或者设备不具备wakeup能力，免谈，报错退出。
b）调用wakeup_source_register接口，以设备名为参数，创建并注册一个wakeup source。
c）调用device_wakeup_attach接口，将新建的wakeup source保存在dev->power.wakeup指针中。
wakeup_source_register接口的实现也比较简单，会先后调用wakeup_source_create、wakeup_source_prepare、wakeup_source_add等接口，所做的工作包括分配struct wakeup_source变量所需的内存空间、初始化内部变量、将新建的wakeup source添加到名称为wakeup_sources的全局链表中、等等。
device_wakeup_attach接口更为直观，不过有一点我们要关注，如果设备的dev->power.wakeup非空，也就是说之前已经有一个wakeup source了，是不允许再enable了的，会报错返回。
5.3.3 pm_stay_awake
当设备有wakeup event正在处理时，需要调用该接口通知PM core，该接口的实现如下：
1: void pm_stay_awake(struct device *dev)
2: {
3: unsigned long flags;
4:
5: if (!dev)
6: return;
7:
8: spin_lock_irqsave(&dev->power.lock, flags);
9: __pm_stay_awake(dev->power.wakeup);
10: spin_unlock_irqrestore(&dev->power.lock, flags);
11: }
呵呵，直接调用__pm_stay_awake，这也是本文的index里没有该接口的原因。接着看代码。
1: void __pm_stay_awake(struct wakeup_source *ws)
2: {
3: unsigned long flags;
4:
5: if (!ws)
6: return;
7:
8: spin_lock_irqsave(&ws->lock, flags);
9:
10: wakeup_source_report_event(ws);
11: del_timer(&ws->timer);
12: ws->timer_expires = 0;
13:
14: spin_unlock_irqrestore(&ws->lock, flags);
15: }
由于pm_stay_awake报告的event需要经过pm_relax主动停止，因此就不再需要timer，所以__pm_stay_awake实现是直接调用wakeup_source_report_event，然后停止timer。接着看代码：
1: static void wakeup_source_report_event(struct wakeup_source *ws)
2: {
3: ws->event_count++;
4: /* This is racy, but the counter is approximate anyway. */
5: if (events_check_enabled)
6: ws->wakeup_count++;
7:
8: if (!ws->active)
9: wakeup_source_activate(ws);
10: }
a）增加wakeup source的event_count，表示该source又产生了一个event。
b）根据events_check_enabled变量的状态，决定是否增加wakeup_count。这和wakeup count的功能有关，到时再详细描述。
c）如果wakeup source没有active，则调用wakeup_source_activate，activate之。这也是5.1小节所描述的，event_count和active_count的区别所在。wakeup_source_activate的代码如下。
1: static void wakeup_source_activate(struct wakeup_source *ws)
2: {
3: unsigned int cec;
4:
5: /*
6: * active wakeup source should bring the system
7: * out of PM_SUSPEND_FREEZE state
8: */
9: freeze_wake();
10:
11: ws->active = true;
12: ws->active_count++;
13: ws->last_time = ktime_get();
14: if (ws->autosleep_enabled)
15: ws->start_prevent_time = ws->last_time;
16:
17: /* Increment the counter of events in progress. */
18: cec = atomic_inc_return(&combined_event_count);
19:
20: trace_wakeup_source_activate(ws->name, cec);
21: }
a）调用freeze_wake，将系统从suspend to freeze状态下唤醒。有关freeze功能，请参考相关的文章。
b）设置active标志，增加active_count，更新last_time。
c）如果使能了autosleep，更新start_prevent_time，因为此刻该wakeup source会开始阻止系统auto sleep。具体可参考auto sleep的功能描述。
d）增加“wakeup events in progress”计数（5.2小节有描述）。该操作是wakeup events framework的灵魂，增加该计数，意味着系统正在处理的wakeup event数目不为零，则系统不能suspend。
到此，pm_stay_awake执行结束，意味着系统至少正在处理一个wakeup event，因此不能suspend。那处理完成后呢？driver要调用pm_relax通知PM core。
5.3.4 pm_relax
pm_relax和pm_stay_awake成对出现，用于在event处理结束后通知PM core，其实现如下：
1: /**
2: * pm_relax - Notify the PM core that processing of a wakeup event has ended.
3: * @dev: Device that signaled the event.
4: *
5: * Execute __pm_relax() for the @dev's wakeup source object.
6: */
7: void pm_relax(struct device *dev)
8: {
9: unsigned long flags;
10:
11: if (!dev)
12: return;
13:
14: spin_lock_irqsave(&dev->power.lock, flags);
15: __pm_relax(dev->power.wakeup);
16: spin_unlock_irqrestore(&dev->power.lock, flags);
17: }
直接调用__pm_relax，如下：
1: void __pm_relax(struct wakeup_source *ws)
2: {
3: unsigned long flags;
4:
5: if (!ws)
6: return;
7:
8: spin_lock_irqsave(&ws->lock, flags);
9: if (ws->active)
10: wakeup_source_deactivate(ws);
11: spin_unlock_irqrestore(&ws->lock, flags);
12: }
如果该wakeup source处于active状态，调用wakeup_source_deactivate接口，deactivate之。deactivate接口和activate接口一样，是wakeup events framework的核心逻辑，如下：
1: static void wakeup_source_deactivate(struct wakeup_source *ws)
2: {
3: unsigned int cnt, inpr, cec;
4: ktime_t duration;
5: ktime_t now;
6:
7: ws->relax_count++;
8: /*
9: * __pm_relax() may be called directly or from a timer function.
10: * If it is called directly right after the timer function has been
11: * started, but before the timer function calls __pm_relax(), it is
12: * possible that __pm_stay_awake() will be called in the meantime and
13: * will set ws->active. Then, ws->active may be cleared immediately
14: * by the __pm_relax() called from the timer function, but in such a
15: * case ws->relax_count will be different from ws->active_count.
16: */
17: if (ws->relax_count != ws->active_count) {
18: ws->relax_count--;
19: return;
20: }
21:
22: ws->active = false;
23:
24: now = ktime_get();
25: duration = ktime_sub(now, ws->last_time);
26: ws->total_time = ktime_add(ws->total_time, duration);
27: if (ktime_to_ns(duration) > ktime_to_ns(ws->max_time))
28: ws->max_time = duration;
29:
30: ws->last_time = now;
31: del_timer(&ws->timer);
32: ws->timer_expires = 0;
33:
34: if (ws->autosleep_enabled)
35: update_prevent_sleep_time(ws, now);
36:
37: /*
38: * Increment the counter of registered wakeup events and decrement the
39: * couter of wakeup events in progress simultaneously.
40: */
41: cec = atomic_add_return(MAX_IN_PROGRESS, &combined_event_count);
42: trace_wakeup_source_deactivate(ws->name, cec);
43:
44:
45: split_counters(&cnt, &inpr);
46: if (!inpr && waitqueue_active(&wakeup_count_wait_queue))
47: wake_up(&wakeup_count_wait_queue);
48: }
a）relax_count加1（如果relax_count和active_count不等，则说明有重复调用，要退出）。
b）清除active标记。
c）更新total_time、max_time、last_time等变量。
d）如果使能auto sleep，更新相关的变量（后面再详细描述）。
e）再欣赏一下艺术，wakeup events in progress减1，registered wakeup events加1。
f）wakeup count相关的处理，后面再详细说明。
5.3.5 pm_wakeup_event
pm_wakeup_event是pm_stay_awake和pm_relax的组合版，在上报event时，指定一个timeout时间，timeout后，自动relax，一般用于不知道何时能处理完成的场景。该接口比较简单，就不一一描述了。
5.3.6 pm_wakeup_pending
drivers产生的wakeup events，最终要上报到PM core，PM core会根据这些events，决定是否要终止suspend过程。这表现在suspend过程中频繁调用pm_wakeup_pending接口上（可参考“Linux电源管理(6)_Generic PM之Suspend功能”）。该接口的实现如下：
1: /**
2: * pm_wakeup_pending - Check if power transition in progress should be aborted.
3: *
4: * Compare the current number of registered wakeup events with its preserved
5: * value from the past and return true if new wakeup events have been registered
6: * since the old value was stored. Also return true if the current number of
7: * wakeup events being processed is different from zero.
8: */
9: bool pm_wakeup_pending(void)
10: {
11: unsigned long flags;
12: bool ret = false;
13:
14: spin_lock_irqsave(&events_lock, flags);
15: if (events_check_enabled) {
16: unsigned int cnt, inpr;
17:
18: split_counters(&cnt, &inpr);
19: ret = (cnt != saved_count || inpr > 0);
20: events_check_enabled = !ret;
21: }
22: spin_unlock_irqrestore(&events_lock, flags);
23:
24: if (ret)
25: print_active_wakeup_sources();
26:
27: return ret;
28: }
该接口的逻辑比较直观，先抛开wakeup count的逻辑不谈（后面会重点说明），只要正在处理的events不为0，就返回true，调用者就会终止suspend。
5.4 wakeup count、wake lock和auto sleep
这篇文章写的有点长了，不能继续了，这几个功能，会接下来的文章中继续分析。
原创文章，转发请注明出处。蜗窝科技，www.wowotech.net。
标签: Linux 电源管理 wakeup events framework
评论：
2015-07-15 19:31
====================================================
不能这么武断的，用户空间的suspend同步，还是需要它的。
2015-07-15 19:44
我指的是wakeup_count的两个sysfs，用户空间suspend同步的时候会读取/sys/power/wakeup_count吗？
2015-07-15 20:02
主要是为了解决用户空间PM进程写state，和其它进程之间的同步问题。
例如：
A进程判断suspend条件成立，准备write state；
产生一个event，发生调度，执行B进程；
B进程处理这个event；
B进程处理event时，发生调度，执行A进程；
A进程误以为条件仍然成立，继续write state（这就不合理了）。
2015-06-03 18:48
想請教一下文中以下的freeze_wake()是否就是可以將系統從deep sleep(於suspend.c中error = suspend_ops->enter(state);)狀態下wakeup回來的functions.？？
static void wakeup_source_activate(struct wakeup_source *ws)
{
...
/*
* active wakeup source should bring the system
* out of PM_SUSPEND_FREEZE state
*/
freeze_wake();
...
}
2015-05-20 10:11
我在项目中，遇到了如下问题，请问下如何分析定位解决呢？
Android 4.4系统唤醒后在亮屏前会Write系统调用驱动设备节点/sys/power/ autosleep，写"off"直接耗时5.1s，导致唤醒亮屏慢.
对应log：
05-14 14:57:34.443 V/libsuspend( 852): autosuspend_autosleep_disable
// 耗时5.1S
05-14 14:57:39.573 V/libsuspend( 852): autosuspend_autosleep_disable done
05-14 14:57:39.573 D/PowerManagerService-JNI( 852): Excessive delay in autosuspend_disable() while turning screen on: 5132ms
对应日志的系统代码（system/core/libsuspend/Autosuspend_autosleep.c）：
ALOGV("autosuspend_autosleep_disable\n");
ret = write(autosleep_fd, on_state, strlen(on_state));
if (ret < 0) {
strerror_r(errno, buf, sizeof(buf));
ALOGE("Error writing to %s: %s\n", SYS_POWER_AUTOSLEEP, buf);
goto err;
}
ALOGV("autosuspend_autosleep_disable done\n");
2015-05-11 19:34
当我按电源键的时候进入suspend过程，在这个过程中会申请ｗakelock和释放wakelock最终suspend下去的过程．
但是还是不明白ｓｕｓｐｅｎｄ的过程中如何检测wakeup event 和wakeup count 的数量之后进入suspend 的．
给提示一下关键点吗？谢谢！
2015-05-04 20:45
恰好看到了您的blog，受益匪浅。不过其中也有很多地方有些深，看不太懂。
最近在调Android,若用户层 echo 1 > /sys/power/wake_lock 可以防止系统深度睡眠STR，然而系统还是会灭屏，请教这是为什么呢？百思不得其解。Android 5.0中貌似没有early suspend呀。
2015-05-02 15:59
--赞同，这也是android做的比较不合理的地方。第三方apk可以随意操作wake lock。加之写apk的人水平良莠不齐。andorid对apk又没有像苹果那样的审核机制。就容易出现下载一些apk后（遇到过中国顶级互联网的apk出现过这种低级错误，名字不透漏了）导致系统无法进入 deep sleep的问题。总之这块android做的不好。
2015-02-03 21:56
2014-12-25 15:40
A. 将设备声明为可唤醒源的API：device_init_wakeup(), 对wake_souce初始化，绑定device和wakewource，这个函数是driver主动调用的，所以driver应该知道自己是否具备唤醒系统的能力，也即设备是否拥有一个唤醒中断源。不过，涉及中断的话，就跟平台相关了，可能需要把一个普通中断设置为唤醒中断（有些SoC可能电气特性就决定某些中断线是唤醒源），那这样的话，仅仅调用device_init_wakeup()来声明一个唤醒源应该是不够的，应该还需要调用irq_enable_wake(), 不知道这样理解对不对？看到好些驱动只是调用device_init_wakeup()，还是说我忽略什么地方？
B. Wake Event 需要驱动在唤醒中断源ISR里主动调用pm_wakeup_event()上报事件，对吧？
2014-12-25 18:48
关于你的问题：
A. 我理解的也不是很全面，只能提一些大概的思路。现在kernel关于设备的wakeup能力，有两种方法：一是和wakeup events framework相关的机制，不过现在确实用的不多；另外一种，是比较传统的方法，你可以参考IRQF_NO_SUSPEND（request IRQ是提供的），以及下面的过程--suspend_enter-->dpm_suspend_end-->dpm_suspend_noirq-->suspend_device_irqs-->__disable_irq。
B. 上报事件，一定是driver主动上报，至于是否需要上报，在哪里上报，则由具体的driver逻辑决定。
2014-12-25 19:50
2015-05-03 22:42
wakeup source，wakeup event 感觉名字起的不好。
1，这里就涉及到wakeup的意思了，何为wakeup？我的理解只有系统进入深度睡眠后（一般主晶振停止震动，程序也不跑了），把系统唤醒才叫wakeup。
2，调用device_init_wakeup()，以及产生wakeup event，根本无法把系统从深度睡眠唤醒，把系统从深度睡眠唤醒一般需要中断产生。 而wakeup souce 产生wakeup event的目的不是把系统从深度睡眠唤醒，而是防止系统进入深度睡眠。
基于以上两点。我感觉wakupe souce以及wakeup event名字修改blocksuspend source，blocksuspend event更好。
不知我理解是否正确。
另外
看到好些驱动只是调用device_init_wakeup() -- ，调用这个的一一般会调用pm_stay_awake产生wakup event事件。或者在配合device_can_wakup使用。
2015-05-04 11:44
我具备wakeup的能力，我就是wakeup source；我产生了一个event，这个event可能会wakeup系统，它就是wakeup event。无论它最终是否wakeup了系统（因为很有可能此时系统没有sleep）。
至于wakeup的定义，也不一定非得要sleep加中断，这只是其中的一种形式，或者说狭义的形式。
2015-05-05 20:59
功能
最新评论
文章分类
随机文章
文章存档
- 2024年2月(1)
- 2023年5月(1)
- 2022年10月(1)
- 2022年8月(1)
- 2022年6月(1)
- 2022年5月(1)
- 2022年4月(2)
- 2022年2月(2)
- 2021年12月(1)
- 2021年11月(5)
- 2021年7月(1)
- 2021年6月(1)
- 2021年5月(3)
- 2020年3月(3)
- 2020年2月(2)
- 2020年1月(3)
- 2019年12月(3)
- 2019年5月(4)
- 2019年3月(1)
- 2019年1月(3)
- 2018年12月(2)
- 2018年11月(1)
- 2018年10月(2)
- 2018年8月(1)
- 2018年6月(1)
- 2018年5月(1)
- 2018年4月(7)
- 2018年2月(4)
- 2018年1月(5)
- 2017年12月(2)
- 2017年11月(2)
- 2017年10月(1)
- 2017年9月(5)
- 2017年8月(4)
- 2017年7月(4)
- 2017年6月(3)
- 2017年5月(3)
- 2017年4月(1)
- 2017年3月(8)
- 2017年2月(6)
- 2017年1月(5)
- 2016年12月(6)
- 2016年11月(11)
- 2016年10月(9)
- 2016年9月(6)
- 2016年8月(9)
- 2016年7月(5)
- 2016年6月(8)
- 2016年5月(8)
- 2016年4月(7)
- 2016年3月(5)
- 2016年2月(5)
- 2016年1月(6)
- 2015年12月(6)
- 2015年11月(9)
- 2015年10月(9)
- 2015年9月(4)
- 2015年8月(3)
- 2015年7月(7)
- 2015年6月(3)
- 2015年5月(6)
- 2015年4月(9)
- 2015年3月(9)
- 2015年2月(6)
- 2015年1月(6)
- 2014年12月(17)
- 2014年11月(8)
- 2014年10月(9)
- 2014年9月(7)
- 2014年8月(12)
- 2014年7月(6)
- 2014年6月(6)
- 2014年5月(9)
- 2014年4月(9)
- 2014年3月(7)
- 2014年2月(3)
- 2014年1月(4)
2015-07-15 16:54
===================================================
PM core中的关于wakeup_count的两个sysfs，实际上没有多大的意义。尤其是wakeup_count_store，用户空间不会去写wake event的数目的。
其实我的理解，解决用空空间同步的问题，主要是给driver层提供了pm_wakeup_event，pm_stay_awake，以及pm_wake_lock等接口，让driver向PM core上报一个虚拟/抽象的wakeup event。
而系统是否被阻止suspend，是基于wakeup count的cnt和inpr的检查。