业务请联系elautoctrl@qq.com 1. Based on linux 2.6.32 and android 2.2,only support SDR(mem). 2. 参考文章: http://2695477.blog.51cto.com/blog/2685477/484751 http://www.docin.com/p-115475680.html http://blogold./u3/113927/showart_2447111.html http://www./html/201003/1269407632ID2530.html
一、新增特性介绍
实际上,android仍然是利用了标准linux的休眠唤醒系统,只不过添加了一些使用上的新特性,early suspend、late resume、wake lock。
Early suspend - 这个机制定义了在suspend的早期,关闭显示屏的时候,一些和显示屏相关的设备,比如背光、重力感应器和触摸屏等设备都应该被关掉,但是此时系统可能还有持有wake lock的任务在运行,如音乐播放,电话,或者扫描sd卡上的文件等,这个时候整个系统还不能进入真正睡眠,直到所有的wake lock都没释放。在嵌入式设备中,悲观是一个很大的电源消耗,所有android加入了这种机制。
Late resume - 这个机制定义了在resume的后期,也就是唤醒源已经将处理器唤醒,标准linux的唤醒流程已经走完了,在android上层系统识别出这个物理上的唤醒源是上层定义的,那么上层将会发出late resume的命令给下层,这个时候将会调用相关设备注册的late resume回调函数。
Wake lock - wakelock在android的电源管理系统中扮演一个核心的角色,wakelock是一种锁的机制,只要有task拿着这个锁, 系统就无法进入休眠, 可以被用户态进程和内核线程获得。这个锁可以是有超时的或者是没有超时的, 超时的锁会在时间过去以后自动解锁。如果没有锁了或者超时了, 内核就会启动标准linux的那套休眠机制机制来进入休眠。
二、kernel层源码解析 - early suspend 和 late resume实现 相关源码: kernel/kernel/power/main.c kernel/kernel/power/earlysuspend.c kernel/kernel/power/wakelock.c kernel/kernel/power/userwakelock.c kernel/kernel/power/suspend.c
之前标准的linux的sysfs的接口只需要一个state就够了,现在至少需要3个接口文件:state、wake_lock、wake_unlock。现在为了配合android为休眠唤醒添加的几种新特性,可以填入文件state的模式又多了一种:on, 标准android系统中只支持state的on和mem模式,其余的暂不支持。wake_lock和wake_unlock接口对应的读写函数在文件userwakelock.c中,对wakelock.c中的create wakelock或者release wakelock进行了封装,供用户空间来使用。
如果上层用户执行:echo xxx(on or mem) > sys/power/state的话,将会调用到如下函数: static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr, const char *buf, size_t n) { #ifdef CONFIG_SUSPEND // set #ifdef CONFIG_EARLYSUSPEND //set suspend_state_t state = PM_SUSPEND_ON; // for early suspend and late resume #else suspend_state_t state = PM_SUSPEND_STANDBY; #endif const char * 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 */ if (len == 4 && !strncmp(buf, “disk”, len)) { error = hibernate(); // 检查是否要求进入disk省电模式,暂时不支持 goto Exit; }
#ifdef CONFIG_SUSPEND // def 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)) { // 需要经过平台pm.c文件定义的模式支持检查函数,mtk只支持mem,同时如果是android发送出来的late resume命令(on),这里也会放行,往下执行 error = 0; request_suspend_state(state); // android休眠唤醒的路线 } #else error = enter_state(state);// 标准linux休眠唤醒的路线 #endif #endif
Exit: return error ? error : n; }
@ kernel/kernel/power/earlysuspend.c enum { DEBUG_USER_STATE = 1U << 0, DEBUG_SUSPEND = 1U << 2, }; int Earlysuspend_debug_mask = DEBUG_USER_STATE; module_param_named(Earlysuspend_debug_mask, Earlysuspend_debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
static DEFINE_MUTEX(early_suspend_lock); static LIST_HEAD(early_suspend_handlers); static void early_sys_sync(struct work_struct *work); static void early_suspend(struct work_struct *work); static void late_resume(struct work_struct *work); static DECLARE_WORK(early_sys_sync_work, early_sys_sync); static DECLARE_WORK(early_suspend_work, early_suspend); static DECLARE_WORK(late_resume_work, late_resume); static DEFINE_SPINLOCK(state_lock); enum { SUSPEND_REQUESTED = 0×1, SUSPENDED = 0×2, SUSPEND_REQUESTED_AND_SUSPENDED = SUSPEND_REQUESTED | SUSPENDED, }; static int state; // 初始化为0
static DECLARE_COMPLETION(fb_drv_ready);
void request_suspend_state(suspend_state_t new_state) { unsigned long irqflags; int old_sleep;
spin_lock_irqsave(&state_lock, irqflags); old_sleep = state & SUSPEND_REQUESTED; // state = 1 or 3 // state的值会在0->1->3->2->0循环变化,后面分析代码都可以看出这些值代表系统目前处于什么阶段,简单得说就是:正常->准备进early suspend->开始early suspend并且对名为mian的wakelock解锁,如果此时没有其余wakelock处于lock状态,那么系统就走linux的休眠唤醒路线让整个系统真正休眠,直到唤醒源发生,然后将处理器和linux层唤醒。之后android层判断本次底层醒来是由于我所定义的唤醒源引起的吗?如果不是,android将不予理会,过段时间没有wakelock锁,系统会再次走linux的休眠路线进入休眠。如果是,那么android上层就会写一个on的指令到state接口中,同样是会调用到函数request_suspend_state() -> 准备执行late resume ->开始执行late resume,之后整个系统就这样被唤醒了。 if (Earlysuspend_debug_mask & DEBUG_USER_STATE) { struct timespec ts; // 打印出debug信息 struct rtc_time tm; getnstimeofday(&ts); rtc_time_to_tm(ts.tv_sec, &tm); pr_info(“[request_suspend_state]: %s (%d->%d) at %lld ” “(%d-%02d-%02d %02d:%02d:%02d.%09lu UTC)/n”, new_state != PM_SUSPEND_ON ? “sleep” : “wakeup”, requested_suspend_state, new_state, ktime_to_ns(ktime_get()), tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); } // eg: [request_suspend_state]: sleep (0->3) at 97985478409 (2010-01-03 09:52:59.637902305 UTC), 这里对时间的获取和处理,在其他地方可以参考 // ready to enter earlysuspend if (!old_sleep && new_state != PM_SUSPEND_ON) { // susepnd会进入这里 state |= SUSPEND_REQUESTED; // state = 1 pr_info(“[request_suspend_state]: sys_sync_work_queue early_sys_sync_work/n”); queue_work(sys_sync_work_queue, &early_sys_sync_work); pr_info(“[request_suspend_state]: suspend_work_queue early_suspend_work/n”); queue_work(suspend_work_queue, &early_suspend_work); // 在wakelocks_init()函数(wakelock.c)中会创建这两个工作队列和工作者线程来专门负责处理sys_sync和early suspend的工作。关于工作队列的详情参考我工作队列的文章 } // ready to enter lateresume else if (old_sleep && new_state == PM_SUSPEND_ON) { state &= ~SUSPEND_REQUESTED; // state = 2 wake_lock(&main_wake_lock); // 对main wakelock上锁 pr_info(“[request_suspend_state]: suspend_work_queue late_resume_work/n” ); if (queue_work(suspend_work_queue, &late_resume_work)) { // 提交late resume的工作项 // // In order to synchronize the backlight turn on timing, // block the thread and wait for fb driver late_resume() // callback function is completed // wait_for_completion(&fb_drv_ready); // 等待完成量fb_drv_ready,他会在late resume结束之后完成 } } requested_suspend_state = new_state; // 存储本次休眠或者是唤醒的状态,供下次休眠或者唤醒使用 spin_unlock_irqrestore(&state_lock, irqflags); }
在系统suspend的时候提交的两个工作项会陆续被执行到,那么下面就来看一下执行early suspend的关键函数。 static void early_sys_sync(struct work_struct *work) { wake_lock(&sys_sync_wake_lock); printk(“[sys_sync work] start/n”); sys_sync(); // 同步文件系统 printk(“[sys_sync wrok] done/n”); wake_unlock(&sys_sync_wake_lock); }
static void 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; // state = 3 else abort = 1; spin_unlock_irqrestore(&state_lock, irqflags);
if (abort) { // suspend 中止退出 if (Earlysuspend_debug_mask & DEBUG_SUSPEND) pr_info(“[early_suspend]: abort, state %d/n”, state); mutex_unlock(&early_suspend_lock); goto abort; }
if (Earlysuspend_debug_mask & DEBUG_SUSPEND) pr_info(“[early_suspend]: call handlers/n”); list_for_each_entry(pos, &early_suspend_handlers, link) { if (pos->suspend != NULL) pos->suspend(pos); } // 函数register_early_suspend()会将每一个early suspend项以优先级大小注册到链表early_suspend_handlers中,这里就是一次取出,然后执行对应的early suspend回调函数 mutex_unlock(&early_suspend_lock);
// Remove sys_sync from early_suspend, // and use work queue to complete sys_sync
abort: spin_lock_irqsave(&state_lock, irqflags); if (state == SUSPEND_REQUESTED_AND_SUSPENDED) { pr_info(“[early_suspend]: wake_unlock(main)/n”); wake_unlock(&main_wake_lock); // main wakelock 解锁。看到这里,好像系统执行了early suspend之后就没有往下执行标准linux的suspend流程了,其实不是,android的做法是,不是你执行完了early suspend 的回调就可以马上走标准linux的suspend流程,而是会检查还有没有wakelock被持有,如果所有wakelock全是解锁状态,那么就会执行标准linux的suspend步骤。 } spin_unlock_irqrestore(&state_lock, irqflags); }
static void late_resume(struct work_struct *work) { struct early_suspend *pos; unsigned long irqflags; int abort = 0; int completed = 0;
mutex_lock(&early_suspend_lock); spin_lock_irqsave(&state_lock, irqflags);
// return back from suspend if (state == SUSPENDED) state &= ~SUSPENDED; // state = 0 else abort = 1; spin_unlock_irqrestore(&state_lock, irqflags);
if (abort) { if (Earlysuspend_debug_mask & DEBUG_SUSPEND) pr_info(“[late_resume]: abort, state %d/n”, state); goto abort; } if (Earlysuspend_debug_mask & DEBUG_SUSPEND) pr_info(“[late_resume]: call handlers/n”); list_for_each_entry_reverse(pos, &early_suspend_handlers, link) { if (!completed && pos->level < EARLY_SUSPEND_LEVEL_DISABLE_FB) { complete(&fb_drv_ready); completed = 1; } if (pos->resume != NULL) pos->resume(pos); } // 以和early suspend的逆序执行链表early_suspend_handlers上的late resume回调函数 if (Earlysuspend_debug_mask & DEBUG_SUSPEND) pr_info(“[late_resume]: done/n”); abort: if (!completed) complete(&fb_drv_ready); // 设置完成量ok mutex_unlock(&early_suspend_lock); } 三、kernel层源码解析 - wakelock的重要地位 wakelock在android的休眠唤醒机制中扮演着及其重要的角色,主要源码位于文件:kernel/kernel/power/wakelock.c,kernel/include/linux/wakelock.h中。
wakelocks_init()函数所做的工作是整个wakelock可以工作起来的基础,所有这里先说说这个函数。 static int __init wakelocks_init(void) { int ret; int i;
for (i = 0; i < ARRAY_SIZE(active_wake_locks); i++) INIT_LIST_HEAD(&active_wake_locks[i]); // 初始化active_wake_locks数组中的两个类型锁链表: WAKE_LOCK_SUSPEND,WAKE_LOCK_IDLE
#ifdef CONFIG_WAKELOCK_STAT // defined wake_lock_init(&deleted_wake_locks, WAKE_LOCK_SUSPEND, “deleted_wake_locks”); // 初始化wakelock deleted_wake_locks,同时将其加入到非活动锁链表中 #endif wake_lock_init(&main_wake_lock, WAKE_LOCK_SUSPEND, “main”); wake_lock_init(&sys_sync_wake_lock, WAKE_LOCK_SUSPEND, “sys_sync”); wake_lock(&main_wake_lock); wake_lock_init(&unknown_wakeup, WAKE_LOCK_SUSPEND, “unknown_wakeups”); // 初始化wakelock: main, sys_sync, unknown_wakeups, 同时将其加入到非活动锁链表中 // 给 main_wake_lock 加锁 ret = platform_device_register(&power_device); if (ret) { pr_err(“[wakelocks_init]: platform_device_register failed/n”); goto err_platform_device_register; } ret = platform_driver_register(&power_driver); if (ret) { pr_err(“[wakelocks_init]: platform_driver_register failed/n”); goto err_platform_driver_register; }
// 新建工作队列和工作者内核线程: sys_sync_work_queue, fs_sync // suspend_work_queue, suspend sys_sync_work_queue = create_singlethread_workqueue(“fs_sync”); if (sys_sync_work_queue == NULL) { pr_err(“[wakelocks_init] fs_sync workqueue create failed/n”); }
suspend_work_queue = create_singlethread_workqueue(“suspend”); if (suspend_work_queue == NULL) { ret = -ENOMEM; goto err_suspend_work_queue; }
#ifdef CONFIG_WAKELOCK_STAT proc_create(“wakelocks”, S_IRUGO, NULL, &wakelock_stats_fops); // 创建proc接口 #endif
return 0;
err_suspend_work_queue: platform_driver_unregister(&power_driver); err_platform_driver_register: platform_device_unregister(&power_device); err_platform_device_register: wake_lock_destroy(&unknown_wakeup); wake_lock_destroy(&main_wake_lock); #ifdef CONFIG_WAKELOCK_STAT wake_lock_destroy(&deleted_wake_locks); #endif return ret; }
可以看到该初始化函数中新建了几个wakelock: deleted_wake_locks、main_wake_lock、sys_sync_wake_lock、unknown_wakeup,他们全部都是WAKE_LOCK_SUSPEND类型的wakelock,说到这里不得不提到wakelock的两种类型了: 1. WAKE_LOCK_SUSPEND – 这种锁如果被某个task持有,那么系统将无法进入休眠。 2. WAKE_LOCK_IDLE – 这种锁不会影响到系统进入休眠,但是如果这种锁被持有,那么系统将无法进入idle空闲模式。
不过常用的所类型还是WAKE_LOCK_SUSPEND,包括userwakelock.c提供给用户空间的新建wakelock的接口,都是建立的第一种锁。另外系统为了分开管理这两种不同类型的锁,建立了两个链表来统一链接不同类型的锁:active_wake_locks[],这个是具有两个链表头的数组,元素0是挂接WAKE_LOCK_SUSPEND类型的锁,而元素1就是挂接WAKE_LOCK_IDLE类型的wakelock了。
接着上面说,这个初始化函数新建这些锁之后,直接将主锁(main_wake_lock)给上锁了,其余都是非锁状态。新建wakelock使用函数wake_lock_init(),该函数设置锁的名字,类型,最后将新建的锁挂接到一个专门链接这些非锁状态的链表inactive_locks上(新建的wakelock初期都是出于非锁状态的,除非显示调用函数wake_lock来上锁)。接着如果使用函数wake_lock()来给特定的wakelock上锁的话,会将该锁从链表inactive_locks上移动到对应类型的专用链表上active_wake_locks[type]上。 wakelock有两种形式的锁:超时锁和非超时锁,这两种形式的锁都是使用函数wake_lock_init()来初始化,只是在上锁的时候会有一点点差别,超时锁使用函数wake_lock_timeout(),而非超时锁使用函数wake_lock(), 这个两个函数会最终调用到同一个函数wake_lock_internal(),该函数依靠传入的不同参数来选择不同的路径来工作。值得注意的是,非超时锁必须手工解锁,否则系统永远不能进入睡眠。下面是wake_lock_internal()函数的片段: if (!(lock->flags & WAKE_LOCK_ACTIVE)) lock->flags |= WAKE_LOCK_ACTIVE;// wakelock状态为inactive,则更改为active … if (has_timeout) { // wake_lock_timeout()会传入1 if (wakelock_debug_mask & DEBUG_WAKE_LOCK) pr_info(“[wake_lock_internal]: %s, type %d, timeout %ld.%03lu/n”, lock->name, type, timeout / HZ, (timeout % HZ) * MSEC_PER_SEC / HZ); lock->expires = jiffies + timeout; // 设置超时时间 lock->flags |= WAKE_LOCK_AUTO_EXPIRE; // 超时锁标志 list_add_tail(&lock->link, &active_wake_locks[type]); } // acquire a non-timeout wakelock 添加一个非超时锁 else { // wake_lock ()会传入0 if (wakelock_debug_mask & DEBUG_WAKE_LOCK) pr_info(“[wake_lock_internal]: %s, type %d/n”, lock->name, type); lock->expires = LONG_MAX; // 设置成超时时间最大值 lock->flags &= ~WAKE_LOCK_AUTO_EXPIRE; // 非超时锁标志 list_add(&lock->link, &active_wake_locks[type]); // 将刚刚设置的非超时锁加到对应类型的活动锁链表中 } 解锁的时候,这两种形式的锁所使用函数都是一样了:wake_unlock(),该函数中会首先作如下操作: lock->flags &= ~(WAKE_LOCK_ACTIVE | WAKE_LOCK_AUTO_EXPIRE); // 清除锁活动标志和自动超时标志 list_del(&lock->link); // 从锁对应的活动链表上摘除 list_add(&lock->link, &inactive_locks); // 将unlock的锁挂接到非活动链表inactive_locks上
前面已经说了只有类型为WAKE_LOCK_SUSPEND的wakelock被上锁才会阻止系统进入suspend,那么也就是说只要链表active_wake_locks[WAKE_LOCK_SUSPEND]为NULL,那么系统就可以执行suspend的流程了。Android对linux的改造,让其可以在三种情况下进入linux的标准suspend的流程: 1. wake_unlock(),这个应该是最容易想到的,只要系统有对WAKE_LOCK_SUSPEND类型的wakelock解锁的动作,都有可能会进入suspend流程开始休眠,为什么是有可能呢?因为可能还有超时锁没有被超时解锁。下面看一下代码片段: void wake_unlock(struct wake_lock *lock) { … if (type == WAKE_LOCK_SUSPEND) // 貌似只在处理这个类型的wakelock { long has_lock = has_wake_lock_locked(type); // 这个函数蛮重要,它来检查type类型的链表上是否还有锁被上锁了。 // 其返回值如果是0,说明没有该类型的锁被持有了;返回非0表明就是这个类型的活动链表上还存在超时锁但是没有非超时锁了,这个返回值就是当前时间距离最后超时的锁超时时间的jiffies值;如果返回-1,那表明还有该类型的非超时锁被持有。 if (wakelock_debug_mask & DEBUG_WAKE_LOCK) pr_info(“[wake_unlock]: has_lock = 0x%x/n” , has_lock); if (has_lock > 0) { if (wakelock_debug_mask & DEBUG_EXPIRE) pr_info(“[wake_unlock]: %s, start expire timer, ” “%ld/n”, lock->name, has_lock); mod_timer(&expire_timer, jiffies + has_lock); // 修改定时器的超时值并add该定时器 } else // 已经没有超时锁了 { if (del_timer(&expire_timer)) // 删除定时器 if (wakelock_debug_mask & DEBUG_EXPIRE) pr_info(“[wake_unlock]: %s, stop expire ” “timer/n”, lock->name); if (has_lock == 0) // !=0,表明还有该类型的非超时锁被持有,现在还不能进入suspend { pr_info(“[wake_unlock]: (%s) suspend_work_queue suspend_work/n” , lock->name); queue_work(suspend_work_queue, &suspend_work); // 提交suspend的工作项,开始执行标准linux的suspend流程 } } … } spin_unlock_irqrestore(&list_lock, irqflags); }
2. 超时锁超时之后,定时器的回调函数会执行会查看是否有其他的wakelock, 如果没有,就在这里让系统进入睡眠。 static void expire_wake_locks(unsigned long data) { long has_lock; unsigned long irqflags; if (debug_mask & DEBUG_EXPIRE) pr_info(“expire_wake_locks: start/n”); spin_lock_irqsave(&list_lock, irqflags); if (debug_mask & DEBUG_SUSPEND) print_active_locks(WAKE_LOCK_SUSPEND); has_lock = has_wake_lock_locked(WAKE_LOCK_SUSPEND); if (debug_mask & DEBUG_EXPIRE) pr_info(“expire_wake_locks: done, has_lock %ld/n”, has_lock); if (has_lock == 0) // 如果没有SUSPEND类型的wakelock处于active,那么将调用suspend queue_work(suspend_work_queue, &suspend_work); spin_unlock_irqrestore(&list_lock, irqflags); } static DEFINE_TIMER(expire_timer, expire_wake_locks, 0, 0); 列出以下一个重要的函数源码: static long has_wake_lock_locked(int type) { struct wake_lock *lock, *n; long max_timeout = 0;
BUG_ON(type >= WAKE_LOCK_TYPE_COUNT); list_for_each_entry_safe(lock, n, &active_wake_locks[type], link) { if (lock->flags & WAKE_LOCK_AUTO_EXPIRE) { long timeout = lock->expires – jiffies; if (timeout <= 0) expire_wake_lock(lock); else if (timeout > max_timeout) max_timeout = timeout; } else return -1; } return max_timeout; }
3. 这个可能有人觉得匪夷所思,就是在wake_lock{_ _timeout}()函数中,调用了内部函数wake_lock_internal()。这里只有在对超时锁上锁的时候才有可能进入休眠,如果对一个费超时锁上锁的话,那么就没有必要去检查活动链表了。 static void wake_lock_internal( struct wake_lock *lock, long timeout, int has_timeout) { … if (type == WAKE_LOCK_SUSPEND) { current_event_num++; #ifdef CONFIG_WAKELOCK_STAT if (lock == &main_wake_lock) update_sleep_wait_stats_locked(1); else if (!wake_lock_active(&main_wake_lock)) update_sleep_wait_stats_locked(0); #endif if (has_timeout) // 超时锁的时候传进来的是1 expire_in = has_wake_lock_locked(type); // 检查当前锁类型链表上是否还有锁处于active的状态,无返回0 else expire_in = -1; // 如果是非超时锁的话,这里直接赋值-1,省去了活动链表检查步骤了 if (expire_in > 0) { if (debug_mask & DEBUG_EXPIRE) pr_info(“wake_lock: %s, start expire timer, ” “%ld/n”, lock->name, expire_in); // modify the time wakelock is expired mod_timer(&expire_timer, jiffies + expire_in); } else { if (del_timer(&expire_timer)) if (debug_mask & DEBUG_EXPIRE) pr_info(“wake_lock: %s, stop expire timer/n”, lock->name); if (expire_in == 0) // 没有锁处于active状态后,准备调用suspend了 { pr_info(“[wake_lock]: suspend_work_queue suspend_work/n “); queue_work(suspend_work_queue, &suspend_work); } } } spin_unlock_irqrestore(&list_lock, irqflags); }
下面是suspend的工作项,经过上面三种情况的检查,ok之后将会提交该工作项给工作队列suspend_work_queue,如下: static void suspend(struct work_struct *work) { int ret; int entry_event_num;
// there are still some wakelock if (has_wake_lock(WAKE_LOCK_SUSPEND)) { if (wakelock_debug_mask & DEBUG_SUSPEND) pr_info(“[suspend]: abort suspend/n”); return; }
entry_event_num = current_event_num; sys_sync(); if (debug_mask & DEBUG_SUSPEND) pr_info(“suspend: enter suspend/n”); ret = pm_suspend(requested_suspend_state); // requested_suspend_state这个全局变量在函数request_suspend_state()中被设置,也就是执行了eraly suspend或者late resume之后,主要是为suspend保留请求的省电状态。 if (debug_mask & DEBUG_EXIT_SUSPEND) { struct timespec ts; struct rtc_time tm; getnstimeofday(&ts); rtc_time_to_tm(ts.tv_sec, &tm); pr_info(“suspend: exit suspend, ret = %d ” “(%d-%02d-%02d %02d:%02d:%02d.%09lu UTC)/n”, ret, tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); } if (current_event_num == entry_event_num) { if (debug_mask & DEBUG_SUSPEND) pr_info(“suspend: pm_suspend returned with no event/n”); wake_lock_timeout(&unknown_wakeup, HZ / 2); } } static DECLARE_WORK(suspend_work, suspend);
@kernel/kernel/power/suspend.c int pm_suspend(suspend_state_t state) { if (state > PM_SUSPEND_ON && state <= PM_SUSPEND_MAX) return enter_state(state); // 标准linux的suspend流程函数 return -EINVAL; } EXPORT_SYMBOL(pm_suspend);
Wakelock的机制被文件userwakelock.c中的code封装成了sys的接口sys/power/wake_lock和sys/power/wake_unlock文件,那么上层如果需要新建wakelock或者注销wakelock,或者是解锁wakelock,都是操作这两个sys接口文件。 四、android层源码解析 在linux之上经过android的软件堆层层封装,最终在上层的java应用程序中使用。休眠唤醒也是从最上层发出的命令,然后一层一层地将参数解析,往最底层传,最后走上标准linux的休眠唤醒之路。 这一部分将会初略分析休眠唤醒机制上linux之上所走的路线。 在linux之上,存在一个hal层,专门做和linux内核设备打交道的事情,这里也不例外。休眠唤醒机制的hal层源码位于:@hardware/libhardware_legacy/power/power.c 该文件源码比较简单,下面列举重点片段: enum { ACQUIRE_PARTIAL_WAKE_LOCK = 0, RELEASE_WAKE_LOCK, REQUEST_STATE, OUR_FD_COUNT }; const char * const NEW_PATHS[] = { “/sys/power/wake_lock”, “/sys/power/wake_unlock”, “/sys/power/state” }; static int g_initialized = 0; static int g_fds[OUR_FD_COUNT]; static const char *off_state = “mem”; static const char *on_state = “on”;
static int open_file_descriptors(const char * const paths[]) { int i; for (i=0; i<OUR_FD_COUNT; i++) { int fd = open(paths[i], O_RDWR); if (fd < 0) { fprintf(stderr, “fatal error opening /”%s/”/n”, paths[i]); g_error = errno; return -1; } g_fds[i] = fd; }
g_error = 0; return 0; }
static inline void initialize_fds(void) { if (g_initialized == 0) { if(open_file_descriptors(NEW_PATHS) < 0) { open_file_descriptors(OLD_PATHS); on_state = “wake”; off_state = “standby”; } g_initialized = 1; } }
int acquire_wake_lock(int lock, const char* id) { initialize_fds(); if (g_error) return g_error; int fd;
if (lock == PARTIAL_WAKE_LOCK) { // 上层传下来的lock type fd = g_fds[ACQUIRE_PARTIAL_WAKE_LOCK]; } else { return EINVAL; }
return write(fd, id, strlen(id)); }
int release_wake_lock(const char* id) { initialize_fds();
// LOGI(“release_wake_lock id=’%s’/n”, id);
if (g_error) return g_error;
ssize_t len = write(g_fds[RELEASE_WAKE_LOCK], id, strlen(id)); return len >= 0; }
int set_screen_state(int on) { QEMU_FALLBACK(set_screen_state(on)); LOGI(“*** set_screen_state %d”, on);
initialize_fds(); if (g_error) return g_error;
char buf[32]; int len; if(on) len = sprintf(buf, on_state); else len = sprintf(buf, off_state); len = write(g_fds[REQUEST_STATE], buf, len); if(len < 0) { LOGE(“Failed setting last user activity: g_error=%d/n”, g_error); } return 0; }
Hal层的代码在jni层中被使用,源码位于:frameworks/base/core/jni/android_os_Power.cpp,代码片段如下: static void acquireWakeLock(JNIEnv *env, jobject clazz, jint lock, jstring idObj) { if (idObj == NULL) { throw_NullPointerException(env, “id is null”); return ; }
const char *id = env->GetStringUTFChars(idObj, NULL);
acquire_wake_lock(lock, id);
env->ReleaseStringUTFChars(idObj, id); }// 对wakelock加锁函数 static void releaseWakeLock(JNIEnv *env, jobject clazz, jstring idObj) { if (idObj == NULL) { throw_NullPointerException(env, “id is null”); return ; }
const char *id = env->GetStringUTFChars(idObj, NULL);
release_wake_lock(id);
env->ReleaseStringUTFChars(idObj, id);
}// 对wakelock解锁函数 static int setScreenState(JNIEnv *env, jobject clazz, jboolean on) { return set_screen_state(on); }// 休眠唤醒的函数
Jni的方法需要注册到上层才可以使用,同时也需要在上层的对应java类中声明了native才可以使用。那么这里的方法在java中对应的声明在哪里呢?frameworks/base/core/java/android/os/Power.java,该文件定义一个java类,如下: public class Power { // can’t instantiate this class private Power() { } /** * Wake lock that ensures that the CPU is running. The screen might * not be on. */ public static final int PARTIAL_WAKE_LOCK = 1; /** * Wake lock that ensures that the screen is on. */ public static final int FULL_WAKE_LOCK = 2; public static native void acquireWakeLock(int lock, String id); public static native void releaseWakeLock(String id); … /** * Turn the screen on or off * * @param on Whether you want the screen on or off */ public static native int setScreenState(boolean on); … } 声明的jni接口应该是被java server在使用,这里就是专门的电源管理服务:PowerManagerService使用,具体源码位置在:frameworks/base/services/java/com/android/server/PowerManagerService.java。android在最上层还提供了现场的android.os.PowerManager类 (frameworks/base/core/java/android/os/PowerManager.java)来供app使用,PowerManager类会调用java服务PowerManagerService的方法来完成与wakelock相关的工作。 @ frameworks/base/core/java/android/os/PowerManager.java 类PowerManager中内嵌了一个WakeLock类,另外还定义了wakelock的类型,下面是代码片段: public class PowerManager { private static final String TAG = “PowerManager”; … /** * Wake lock that ensures that the CPU is running. The screen might * not be on. */ public static final int PARTIAL_WAKE_LOCK = WAKE_BIT_CPU_STRONG;
/** * Wake lock that ensures that the screen and keyboard are on at * full brightness. */ public static final int FULL_WAKE_LOCK = WAKE_BIT_CPU_WEAK | WAKE_BIT_SCREEN_BRIGHT | WAKE_BIT_KEYBOARD_BRIGHT; /** * Wake lock that ensures that the screen is on at full brightness; * the keyboard backlight will be allowed to go off. */ public static final int SCREEN_BRIGHT_WAKE_LOCK = WAKE_BIT_CPU_WEAK | WAKE_BIT_SCREEN_BRIGHT;
/** * Wake lock that ensures that the screen is on (but may be dimmed); * the keyboard backlight will be allowed to go off. */ public static final int SCREEN_DIM_WAKE_LOCK = WAKE_BIT_CPU_WEAK | WAKE_BIT_SCREEN_DIM;
/** * Wake lock that turns the screen off when the proximity sensor activates. * Since not all devices have proximity sensors, use * {@link #getSupportedWakeLockFlags() getSupportedWakeLockFlags()} to determine if * this wake lock mode is supported. * * {@hide} */ public static final int PROXIMITY_SCREEN_OFF_WAKE_LOCK = WAKE_BIT_PROXIMITY_SCREEN_OFF; … public class WakeLock { … WakeLock(int flags, String tag) { switch (flags & LOCK_MASK) { case PARTIAL_WAKE_LOCK: case SCREEN_DIM_WAKE_LOCK: case SCREEN_BRIGHT_WAKE_LOCK: case FULL_WAKE_LOCK: case PROXIMITY_SCREEN_OFF_WAKE_LOCK: break; default: throw new IllegalArgumentException(); }
mFlags = flags; mTag = tag; mToken = new Binder(); } public void acquire() { synchronized (mToken) { if (!mRefCounted || mCount++ == 0) { try { mService.acquireWakeLock(mFlags, mToken, mTag); } catch (RemoteException e) { } mHeld = true; } } } public void release(int flags) { synchronized (mToken) { if (!mRefCounted || –mCount == 0) { try { mService.releaseWakeLock(mToken, flags); } catch (RemoteException e) { } mHeld = false; } if (mCount < 0) { throw new RuntimeException(“WakeLock under-locked ” + mTag); } } } … } … public WakeLock newWakeLock(int flags, String tag) { if (tag == null) { throw new NullPointerException(“tag is null in PowerManager.newWakeLock”); } return new WakeLock(flags, tag); } public void goToSleep(long time) { try { mService.goToSleep(time); } catch (RemoteException e) { } } … public PowerManager(IPowerManager service, Handler handler) { mService = service; mHandler = handler; }
IPowerManager mService; Handler mHandler; } 应用实例: PowerManager pm = (PowerManager)getSystemService(Context.POWER_SERVICE); PowerManager.WakeLock wl = pm.newWakeLock(PowerManager.SCREEN_DIM_WAKE_LOCK, “Tag”); wl.acquire(); //申请锁这个里面会调用PowerManagerService里面acquireWakeLock() … wl.release(); //释放锁,显示的释放,如果申请的锁不在此释放系统就不会进入休眠。
接下来就会调用到java服务PowerManagerService中: public void acquireWakeLock(int flags, IBinder lock, String tag) { int uid = Binder.getCallingUid(); if (uid != Process.myUid()) { mContext.enforceCallingOrSelfPermission(android.Manifest.permission.WAKE_LOCK, null); } long ident = Binder.clearCallingIdentity(); try { synchronized (mLocks) { acquireWakeLockLocked(flags, lock, uid, tag); // 内部方法 } } finally { Binder.restoreCallingIdentity(ident); } }
acquireWakeLockLocked(flags, lock, uid, tag)会调用函数power类的方法: Power.acquireWakeLock(Power.PARTIAL_WAKE_LOCK,PARTIAL_NAME)。
public void releaseWakeLock(IBinder lock, int flags) { int uid = Binder.getCallingUid(); if (uid != Process.myUid()) { mContext.enforceCallingOrSelfPermission(android.Manifest.permission.WAKE_LOCK, null); }
synchronized (mLocks) { releaseWakeLockLocked(lock, flags, false); } } releaseWakeLockLocked(lock, flags, false)函数会调用power类的方法: Power.releaseWakeLock(PARTIAL_NAME);
上层休眠唤醒都是调用PowerManagerService类的方法: goToSleep() à goToSleepWithReason() à goToSleepLocked() à setPowerState() à setScreenStateLocked() à Power.setScreenState() à jni方法 Android层的代码分析得不是很详细,这里只关注框架和流程。下图是网上的一个框架,可以参考一下: 原创文章,转载请注明: 转载自elautoctrl 本文链接地址: Android在标准linux基础上对休眠唤醒的实现 业务请联系elautoctrl@qq.com 1. Based on linux 2.6.32 and android 2.2,only support SDR(mem). 2. 参考文章: http://2695477.blog.51cto.com/blog/2685477/484751 http://www.docin.com/p-115475680.html http://blogold./u3/113927/showart_2447111.html http://www./html/201003/1269407632ID2530.html
一、新增特性介绍
实际上,android仍然是利用了标准linux的休眠唤醒系统,只不过添加了一些使用上的新特性,early suspend、late resume、wake lock。
Early suspend - 这个机制定义了在suspend的早期,关闭显示屏的时候,一些和显示屏相关的设备,比如背光、重力感应器和触摸屏等设备都应该被关掉,但是此时系统可能还有持有wake lock的任务在运行,如音乐播放,电话,或者扫描sd卡上的文件等,这个时候整个系统还不能进入真正睡眠,直到所有的wake lock都没释放。在嵌入式设备中,悲观是一个很大的电源消耗,所有android加入了这种机制。
Late resume - 这个机制定义了在resume的后期,也就是唤醒源已经将处理器唤醒,标准linux的唤醒流程已经走完了,在android上层系统识别出这个物理上的唤醒源是上层定义的,那么上层将会发出late resume的命令给下层,这个时候将会调用相关设备注册的late resume回调函数。
Wake lock - wakelock在android的电源管理系统中扮演一个核心的角色,wakelock是一种锁的机制,只要有task拿着这个锁, 系统就无法进入休眠, 可以被用户态进程和内核线程获得。这个锁可以是有超时的或者是没有超时的, 超时的锁会在时间过去以后自动解锁。如果没有锁了或者超时了, 内核就会启动标准linux的那套休眠机制机制来进入休眠。
二、kernel层源码解析 - early suspend 和 late resume实现 相关源码: kernel/kernel/power/main.c kernel/kernel/power/earlysuspend.c kernel/kernel/power/wakelock.c kernel/kernel/power/userwakelock.c kernel/kernel/power/suspend.c
之前标准的linux的sysfs的接口只需要一个state就够了,现在至少需要3个接口文件:state、wake_lock、wake_unlock。现在为了配合android为休眠唤醒添加的几种新特性,可以填入文件state的模式又多了一种:on, 标准android系统中只支持state的on和mem模式,其余的暂不支持。wake_lock和wake_unlock接口对应的读写函数在文件userwakelock.c中,对wakelock.c中的create wakelock或者release wakelock进行了封装,供用户空间来使用。
如果上层用户执行:echo xxx(on or mem) > sys/power/state的话,将会调用到如下函数: static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr, const char *buf, size_t n) { #ifdef CONFIG_SUSPEND // set #ifdef CONFIG_EARLYSUSPEND //set suspend_state_t state = PM_SUSPEND_ON; // for early suspend and late resume #else suspend_state_t state = PM_SUSPEND_STANDBY; #endif const char * 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 */ if (len == 4 && !strncmp(buf, “disk”, len)) { error = hibernate(); // 检查是否要求进入disk省电模式,暂时不支持 goto Exit; }
#ifdef CONFIG_SUSPEND // def 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)) { // 需要经过平台pm.c文件定义的模式支持检查函数,mtk只支持mem,同时如果是android发送出来的late resume命令(on),这里也会放行,往下执行 error = 0; request_suspend_state(state); // android休眠唤醒的路线 } #else error = enter_state(state);// 标准linux休眠唤醒的路线 #endif #endif
Exit: return error ? error : n; }
@ kernel/kernel/power/earlysuspend.c enum { DEBUG_USER_STATE = 1U << 0, DEBUG_SUSPEND = 1U << 2, }; int Earlysuspend_debug_mask = DEBUG_USER_STATE; module_param_named(Earlysuspend_debug_mask, Earlysuspend_debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
static DEFINE_MUTEX(early_suspend_lock); static LIST_HEAD(early_suspend_handlers); static void early_sys_sync(struct work_struct *work); static void early_suspend(struct work_struct *work); static void late_resume(struct work_struct *work); static DECLARE_WORK(early_sys_sync_work, early_sys_sync); static DECLARE_WORK(early_suspend_work, early_suspend); static DECLARE_WORK(late_resume_work, late_resume); static DEFINE_SPINLOCK(state_lock); enum { SUSPEND_REQUESTED = 0×1, SUSPENDED = 0×2, SUSPEND_REQUESTED_AND_SUSPENDED = SUSPEND_REQUESTED | SUSPENDED, }; static int state; // 初始化为0
static DECLARE_COMPLETION(fb_drv_ready);
void request_suspend_state(suspend_state_t new_state) { unsigned long irqflags; int old_sleep;
spin_lock_irqsave(&state_lock, irqflags); old_sleep = state & SUSPEND_REQUESTED; // state = 1 or 3 // state的值会在0->1->3->2->0循环变化,后面分析代码都可以看出这些值代表系统目前处于什么阶段,简单得说就是:正常->准备进early suspend->开始early suspend并且对名为mian的wakelock解锁,如果此时没有其余wakelock处于lock状态,那么系统就走linux的休眠唤醒路线让整个系统真正休眠,直到唤醒源发生,然后将处理器和linux层唤醒。之后android层判断本次底层醒来是由于我所定义的唤醒源引起的吗?如果不是,android将不予理会,过段时间没有wakelock锁,系统会再次走linux的休眠路线进入休眠。如果是,那么android上层就会写一个on的指令到state接口中,同样是会调用到函数request_suspend_state() -> 准备执行late resume ->开始执行late resume,之后整个系统就这样被唤醒了。 if (Earlysuspend_debug_mask & DEBUG_USER_STATE) { struct timespec ts; // 打印出debug信息 struct rtc_time tm; getnstimeofday(&ts); rtc_time_to_tm(ts.tv_sec, &tm); pr_info(“[request_suspend_state]: %s (%d->%d) at %lld ” “(%d-%02d-%02d %02d:%02d:%02d.%09lu UTC)/n”, new_state != PM_SUSPEND_ON ? “sleep” : “wakeup”, requested_suspend_state, new_state, ktime_to_ns(ktime_get()), tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); } // eg: [request_suspend_state]: sleep (0->3) at 97985478409 (2010-01-03 09:52:59.637902305 UTC), 这里对时间的获取和处理,在其他地方可以参考 // ready to enter earlysuspend if (!old_sleep && new_state != PM_SUSPEND_ON) { // susepnd会进入这里 state |= SUSPEND_REQUESTED; // state = 1 pr_info(“[request_suspend_state]: sys_sync_work_queue early_sys_sync_work/n”); queue_work(sys_sync_work_queue, &early_sys_sync_work); pr_info(“[request_suspend_state]: suspend_work_queue early_suspend_work/n”); queue_work(suspend_work_queue, &early_suspend_work); // 在wakelocks_init()函数(wakelock.c)中会创建这两个工作队列和工作者线程来专门负责处理sys_sync和early suspend的工作。关于工作队列的详情参考我工作队列的文章 } // ready to enter lateresume else if (old_sleep && new_state == PM_SUSPEND_ON) { state &= ~SUSPEND_REQUESTED; // state = 2 wake_lock(&main_wake_lock); // 对main wakelock上锁 pr_info(“[request_suspend_state]: suspend_work_queue late_resume_work/n” ); if (queue_work(suspend_work_queue, &late_resume_work)) { // 提交late resume的工作项 // // In order to synchronize the backlight turn on timing, // block the thread and wait for fb driver late_resume() // callback function is completed // wait_for_completion(&fb_drv_ready); // 等待完成量fb_drv_ready,他会在late resume结束之后完成 } } requested_suspend_state = new_state; // 存储本次休眠或者是唤醒的状态,供下次休眠或者唤醒使用 spin_unlock_irqrestore(&state_lock, irqflags); }
在系统suspend的时候提交的两个工作项会陆续被执行到,那么下面就来看一下执行early suspend的关键函数。 static void early_sys_sync(struct work_struct *work) { wake_lock(&sys_sync_wake_lock); printk(“[sys_sync work] start/n”); sys_sync(); // 同步文件系统 printk(“[sys_sync wrok] done/n”); wake_unlock(&sys_sync_wake_lock); }
static void 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; // state = 3 else abort = 1; spin_unlock_irqrestore(&state_lock, irqflags);
if (abort) { // suspend 中止退出 if (Earlysuspend_debug_mask & DEBUG_SUSPEND) pr_info(“[early_suspend]: abort, state %d/n”, state); mutex_unlock(&early_suspend_lock); goto abort; }
if (Earlysuspend_debug_mask & DEBUG_SUSPEND) pr_info(“[early_suspend]: call handlers/n”); list_for_each_entry(pos, &early_suspend_handlers, link) { if (pos->suspend != NULL) pos->suspend(pos); } // 函数register_early_suspend()会将每一个early suspend项以优先级大小注册到链表early_suspend_handlers中,这里就是一次取出,然后执行对应的early suspend回调函数 mutex_unlock(&early_suspend_lock);
// Remove sys_sync from early_suspend, // and use work queue to complete sys_sync
abort: spin_lock_irqsave(&state_lock, irqflags); if (state == SUSPEND_REQUESTED_AND_SUSPENDED) { pr_info(“[early_suspend]: wake_unlock(main)/n”); wake_unlock(&main_wake_lock); // main wakelock 解锁。看到这里,好像系统执行了early suspend之后就没有往下执行标准linux的suspend流程了,其实不是,android的做法是,不是你执行完了early suspend 的回调就可以马上走标准linux的suspend流程,而是会检查还有没有wakelock被持有,如果所有wakelock全是解锁状态,那么就会执行标准linux的suspend步骤。 } spin_unlock_irqrestore(&state_lock, irqflags); }
static void late_resume(struct work_struct *work) { struct early_suspend *pos; unsigned long irqflags; int abort = 0; int completed = 0;
mutex_lock(&early_suspend_lock); spin_lock_irqsave(&state_lock, irqflags);
// return back from suspend if (state == SUSPENDED) state &= ~SUSPENDED; // state = 0 else abort = 1; spin_unlock_irqrestore(&state_lock, irqflags);
if (abort) { if (Earlysuspend_debug_mask & DEBUG_SUSPEND) pr_info(“[late_resume]: abort, state %d/n”, state); goto abort; } if (Earlysuspend_debug_mask & DEBUG_SUSPEND) pr_info(“[late_resume]: call handlers/n”); list_for_each_entry_reverse(pos, &early_suspend_handlers, link) { if (!completed && pos->level < EARLY_SUSPEND_LEVEL_DISABLE_FB) { complete(&fb_drv_ready); completed = 1; } if (pos->resume != NULL) pos->resume(pos); } // 以和early suspend的逆序执行链表early_suspend_handlers上的late resume回调函数 if (Earlysuspend_debug_mask & DEBUG_SUSPEND) pr_info(“[late_resume]: done/n”); abort: if (!completed) complete(&fb_drv_ready); // 设置完成量ok mutex_unlock(&early_suspend_lock); } 三、kernel层源码解析 - wakelock的重要地位 wakelock在android的休眠唤醒机制中扮演着及其重要的角色,主要源码位于文件:kernel/kernel/power/wakelock.c,kernel/include/linux/wakelock.h中。
wakelocks_init()函数所做的工作是整个wakelock可以工作起来的基础,所有这里先说说这个函数。 static int __init wakelocks_init(void) { int ret; int i;
for (i = 0; i < ARRAY_SIZE(active_wake_locks); i++) INIT_LIST_HEAD(&active_wake_locks[i]); // 初始化active_wake_locks数组中的两个类型锁链表: WAKE_LOCK_SUSPEND,WAKE_LOCK_IDLE
#ifdef CONFIG_WAKELOCK_STAT // defined wake_lock_init(&deleted_wake_locks, WAKE_LOCK_SUSPEND, “deleted_wake_locks”); // 初始化wakelock deleted_wake_locks,同时将其加入到非活动锁链表中 #endif wake_lock_init(&main_wake_lock, WAKE_LOCK_SUSPEND, “main”); wake_lock_init(&sys_sync_wake_lock, WAKE_LOCK_SUSPEND, “sys_sync”); wake_lock(&main_wake_lock); wake_lock_init(&unknown_wakeup, WAKE_LOCK_SUSPEND, “unknown_wakeups”); // 初始化wakelock: main, sys_sync, unknown_wakeups, 同时将其加入到非活动锁链表中 // 给 main_wake_lock 加锁 ret = platform_device_register(&power_device); if (ret) { pr_err(“[wakelocks_init]: platform_device_register failed/n”); goto err_platform_device_register; } ret = platform_driver_register(&power_driver); if (ret) { pr_err(“[wakelocks_init]: platform_driver_register failed/n”); goto err_platform_driver_register; }
// 新建工作队列和工作者内核线程: sys_sync_work_queue, fs_sync // suspend_work_queue, suspend sys_sync_work_queue = create_singlethread_workqueue(“fs_sync”); if (sys_sync_work_queue == NULL) { pr_err(“[wakelocks_init] fs_sync workqueue create failed/n”); }
suspend_work_queue = create_singlethread_workqueue(“suspend”); if (suspend_work_queue == NULL) { ret = -ENOMEM; goto err_suspend_work_queue; }
#ifdef CONFIG_WAKELOCK_STAT proc_create(“wakelocks”, S_IRUGO, NULL, &wakelock_stats_fops); // 创建proc接口 #endif
return 0;
err_suspend_work_queue: platform_driver_unregister(&power_driver); err_platform_driver_register: platform_device_unregister(&power_device); err_platform_device_register: wake_lock_destroy(&unknown_wakeup); wake_lock_destroy(&main_wake_lock); #ifdef CONFIG_WAKELOCK_STAT wake_lock_destroy(&deleted_wake_locks); #endif return ret; }
可以看到该初始化函数中新建了几个wakelock: deleted_wake_locks、main_wake_lock、sys_sync_wake_lock、unknown_wakeup,他们全部都是WAKE_LOCK_SUSPEND类型的wakelock,说到这里不得不提到wakelock的两种类型了: 1. WAKE_LOCK_SUSPEND – 这种锁如果被某个task持有,那么系统将无法进入休眠。 2. WAKE_LOCK_IDLE – 这种锁不会影响到系统进入休眠,但是如果这种锁被持有,那么系统将无法进入idle空闲模式。
不过常用的所类型还是WAKE_LOCK_SUSPEND,包括userwakelock.c提供给用户空间的新建wakelock的接口,都是建立的第一种锁。另外系统为了分开管理这两种不同类型的锁,建立了两个链表来统一链接不同类型的锁:active_wake_locks[],这个是具有两个链表头的数组,元素0是挂接WAKE_LOCK_SUSPEND类型的锁,而元素1就是挂接WAKE_LOCK_IDLE类型的wakelock了。
接着上面说,这个初始化函数新建这些锁之后,直接将主锁(main_wake_lock)给上锁了,其余都是非锁状态。新建wakelock使用函数wake_lock_init(),该函数设置锁的名字,类型,最后将新建的锁挂接到一个专门链接这些非锁状态的链表inactive_locks上(新建的wakelock初期都是出于非锁状态的,除非显示调用函数wake_lock来上锁)。接着如果使用函数wake_lock()来给特定的wakelock上锁的话,会将该锁从链表inactive_locks上移动到对应类型的专用链表上active_wake_locks[type]上。 wakelock有两种形式的锁:超时锁和非超时锁,这两种形式的锁都是使用函数wake_lock_init()来初始化,只是在上锁的时候会有一点点差别,超时锁使用函数wake_lock_timeout(),而非超时锁使用函数wake_lock(), 这个两个函数会最终调用到同一个函数wake_lock_internal(),该函数依靠传入的不同参数来选择不同的路径来工作。值得注意的是,非超时锁必须手工解锁,否则系统永远不能进入睡眠。下面是wake_lock_internal()函数的片段: if (!(lock->flags & WAKE_LOCK_ACTIVE)) lock->flags |= WAKE_LOCK_ACTIVE;// wakelock状态为inactive,则更改为active … if (has_timeout) { // wake_lock_timeout()会传入1 if (wakelock_debug_mask & DEBUG_WAKE_LOCK) pr_info(“[wake_lock_internal]: %s, type %d, timeout %ld.%03lu/n”, lock->name, type, timeout / HZ, (timeout % HZ) * MSEC_PER_SEC / HZ); lock->expires = jiffies + timeout; // 设置超时时间 lock->flags |= WAKE_LOCK_AUTO_EXPIRE; // 超时锁标志 list_add_tail(&lock->link, &active_wake_locks[type]); } // acquire a non-timeout wakelock 添加一个非超时锁 else { // wake_lock ()会传入0 if (wakelock_debug_mask & DEBUG_WAKE_LOCK) pr_info(“[wake_lock_internal]: %s, type %d/n”, lock->name, type); lock->expires = LONG_MAX; // 设置成超时时间最大值 lock->flags &= ~WAKE_LOCK_AUTO_EXPIRE; // 非超时锁标志 list_add(&lock->link, &active_wake_locks[type]); // 将刚刚设置的非超时锁加到对应类型的活动锁链表中 } 解锁的时候,这两种形式的锁所使用函数都是一样了:wake_unlock(),该函数中会首先作如下操作: lock->flags &= ~(WAKE_LOCK_ACTIVE | WAKE_LOCK_AUTO_EXPIRE); // 清除锁活动标志和自动超时标志 list_del(&lock->link); // 从锁对应的活动链表上摘除 list_add(&lock->link, &inactive_locks); // 将unlock的锁挂接到非活动链表inactive_locks上
前面已经说了只有类型为WAKE_LOCK_SUSPEND的wakelock被上锁才会阻止系统进入suspend,那么也就是说只要链表active_wake_locks[WAKE_LOCK_SUSPEND]为NULL,那么系统就可以执行suspend的流程了。Android对linux的改造,让其可以在三种情况下进入linux的标准suspend的流程: 1. wake_unlock(),这个应该是最容易想到的,只要系统有对WAKE_LOCK_SUSPEND类型的wakelock解锁的动作,都有可能会进入suspend流程开始休眠,为什么是有可能呢?因为可能还有超时锁没有被超时解锁。下面看一下代码片段: void wake_unlock(struct wake_lock *lock) { … if (type == WAKE_LOCK_SUSPEND) // 貌似只在处理这个类型的wakelock { long has_lock = has_wake_lock_locked(type); // 这个函数蛮重要,它来检查type类型的链表上是否还有锁被上锁了。 // 其返回值如果是0,说明没有该类型的锁被持有了;返回非0表明就是这个类型的活动链表上还存在超时锁但是没有非超时锁了,这个返回值就是当前时间距离最后超时的锁超时时间的jiffies值;如果返回-1,那表明还有该类型的非超时锁被持有。 if (wakelock_debug_mask & DEBUG_WAKE_LOCK) pr_info(“[wake_unlock]: has_lock = 0x%x/n” , has_lock); if (has_lock > 0) { if (wakelock_debug_mask & DEBUG_EXPIRE) pr_info(“[wake_unlock]: %s, start expire timer, ” “%ld/n”, lock->name, has_lock); mod_timer(&expire_timer, jiffies + has_lock); // 修改定时器的超时值并add该定时器 } else // 已经没有超时锁了 { if (del_timer(&expire_timer)) // 删除定时器 if (wakelock_debug_mask & DEBUG_EXPIRE) pr_info(“[wake_unlock]: %s, stop expire ” “timer/n”, lock->name); if (has_lock == 0) // !=0,表明还有该类型的非超时锁被持有,现在还不能进入suspend { pr_info(“[wake_unlock]: (%s) suspend_work_queue suspend_work/n” , lock->name); queue_work(suspend_work_queue, &suspend_work); // 提交suspend的工作项,开始执行标准linux的suspend流程 } } … } spin_unlock_irqrestore(&list_lock, irqflags); }
2. 超时锁超时之后,定时器的回调函数会执行会查看是否有其他的wakelock, 如果没有,就在这里让系统进入睡眠。 static void expire_wake_locks(unsigned long data) { long has_lock; unsigned long irqflags; if (debug_mask & DEBUG_EXPIRE) pr_info(“expire_wake_locks: start/n”); spin_lock_irqsave(&list_lock, irqflags); if (debug_mask & DEBUG_SUSPEND) print_active_locks(WAKE_LOCK_SUSPEND); has_lock = has_wake_lock_locked(WAKE_LOCK_SUSPEND); if (debug_mask & DEBUG_EXPIRE) pr_info(“expire_wake_locks: done, has_lock %ld/n”, has_lock); if (has_lock == 0) // 如果没有SUSPEND类型的wakelock处于active,那么将调用suspend queue_work(suspend_work_queue, &suspend_work); spin_unlock_irqrestore(&list_lock, irqflags); } static DEFINE_TIMER(expire_timer, expire_wake_locks, 0, 0); 列出以下一个重要的函数源码: static long has_wake_lock_locked(int type) { struct wake_lock *lock, *n; long max_timeout = 0;
BUG_ON(type >= WAKE_LOCK_TYPE_COUNT); list_for_each_entry_safe(lock, n, &active_wake_locks[type], link) { if (lock->flags & WAKE_LOCK_AUTO_EXPIRE) { long timeout = lock->expires – jiffies; if (timeout <= 0) expire_wake_lock(lock); else if (timeout > max_timeout) max_timeout = timeout; } else return -1; } return max_timeout; }
3. 这个可能有人觉得匪夷所思,就是在wake_lock{_ _timeout}()函数中,调用了内部函数wake_lock_internal()。这里只有在对超时锁上锁的时候才有可能进入休眠,如果对一个费超时锁上锁的话,那么就没有必要去检查活动链表了。 static void wake_lock_internal( struct wake_lock *lock, long timeout, int has_timeout) { … if (type == WAKE_LOCK_SUSPEND) { current_event_num++; #ifdef CONFIG_WAKELOCK_STAT if (lock == &main_wake_lock) update_sleep_wait_stats_locked(1); else if (!wake_lock_active(&main_wake_lock)) update_sleep_wait_stats_locked(0); #endif if (has_timeout) // 超时锁的时候传进来的是1 expire_in = has_wake_lock_locked(type); // 检查当前锁类型链表上是否还有锁处于active的状态,无返回0 else expire_in = -1; // 如果是非超时锁的话,这里直接赋值-1,省去了活动链表检查步骤了 if (expire_in > 0) { if (debug_mask & DEBUG_EXPIRE) pr_info(“wake_lock: %s, start expire timer, ” “%ld/n”, lock->name, expire_in); // modify the time wakelock is expired mod_timer(&expire_timer, jiffies + expire_in); } else { if (del_timer(&expire_timer)) if (debug_mask & DEBUG_EXPIRE) pr_info(“wake_lock: %s, stop expire timer/n”, lock->name); if (expire_in == 0) // 没有锁处于active状态后,准备调用suspend了 { pr_info(“[wake_lock]: suspend_work_queue suspend_work/n “); queue_work(suspend_work_queue, &suspend_work); } } } spin_unlock_irqrestore(&list_lock, irqflags); }
下面是suspend的工作项,经过上面三种情况的检查,ok之后将会提交该工作项给工作队列suspend_work_queue,如下: static void suspend(struct work_struct *work) { int ret; int entry_event_num;
// there are still some wakelock if (has_wake_lock(WAKE_LOCK_SUSPEND)) { if (wakelock_debug_mask & DEBUG_SUSPEND) pr_info(“[suspend]: abort suspend/n”); return; }
entry_event_num = current_event_num; sys_sync(); if (debug_mask & DEBUG_SUSPEND) pr_info(“suspend: enter suspend/n”); ret = pm_suspend(requested_suspend_state); // requested_suspend_state这个全局变量在函数request_suspend_state()中被设置,也就是执行了eraly suspend或者late resume之后,主要是为suspend保留请求的省电状态。 if (debug_mask & DEBUG_EXIT_SUSPEND) { struct timespec ts; struct rtc_time tm; getnstimeofday(&ts); rtc_time_to_tm(ts.tv_sec, &tm); pr_info(“suspend: exit suspend, ret = %d ” “(%d-%02d-%02d %02d:%02d:%02d.%09lu UTC)/n”, ret, tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec); } if (current_event_num == entry_event_num) { if (debug_mask & DEBUG_SUSPEND) pr_info(“suspend: pm_suspend returned with no event/n”); wake_lock_timeout(&unknown_wakeup, HZ / 2); } } static DECLARE_WORK(suspend_work, suspend);
@kernel/kernel/power/suspend.c int pm_suspend(suspend_state_t state) { if (state > PM_SUSPEND_ON && state <= PM_SUSPEND_MAX) return enter_state(state); // 标准linux的suspend流程函数 return -EINVAL; } EXPORT_SYMBOL(pm_suspend);
Wakelock的机制被文件userwakelock.c中的code封装成了sys的接口sys/power/wake_lock和sys/power/wake_unlock文件,那么上层如果需要新建wakelock或者注销wakelock,或者是解锁wakelock,都是操作这两个sys接口文件。 四、android层源码解析 在linux之上经过android的软件堆层层封装,最终在上层的java应用程序中使用。休眠唤醒也是从最上层发出的命令,然后一层一层地将参数解析,往最底层传,最后走上标准linux的休眠唤醒之路。 这一部分将会初略分析休眠唤醒机制上linux之上所走的路线。 在linux之上,存在一个hal层,专门做和linux内核设备打交道的事情,这里也不例外。休眠唤醒机制的hal层源码位于:@hardware/libhardware_legacy/power/power.c 该文件源码比较简单,下面列举重点片段: enum { ACQUIRE_PARTIAL_WAKE_LOCK = 0, RELEASE_WAKE_LOCK, REQUEST_STATE, OUR_FD_COUNT }; const char * const NEW_PATHS[] = { “/sys/power/wake_lock”, “/sys/power/wake_unlock”, “/sys/power/state” }; static int g_initialized = 0; static int g_fds[OUR_FD_COUNT]; static const char *off_state = “mem”; static const char *on_state = “on”;
static int open_file_descriptors(const char * const paths[]) { int i; for (i=0; i<OUR_FD_COUNT; i++) { int fd = open(paths[i], O_RDWR); if (fd < 0) { fprintf(stderr, “fatal error opening /”%s/”/n”, paths[i]); g_error = errno; return -1; } g_fds[i] = fd; }
g_error = 0; return 0; }
static inline void initialize_fds(void) { if (g_initialized == 0) { if(open_file_descriptors(NEW_PATHS) < 0) { open_file_descriptors(OLD_PATHS); on_state = “wake”; off_state = “standby”; } g_initialized = 1; } }
int acquire_wake_lock(int lock, const char* id) { initialize_fds(); if (g_error) return g_error; int fd;
if (lock == PARTIAL_WAKE_LOCK) { // 上层传下来的lock type fd = g_fds[ACQUIRE_PARTIAL_WAKE_LOCK]; } else { return EINVAL; }
return write(fd, id, strlen(id)); }
int release_wake_lock(const char* id) { initialize_fds();
// LOGI(“release_wake_lock id=’%s’/n”, id);
if (g_error) return g_error;
ssize_t len = write(g_fds[RELEASE_WAKE_LOCK], id, strlen(id)); return len >= 0; }
int set_screen_state(int on) { QEMU_FALLBACK(set_screen_state(on)); LOGI(“*** set_screen_state %d”, on);
initialize_fds(); if (g_error) return g_error;
char buf[32]; int len; if(on) len = sprintf(buf, on_state); else len = sprintf(buf, off_state); len = write(g_fds[REQUEST_STATE], buf, len); if(len < 0) { LOGE(“Failed setting last user activity: g_error=%d/n”, g_error); } return 0; }
Hal层的代码在jni层中被使用,源码位于:frameworks/base/core/jni/android_os_Power.cpp,代码片段如下: static void acquireWakeLock(JNIEnv *env, jobject clazz, jint lock, jstring idObj) { if (idObj == NULL) { throw_NullPointerException(env, “id is null”); return ; }
const char *id = env->GetStringUTFChars(idObj, NULL);
acquire_wake_lock(lock, id);
env->ReleaseStringUTFChars(idObj, id); }// 对wakelock加锁函数 static void releaseWakeLock(JNIEnv *env, jobject clazz, jstring idObj) { if (idObj == NULL) { throw_NullPointerException(env, “id is null”); return ; }
const char *id = env->GetStringUTFChars(idObj, NULL);
release_wake_lock(id);
env->ReleaseStringUTFChars(idObj, id);
}// 对wakelock解锁函数 static int setScreenState(JNIEnv *env, jobject clazz, jboolean on) { return set_screen_state(on); }// 休眠唤醒的函数
Jni的方法需要注册到上层才可以使用,同时也需要在上层的对应java类中声明了native才可以使用。那么这里的方法在java中对应的声明在哪里呢?frameworks/base/core/java/android/os/Power.java,该文件定义一个java类,如下: public class Power { // can’t instantiate this class private Power() { } /** * Wake lock that ensures that the CPU is running. The screen might * not be on. */ public static final int PARTIAL_WAKE_LOCK = 1; /** * Wake lock that ensures that the screen is on. */ public static final int FULL_WAKE_LOCK = 2; public static native void acquireWakeLock(int lock, String id); public static native void releaseWakeLock(String id); … /** * Turn the screen on or off * * @param on Whether you want the screen on or off */ public static native int setScreenState(boolean on); … } 声明的jni接口应该是被java server在使用,这里就是专门的电源管理服务:PowerManagerService使用,具体源码位置在:frameworks/base/services/java/com/android/server/PowerManagerService.java。android在最上层还提供了现场的android.os.PowerManager类 (frameworks/base/core/java/android/os/PowerManager.java)来供app使用,PowerManager类会调用java服务PowerManagerService的方法来完成与wakelock相关的工作。 @ frameworks/base/core/java/android/os/PowerManager.java 类PowerManager中内嵌了一个WakeLock类,另外还定义了wakelock的类型,下面是代码片段: public class PowerManager { private static final String TAG = “PowerManager”; … /** * Wake lock that ensures that the CPU is running. The screen might * not be on. */ public static final int PARTIAL_WAKE_LOCK = WAKE_BIT_CPU_STRONG;
/** * Wake lock that ensures that the screen and keyboard are on at * full brightness. */ public static final int FULL_WAKE_LOCK = WAKE_BIT_CPU_WEAK | WAKE_BIT_SCREEN_BRIGHT | WAKE_BIT_KEYBOARD_BRIGHT; /** * Wake lock that ensures that the screen is on at full brightness; * the keyboard backlight will be allowed to go off. */ public static final int SCREEN_BRIGHT_WAKE_LOCK = WAKE_BIT_CPU_WEAK | WAKE_BIT_SCREEN_BRIGHT;
/** * Wake lock that ensures that the screen is on (but may be dimmed); * the keyboard backlight will be allowed to go off. */ public static final int SCREEN_DIM_WAKE_LOCK = WAKE_BIT_CPU_WEAK | WAKE_BIT_SCREEN_DIM;
/** * Wake lock that turns the screen off when the proximity sensor activates. * Since not all devices have proximity sensors, use * {@link #getSupportedWakeLockFlags() getSupportedWakeLockFlags()} to determine if * this wake lock mode is supported. * * {@hide} */ public static final int PROXIMITY_SCREEN_OFF_WAKE_LOCK = WAKE_BIT_PROXIMITY_SCREEN_OFF; … public class WakeLock { … WakeLock(int flags, String tag) { switch (flags & LOCK_MASK) { case PARTIAL_WAKE_LOCK: case SCREEN_DIM_WAKE_LOCK: case SCREEN_BRIGHT_WAKE_LOCK: case FULL_WAKE_LOCK: case PROXIMITY_SCREEN_OFF_WAKE_LOCK: break; default: throw new IllegalArgumentException(); }
mFlags = flags; mTag = tag; mToken = new Binder(); } public void acquire() { synchronized (mToken) { if (!mRefCounted || mCount++ == 0) { try { mService.acquireWakeLock(mFlags, mToken, mTag); } catch (RemoteException e) { } mHeld = true; } } } public void release(int flags) { synchronized (mToken) { if (!mRefCounted || –mCount == 0) { try { mService.releaseWakeLock(mToken, flags); } catch (RemoteException e) { } mHeld = false; } if (mCount < 0) { throw new RuntimeException(“WakeLock under-locked ” + mTag); } } } … } … public WakeLock newWakeLock(int flags, String tag) { if (tag == null) { throw new NullPointerException(“tag is null in PowerManager.newWakeLock”); } return new WakeLock(flags, tag); } public void goToSleep(long time) { try { mService.goToSleep(time); } catch (RemoteException e) { } } … public PowerManager(IPowerManager service, Handler handler) { mService = service; mHandler = handler; }
IPowerManager mService; Handler mHandler; } 应用实例: PowerManager pm = (PowerManager)getSystemService(Context.POWER_SERVICE); PowerManager.WakeLock wl = pm.newWakeLock(PowerManager.SCREEN_DIM_WAKE_LOCK, “Tag”); wl.acquire(); //申请锁这个里面会调用PowerManagerService里面acquireWakeLock() … wl.release(); //释放锁,显示的释放,如果申请的锁不在此释放系统就不会进入休眠。
接下来就会调用到java服务PowerManagerService中: public void acquireWakeLock(int flags, IBinder lock, String tag) { int uid = Binder.getCallingUid(); if (uid != Process.myUid()) { mContext.enforceCallingOrSelfPermission(android.Manifest.permission.WAKE_LOCK, null); } long ident = Binder.clearCallingIdentity(); try { synchronized (mLocks) { acquireWakeLockLocked(flags, lock, uid, tag); // 内部方法 } } finally { Binder.restoreCallingIdentity(ident); } }
acquireWakeLockLocked(flags, lock, uid, tag)会调用函数power类的方法: Power.acquireWakeLock(Power.PARTIAL_WAKE_LOCK,PARTIAL_NAME)。
public void releaseWakeLock(IBinder lock, int flags) { int uid = Binder.getCallingUid(); if (uid != Process.myUid()) { mContext.enforceCallingOrSelfPermission(android.Manifest.permission.WAKE_LOCK, null); }
synchronized (mLocks) { releaseWakeLockLocked(lock, flags, false); } } releaseWakeLockLocked(lock, flags, false)函数会调用power类的方法: Power.releaseWakeLock(PARTIAL_NAME);
上层休眠唤醒都是调用PowerManagerService类的方法: goToSleep() à goToSleepWithReason() à goToSleepLocked() à setPowerState() à setScreenStateLocked() à Power.setScreenState() à jni方法 Android层的代码分析得不是很详细,这里只关注框架和流程。下图是网上的一个框架,可以参考一下: 原创文章,转载请注明: 转载自elautoctrl 本文链接地址: Android在标准linux基础上对休眠唤醒的实现 |
|