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:

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

评论:

Edward
2019-01-08 17:41
Dear wowo:
我cat wakeup source发现某个wakeup source,event_count在持续增长,如何得知是哪个进程在不断触发这个wakeup source?
wowo
2019-01-10 19:25
@Edward:kernel的wakeup event面向的对象是设备,而非进程。
当然,用户程序所使用的wake_lock除外。
kernel_123
2017-09-05 17:55
Hi wowo
咨询个问题.

当系统进入到suspend流程后,如果有wakeup event产生,是通过pm_wakeup_pending函数去判断的.
当系统插入usb后,这时候会激活唤醒源,增加events in progress个数,在插入usb的情况下按下power按键,系统是如何阻止不进suspend流程的?从代码上看只是激活唤醒源,增加events in progress的个数,确实没有找到阻止系统不进suspend的流程的代码块? 还系统解答.谢谢
wowo
2017-09-05 19:49
@kernel_123:插入usb之后,usb会产生一个wakeup event,然后用户空间的某些程序起来(一般是power manager service),加一把锁,这样系统就没有机会suspend了。你可以去/sys/power下面确认一下,看看是哪把锁。
keke
2017-05-26 10:55
@wowo
您好,感谢您的分享,看了收获很大。想请教您个问题:您说到"wakeup events产生后,通常是以中断的形式通知device driver"。我现在有一个问题,当系统suspend后,所有的device应该也是suspend的。
当有wake event(比如按键)时,系统resume,这时各个device也会resume,但是我不想让某个device(例如usb)resume。能不能通过不触发usb中断的方式,让usb继续suspend?怎么操作呢?谢谢
wowo
2017-05-26 11:03
@keke:你这个其实是runtime pm的需求:只要usb没有工作,就可以处于某一种低功耗状态。唤醒的时机有二:
1. 软件主动唤醒(主动发送数据等)。
2. 被动事件唤醒(例如phy收到数据,产生中断)。这种情况,一般需要usb controller支持(大部分的controller都支持)。
keke
2017-05-26 11:49
@wowo:@wowo
谢谢wowo的回复。
1)您的意思说虽然是系统从suspend->resume,但对usb来说,它的suspend->resume其实是和runtime时是一样的?但是我调试时,usb有两种情况的resume:系统suspend时的和runtime时的,而且当系统resume时,确实是走的usb中非runtime时resume的代码。
2)我现在usb接口上一直插着u盘(或者其他usb设备),当系统suspend->resume时,应该会有数据的收发吧?所以会唤醒usb controller?
谢谢
keke
2017-05-26 11:55
@keke:@wowo
我现在想法是即使usb口上插着设备,也让usb一直睡着,直到我人为从用户层唤醒它。能这样做吗?
wowo
2017-05-31 17:26
@keke:这样没有问题啊,如果都是从用户层控制,想怎么做都可以啊,例如自定义几个ioctl,让USB睡或者醒。
keke
2017-06-05 10:06
@wowo:明白了,感谢感谢。
jiangxinyu
2016-11-17 18:36
Hi wowo:
看了你的系列文章,受益匪浅。有个疑惑想请教您下。
背景是,当系统处在深度睡眠状态下,通过外部的IO中断来唤醒系统(android5.1),在中断的处理函数内加pm_wakeup_event,理论上是可以实现唤醒目的的(前提是需要将这个IO注册为wakeup source).我的疑惑是这个wakeup event是如何将唤醒事件传到user space?Android的power manager service怎么获知这一事件从而完全active系统,比如亮屏。我看了一下,pm_wakeup_event到最后无非是控制“wakeup events in progress”不为0,达到不让进休眠的目的,没有找到上报事件到用户空间的地方,望指教。
wowo
2016-11-17 18:45
@jiangxinyu:kernel event要做的事情很单纯:唤醒系统(包括kernel以及用户进程)。因此,从这个角度看,android醒来了,目的达到了。至于android醒来之后,是否会重新睡下去(就是你这里的疑问),取决于这个“事件”的性质,值不值得android保持清醒,甚至打开屏幕。因此android的某个service需要在系统醒来后,检查这个事件,以便进行后续的动作(例如亮屏,例如继续睡)。
jiangxinyu
2016-11-17 18:50
@wowo:@wowo:感谢回复。您回答的后半部分懂了,想确认一下,您的这一句话“唤醒系统(包括kernel以及用户进程)”是哪个地方实现的,我看了kernel代码,看起来是这里,对吗?
void freeze_wake(void)
{
    suspend_freeze_wake = true;
    wake_up(&suspend_freeze_wait_head);
}
wowo
2016-11-17 18:57
@jiangxinyu:其实就是suspend_finish中的那些东西。
PS:系统是怎么睡下去的,就要怎么醒过来。
jiangxinyu
2016-11-17 19:02
@wowo:非常感谢,明白了
qilin
2016-11-18 11:57
@wowo:@wowo android醒来了,目的达到了。--- 那么在libsuspend想要再次进入休眠流程时,android上层还没有来得及处理kernel传上来的数据(比如powerkey事件),而且上层也没有持wakelock的话,那是否会错过,又进入suspend流程里面休眠下去了。 如果有的话,对这种情况又如何避免呢,谢谢~
wowo
2016-11-18 13:16
@qilin:如果kernel在上报event的时候,携带了timeout参数,那么这个event会在一定的时间之后自动被relax,就有可能出现你这里提到的错过的情况。
如果想避免这种风险,一般是这样做:
kernel产生事件时,产生一个永久的event;
应用处理完这个事件之后(例如read),再relax它。
qilin
2016-11-18 15:10
@wowo:应用处理完这个事件之后(例如read)-----假如应用在处理这个事的时候没有加wakelock锁呢?这时候autosuspend_wakeup_count.c走过了100ms,然后告诉kernel说:你可以再睡了。
其实还是一个同步问题:按键来了,kernel醒了,等待android上层处理,上层处理时获取wakelock锁,就怕上层还没醒或者没有及时获取锁,就有自动机制再次触发kernel又睡了。这里同步又如何保证。(即如何保证fw上层获取wakelock锁在libsuspend下一次触发kernel suspend之前呢)
wowo
2016-11-18 15:43
@qilin:应用都在处理事情了,还不加锁,这就是应用的问题了。
qilin
2016-11-18 16:03
@wowo:也是哦,:-) 感谢,一直关注wowotech,学到很多。。
timor
2016-11-01 11:08
void __pm_wakeup_event(struct wakeup_source *ws, unsigned int msec)
1.  首先上报wakupsource事件
2.  msec=0, 则立马disable wakeup source
3.  msec !=0, 则在timeout之后disable wakeup source的。

