earlysuspend调用过程

1. 电源管理的状态

Android的Linux内核为系统提供了4种电源状态，内核的源码为当中的3种定义了名字和相应的宏定义，名字定义在kernel/power/suspend.c中：

constchar*const pm_states[PM_SUSPEND_MAX]={ #ifdef CONFIG_EARLYSUSPEND [PM_SUSPEND_ON]        ="on", #endif [PM_SUSPEND_STANDBY]   ="standby", [PM_SUSPEND_MEM] ="mem", };

相应的宏定义在：include/linux/suspend.h中：

typedefint __bitwise suspend_state_t; #define PM_SUSPEND_ON          ((__force suspend_state_t) 0) #define PM_SUSPEND_STANDBY     ((__force suspend_state_t) 1) #define PM_SUSPEND_MEM         ((__force suspend_state_t) 3) #define PM_SUSPEND_MAX         ((__force suspend_state_t) 4)

非常奇怪的是，第四种状态（disk）没有详细的定义，而是硬编码在代码中，不明确为什么会这样做，至少我如今看的版本号是这样（2.6.35），这样的就是所谓的suspend to disk或者叫hibernate。只是这不是重点，再说，眼下也非常少有Android的设备支持hibernate。

顾名思义：

PM_SUSPEND_ON— 设备处于全电源状态，也就是正常工作状态；

PM_SUSPEND_STANDBY— 设备处于省电状态，但还能够接收某些事件，详细的行为取决与详细的设备；

PM_SUSPEND_MEM— suspend to memory，设备进入睡眠状态，但全部的数据还保存在内存中，仅仅有某些外部中断才干够唤醒设备；

眼下，大多数的Android设备都仅仅支持当中的两种：PM_SUSPEND_ON 和 PM_SUSPEND_MEM，所以以下的讨论说道suspend的地方，均是指PM_SUSPEND_MEM。

2. Early Suspend、Late Resume

Early Suspend和Late Resume是Android在标准Linux的基础上添加的一项特性。当用户空间的向内核请求进入suspend时，这时候会先进入early suspend状态，驱动程序能够注冊early suspend的回调函数，当进入该状态时，内核会逐一地调用这些回调函数。比如显示屏的驱动程序一般会注冊early
suspend，在他的回调函数中，驱动程序会把屏幕和背光都关闭。在这样的状态下，全部的后台进程都还在活动中，该播放歌曲的播放歌曲，该下载数据的依旧在下载，仅仅是显示屏不良而已。进入early suspend状态以后，一旦全部的电源锁（wake lock）被释放，系统立即会进入真正的suspend流程，直到最后系统停止工作，等待外部事件的唤醒。

3. Android的电源锁机制：wake lock

Android相比标准的Linux内核，在电源管理中增加了wake lock机制。一旦申请了某种类型的锁，电源管理模块将会“锁住”某一种电源状态，眼下，Android提供了两种类型的锁：

WAKE_LOCK_SUSPEND— 阻止系统进入suspend状态；

WAKE_LOCK_IDLE— 阻止系统进入idle状态；

wake lock也能够设定超时，时间一到，自己主动释放该锁。

有关wake lock的代码在：kernel/power/wakelock.c中。

4. 电源状态迁移

内核启动完毕以后，电源管理系统会在sysfs文件系统中建立3个文件：

/sys/power/state /sys/power/wake_lock /sys/power/wake_unlock

电源状态的迁移首先由用户空间的应用程序发起，当系统应用检測到一定时间内没实用户活动后（比如触摸屏、按键），能够向/sys/power/state文件写入对应的电源状态名称（请參考第一节内容），假设写入“mem”，将会触发内核启动suspend的流程，内核将会依照图2.1进行状态的迁移。应用程序也能够通过/sys/power/wake_lock申请一个WAKE_LOCK_SUSPEND
类型的锁，对应地，通过/sys/power/wake_unlock则能够释放一个锁。内核在进入suspend之前假设检測到某个锁没有释放，则会放弃本次的suspend过程，直到这个锁释放为止。

基于Android的Linux内核的电源管理：Early Suspend

1. 用户空间的接口

在kernel/power/main.c中，定义了一组sysfs的属性文件，当中一个定义是：

power_attr(state);

把这个宏展开后:

staticstruct kobj_attribute state_attr={ \ .attr={                               \ .name="state",   \ ,                          \ },                                           \ .show     =state_show,                          \ .store      =state_store,                 \ }

我们再看看main.c的入口：

staticint __init pm_init(void) { ...... power_kobj=kobject_create_and_add("power", NULL); if(!power_kobj) return-ENOMEM; return sysfs_create_group(power_kobj,&attr_group); }

显然，该函数运行后，会在生成/sys/power文件夹，该文件夹下会建立一系列属性文件，当中一个就是/sys/power/state文件。用户空间向该文件的写入将会导致state_store被调用，读取该文件将会导致state_show函数被调用。

如今回到Android的HAL层中，查看一下代码：hardware/libhardware_legacy/power/power.c：

//定义写入/sys/power/state的命令字符串 staticconst char*off_state="mem"; staticconst char*on_state="on"; //打开/sys/power/state等属性文件，保存对应的文件描写叙述符 staticint open_file_descriptors(constchar*const paths[]) { int i; ; i 终于，用户空间的电源管理系统会调用set_screen_state函数来触发suspend的流程，该函数实际上就是往/sys/power/state文件写入"mem"或"on"命令字符串。 <pre lang="c" line="1">int set_screen_state(inton) { ...... initialize_fds(); ...... ]; int len; if(on) len = snprintf(buf,sizeof(buf),"%s", on_state); else len = snprintf(buf,sizeof(buf),"%s", off_state); ]='\0'; len = write(g_fds[REQUEST_STATE], buf,len); ...... ; }

2. 内核中数据结构和接口

与earlysuspend相关的数据结构和接口都在earlysuspend.h中进行了定义。

- early_suspend结构

struct early_suspend{ #ifdef CONFIG_HAS_EARLYSUSPEND structlist_head link; int level; void(*suspend)(struct early_suspend *h); void(*resume)(struct early_suspend *h); #endif };

希望运行early suspend的设备，他的设备驱动程序须要向电源管理系统注冊，该结构体用于向电源管理系统注冊earlysuspend/lateresume，当电源管理系统启动suspend流程时，回调函数suspend会被调用，相反，resume的最后阶段，回调函数resume会被调用，level字段用于调整该结构体在注冊链表中的位置，suspend时，level的数值越小，回调函数的被调用的时间越早，resume时则反过来。Android预先定义了3个level等级：

enum{ , , , };

假设你想你的设备在FB设备被禁止之前运行他的early suspend回调，设备驱动程序应该把level值设定为小于150的某个数值，然后向系统注冊early_suspend结构。注冊和反注冊函数是：

void register_early_suspend(struct early_suspend *handler); void unregister_early_suspend(struct early_suspend *handler);

early_suspend_handlers链表

全部注冊到系统中的early_suspend结构都会按level值按顺序增加到全局链表early_suspend_handlers中。

3.
工作流程

首先，我们从kernel/power/wakelock.c中的初始化函数開始：

staticint __init wakelocks_init(void) { int ret; int i; ...... ; i< ARRAY_SIZE(active_wake_locks); i++) INIT_LIST_HEAD(&active_wake_locks[i]); ...... wake_lock_init(&main_wake_lock, WAKE_LOCK_SUSPEND,"main"); wake_lock(&main_wake_lock); wake_lock_init(&unknown_wakeup, WAKE_LOCK_SUSPEND,"unknown_wakeups"); ...... ret= platform_device_register(&power_device); ret = platform_driver_register(&power_driver); ...... suspend_work_queue= create_singlethread_workqueue("suspend"); ...... ; }

能够看到，显示初始化active_wake_locks链表数组，然后初始化而且锁住main_wake_lock，注冊平台设备power_device，这些数组、锁和power_device我们在兴许文章再讨论，这里我们关注的最后一个动作：创建了一个工作队列线程suspend_work_queue，该工作队列是earlysuspend的核心所在。

系统启动完毕后，相关的驱动程序通过register_early_suspend()函数注冊了early suspend特性，等待一段时间后，假设没实用户活动（比如按键、触控等操作），用户空间的电源管理服务终于会调用第一节提到的set_screen_state()函数，透过sysfs，进而会调用到内核中的state_store()：

static ssize_t state_store(struct kobject*kobj,struct kobj_attribute*attr, constchar*buf, size_t n) { #ifdef CONFIG_SUSPEND #ifdef CONFIG_EARLYSUSPEND suspend_state_t state = PM_SUSPEND_ON; #else suspend_state_t state = PM_SUSPEND_STANDBY; #endif constchar*const*s; #endif char*p; int len; int error=-EINVAL; p = memchr(buf,'\n', n); len = p ? p- buf : n; /* First, check if we are requested to hibernate */ &&!strncmp(buf,"disk", len)){ error = hibernate(); goto Exit; } #ifdef CONFIG_SUSPEND for(s=&pm_states[state]; state < PM_SUSPEND_MAX; s++, state++){ if(*s&& len== strlen(*s)&&!strncmp(buf,*s, len)) break; } if(state< PM_SUSPEND_MAX&&*s) #ifdef CONFIG_EARLYSUSPEND if(state== PM_SUSPEND_ON|| valid_state(state)){ error =; request_suspend_state(state); } #else error = enter_state(state); #endif #endif Exit: return error? error : n; }

看到了没，前一篇文章说过，suspend to disk做了特殊处理，这里直接比較传入的字符串，而不是使用兴许的pm_states数组，这里我不关心suspend to disk，所以略过hibernate的分析。

紧接着，通过pm_states数组，依据命令字符串查询得到请求的状态，默认情况下，Android的内核都会配置了CONFIG_EARLYSUSPEND，所以会调用request_suspend_state()函数，只是在调用该函数之前会先valid_state()一下，这给了平台相关的代码一个机会确认该平台是否支持所请求的电源状态。valid_state()的详细实现请參考内核代码树。

void request_suspend_state(suspend_state_t new_state) { unsignedlong irqflags; int old_sleep; spin_lock_irqsave(&state_lock, irqflags); old_sleep = state & SUSPEND_REQUESTED; ...... if(!old_sleep&& new_state!= PM_SUSPEND_ON){ state |= SUSPEND_REQUESTED; if(queue_work(suspend_work_queue,&early_suspend_work)) pr_info("early_suspend_work is in queue already\n"); }elseif(old_sleep&& new_state== PM_SUSPEND_ON){ state &= ~SUSPEND_REQUESTED; wake_lock(&main_wake_lock); if(!queue_work(suspend_work_queue,&late_resume_work)) pr_info("late_resume_work is in queue already\n"); } requested_suspend_state = new_state; spin_unlock_irqrestore(&state_lock, irqflags); }

还记得前面初始化时建立的工作队列suspend_woek_queue吗？依据之前的电源状态和请求的状态， request_suspend_state()仅仅是简单地向suspend_work_queue中增加early_suspend_work或者是late_resume_work并调度他们运行。early_suspend_work的工作函数是early_suspend()：

staticvoid early_suspend(struct work_struct*work) { struct early_suspend*pos; unsignedlong irqflags; ; mutex_lock(&early_suspend_lock); spin_lock_irqsave(&state_lock,irqflags); if(state== SUSPEND_REQUESTED) state |= SUSPENDED; else abort =; spin_unlock_irqrestore(&state_lock,irqflags); if(abort){ ...... } ...... list_for_each_entry(pos,&early_suspend_handlers, link){ if(pos->suspend!= NULL){ if(debug_mask&DEBUG_SUSPEND) printk(KERN_DEBUG"pos->suspend: %pF begin\n", pos->suspend); pos->suspend(pos); if(debug_mask&DEBUG_SUSPEND) printk(KERN_DEBUG"pos->suspend: %pF finish\n", pos->suspend); } } mutex_unlock(&early_suspend_lock); if(debug_mask& DEBUG_SUSPEND) pr_info("early_suspend:sync\n"); sys_sync(); abort: spin_lock_irqsave(&state_lock,irqflags); if(state==SUSPEND_REQUESTED_AND_SUSPENDED) wake_unlock(&main_wake_lock); spin_unlock_irqrestore(&state_lock,irqflags); }

最终看到啦，early_suspend()遍历early_suspend_handlers链表，从中取出各个驱动程序注冊的early_suspend结构，然后调用它的suspend回调函数。最后，释放main_wake_lock锁，至此整个earlysuspend的流程完毕。以下的序列图清晰地表明了整个调用的过程：



可是，这时整个系统仅仅是处于所谓的idle状态，cpu还在工作，后台进程也在工作中，那什么时候系统会真正地进入睡眠状态？注意到最后一句关键的调用了没有：

wake_unlock(&main_wake_lock);