基于Android的Linux内核的电源管理
转自:http://blog.csdn.net/droidphone/article/details/6642081
基于Android的Linux内核的电源管理:概述
1. 电源管理的状态
Android的Linux内核为系统提供了4种电源状态,内核的源代码为其中的3种定义了名字和对应的宏定义,名字定义在kernel/power/suspend.c中:
[cpp] view plain copy
- constchar*constpm_states[PM_SUSPEND_MAX]={
- #ifdefCONFIG_EARLYSUSPEND
- [PM_SUSPEND_ON]="on",
- #endif
- [PM_SUSPEND_STANDBY]="standby",
- [PM_SUSPEND_MEM]="mem",
- };
[cpp] view plain copy
对应的宏定义在:include/linux/suspend.h中:
- typedefint__bitwisesuspend_state_t;
- #definePM_SUSPEND_ON((__forcesuspend_state_t)0)
- #definePM_SUSPEND_STANDBY((__forcesuspend_state_t)1)
- #definePM_SUSPEND_MEM((__forcesuspend_state_t)3)
- #definePM_SUSPEND_MAX((__forcesuspend_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流程,直到最后系统停止工作,等待外部事件的唤醒。
图2.1 电源状态的转换
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);
把这个宏展开后:
[cpp] view plain copy
- staticstructkobj_attributestate_attr={\
- .attr={\
- .name="state",\
- .mode=0644,\
- },\
- .show=state_show,\
- .store=state_store,\
- }
[cpp] view plain copy
我们再看看main.c的入口:
- staticint__initpm_init(void)
- {
- ......
- power_kobj=kobject_create_and_add("power",NULL);
- if(!power_kobj)
- return-ENOMEM;
- returnsysfs_create_group(power_kobj,&attr_group);
- }
显然,该函数执行后,会在生成/sys/power目录,该目录下会建立一系列属性文件,其中一个就是/sys/power/state文件。用户空间向该文件的写入将会导致state_store被调用,读取该文件将会导致state_show函数被调用。
现在回到Android的HAL层中,查看一下代码:hardware/libhardware_legacy/power/power.c:
[cpp] view plain copy
- //定义写入/sys/power/state的命令字符串
- staticconstchar*off_state="mem";
- staticconstchar*on_state="on";
- //打开/sys/power/state等属性文件,保存相应的文件描述符
- staticint
- open_file_descriptors(constchar*constpaths[])
- {
- inti;
- for(i=0;i<OUR_FD_COUNT;i++){
- intfd=open(paths[i],O_RDWR);
- if(fd<0){
- fprintf(stderr,"fatalerroropening\"%s\"\n",paths[i]);
- g_error=errno;
- return-1;
- }
- g_fds[i]=fd;
- }
- g_error=0;
- return0;
- }
最终,用户空间的电源管理系统会调用set_screen_state函数来触发suspend的流程,该函数实际上就是往/sys/power/state文件写入"mem"或"on"命令字符串。
[cpp] view plain copy
- int
- set_screen_state(inton)
- {
- ......
- initialize_fds();
- ......
- charbuf[32];
- intlen;
- if(on)
- len=snprintf(buf,sizeof(buf),"%s",on_state);
- else
- len=snprintf(buf,sizeof(buf),"%s",off_state);
- buf[sizeof(buf)-1]='\0';
- len=write(g_fds[REQUEST_STATE],buf,len);
- ......
- return0;
- }
/********************************************************************************************/
声明:本博内容均由http://blog.csdn.net/droidphone原创,转载请注明出处,谢谢!
/********************************************************************************************/
2.内核中数据结构和接口
与earlysuspend相关的数据结构和接口都在earlysuspend.h中进行了定义。
- early_suspend 结构
[cpp] view plain copy
- structearly_suspend{
- #ifdefCONFIG_HAS_EARLYSUSPEND
- structlist_headlink;
- intlevel;
- void(*suspend)(structearly_suspend*h);
- void(*resume)(structearly_suspend*h);
- #endif
- };
希望执行early suspend的设备,他的设备驱动程序需要向电源管理系统注册,该结构体用于向电源管理系统注册earlysuspend/lateresume,当电源管理系统启动suspend流程时,回调函数suspend会被调用,相反,resume的最后阶段,回调函数resume会被调用,level字段用于调整该结构体在注册链表中的位置,suspend时,level的数值越小,回调函数的被调用的时间越早,resume时则反过来。Android预先定义了3个level等级:
[cpp] view plain copy
- enum{
- EARLY_SUSPEND_LEVEL_BLANK_SCREEN=50,
- EARLY_SUSPEND_LEVEL_STOP_DRAWING=100,
- EARLY_SUSPEND_LEVEL_DISABLE_FB=150,
- };
[cpp] view plain copy
- 如果你想你的设备在FB设备被禁止之前执行他的earlysuspend回调,设备驱动程序应该把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中的初始化函数开始:
[cpp] view plain copy
- staticint__initwakelocks_init(void)
- {
- intret;
- inti;
- ......
- for(i=0;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");
- ......
- return0;
- }
可以看到,显示初始化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():
[cpp] view plain copy
- staticssize_tstate_store(structkobject*kobj,structkobj_attribute*attr,
- constchar*buf,size_tn)
- {
- #ifdefCONFIG_SUSPEND
- #ifdefCONFIG_EARLYSUSPEND
- suspend_state_tstate=PM_SUSPEND_ON;
- #else
- suspend_state_tstate=PM_SUSPEND_STANDBY;
- #endif
- constchar*const*s;
- #endif
- char*p;
- intlen;
- interror=-EINVAL;
- p=memchr(buf,'\n',n);
- len=p?p-buf:n;
- /*First,checkifwearerequestedtohibernate*/
- if(len==4&&!strncmp(buf,"disk",len)){
- error=hibernate();
- gotoExit;
- }
- #ifdefCONFIG_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)
- #ifdefCONFIG_EARLYSUSPEND
- if(state==PM_SUSPEND_ON||valid_state(state)){
- error=0;
- request_suspend_state(state);
- }
- #else
- error=enter_state(state);
- #endif
- #endif
- Exit:
- returnerror?error:n;
- }
看到了没,前一篇文章说过,suspend to disk做了特殊处理,这里直接比较传入的字符串,而不是使用后续的pm_states数组,这里我不关心suspend to disk,所以略过hibernate的分析。紧接着,通过pm_states数组,根据命令字符串查询得到请求的状态,默认情况下,Android的内核都会配置了CONFIG_EARLYSUSPEND,所以会调用request_suspend_state()函数,不过在调用该函数之前会先valid_state()一下,这给了平台相关的代码一个机会确认该平台是否支持所请求的电源状态。valid_state()的具体实现请参考内核代码树。
[cpp] view plain copy
- voidrequest_suspend_state(suspend_state_tnew_state)
- {
- unsignedlongirqflags;
- intold_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_workisinqueuealready\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_workisinqueuealready\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;
unsigned long irqflags;
int abort = 0;
mutex_lock(&early_suspend_lock);
spin_lock_irqsave(&state_lock,irqflags);
if (state == SUSPEND_REQUESTED)
state |= SUSPENDED;
else
abort = 1;
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的流程完成。下面的序列图清晰地表明了整个调用的过程:
图3.1 early suspend调用流程
但是,这时整个系统只是处于所谓的idle状态,cpu还在工作,后台进程也在工作中,那什么时候系统会真正地进入睡眠状态?注意到最后一句关键的调用了没有:
wake_unlock(&main_wake_lock);
解锁动作会触发标准linux的suspend流程,这个过程就留给写一篇文章讨论吧
更多相关文章
- Android 沉浸式状态栏完美解决方案
- Android中Adapter中edittext,checkbox记住状态解决方案
- 在Ubuntu上为Android增加硬件抽象层(HAL)模块访问Linux内核驱动程
- [转]android的Goldfish内核概述
- Android获取WIFI状态下的IP地址以及MAC地址
- Android网络状态监听
- Android 判断程序前后台状态