对于第三步没有找到是如何走进定时器的超时函数pm_wakeup_timer_fn, 还请指点, :)
wowo
2016-11-01 11:28
@timor:wakeup_source_add
    setup_timer(&ws->timer, pm_wakeup_timer_fn, (unsigned long)ws);
    
__pm_wakeup_event
    mod_timer(&ws->timer, expires);
timor
2016-11-01 11:43
@timor:刚能看错了,有的驱动没有调用device_init_wakeup函数,也就是没有建立wakeup source到device的关系。

而有的驱动是在probe函数中调用device_init_wakeup函数,然后在中断处理函数中调用pm_wakeup_event函数。

真不知道,为啥有的驱动这样做。
faker
2016-10-27 19:47
调用atomic_add_return(MAX_IN_PROGRESS, &combined_event_count);之后wakeup events in progress减1,registered wakeup events加1。

这样的话registered wakeup events一直在高16位增加,会不会出现越界问题?
wowo
2016-10-28 09:17
@faker:这是个好问题啊,我以前确实没有想过。从代码逻辑看,答案是肯定的:会越界。但这又有什么关系?
我们再问一个问题:越界的后果是什么?
答案是没什么。
wakeup count是为了解决suspend时的用户空间同步问题,即使越界了,也是没有问题的。
可参考这篇文章:http://www.wowotech.net/pm_subsystem/wakeup_count.html
西人
2016-10-09 18:55
注6:阅读上述代码时,我们可以看到很多类似“!!dev->power.can_wakeup == !!capable”的、带有两个“!”操作符的语句,是为了保证最后的操作对象非0即1。这从侧面反映了内核开发者的严谨程度,值得我们学习。
------------------------------------------------------------------------
这句话不是很理解,我觉得“!dev->power.can_wakeup == !capable”效果也是一样的啊,为什么要两个!!
wowo
2016-10-09 20:10
@西人:之所以两个!,我的理解,他是要保持“形式上”的正确性,因为判断的是dev->power.can_wakeup == capable,而不是!dev->power.can_wakeup == !capable。当然,实际的效果是一样的。
默默地牛逼
2016-09-29 17:28
@wowo:wowo你好,有一个类型windows的需求,usb鼠标滑动把android系统从深度睡眠中唤醒的需求;根据我的了解从suspend中唤醒系统都是通过将一个中断设置为 enable_irq_wake,通过这种形式唤醒;而usb是典型的主从设备,只能主机端主动读取从机数据。不知道博主有何思路或方向
wowo
2016-09-29 21:08
@默默地牛逼:这种情况下,一般都是USB controller还在活着(或者处于可以感知USB鼠标动作的状态)。
默默地牛逼
2016-10-02 18:51
@wowo:非常感谢
南山南
2016-01-19 11:56
registered wakeup events和saved_count和event_count,

这几个之间是什么关系?设计这几个变量的目的?
有点混乱。望能够解释一下。感谢
wowo
2016-01-19 13:06
@南山南:5.2小节已经有解释,你可以先看一下,如果还不明白,可以有针对性的问。
南山南
2016-01-20 14:21
@wowo:非常感谢。根据定义,我理解
registered wakeup events是指总的可以处理的event个数吧;
#define MAX_IN_PROGRESS ((1<<IN_PROGRESS_BITS) -1).

不知是否是这个意思?
之前一直理解为registered wakeup event和save_count是一个变量。
wowo
2016-01-20 14:43
@南山南:registered wakeup events是总的event的个数。我不太理解你这里“可处理的”是什么意思。只要是报上去的event,都会记录在这个变量中。
而save_count是registered wakeup events的一个快照,用于实现wakeup count功能。
当程序要休眠的时候,会写wakeup count,这时会记录一个快照(保存在saved_count中)。
程序写完wakeup count之后,会接着读这个值,此时如果快照和registered wakeup events一致,则允许suspend。
以上具体可参考http://www.wowotech.net/linux_kenrel/wakeup_count.html
Norz
2016-01-09 01:27
博主,你好,目前遇到一个问题,预想的是设备中断通过kill_async产生SIGIO给JNI层的进程,但是在系统suspend后,JNI层的进程被Freeze了,竟然无法即时响应(通常是不响应),之后系统就又睡过去了,不知道这种情况,有没有好的解决方法呢?
wowo
2016-01-09 21:08
@Norz:设备中断中应该发送一个有超时时间的wakeup event,给JNI进程一定的处理时间。如果这一段时间还不处理,再睡下去。

发表评论:

Copyright @ 2013-2015 蜗窝科技 All rights reserved. Powered by emlog