有四种方式可以引起休眠
①在wake_unlock()中, 如果发现解锁以后没有任何其他的wake lock了, 就开始休眠
②在定时器到时间以后, 定时器的回调函数会查看是否有其他的wake lock, 如果没有, 就在这里让系统进入睡眠
③在wake_lock() 中, 对一个wake lock加锁以后, 会再次检查一下有没有锁, 刚加上锁,为什么要检查,有用吗?
④按power键,调用earlysuspend.使系统或应用程序释放锁.从而调用上述三个函数进入休眠
- earlysuspend、autosleep以及wakeup_count三种休眠机制的分析和比较
1） android 面临的问题
Opportunistic sleep: 当没有任务时，需要寻找时机，进入suspended
2） 3类同步问题
a. 内核:driver处理event的过程中，系统不能suspend
b. 用户:用户进程处理的过程中系统不能suspend
c. 内核与用户交互:
休眠过程中，触发event, 需abort suspend流程;
event 事件需用户态处理完毕后，才能suspend;
2.常见的休眠唤醒机制有三种：earlysuspend、autosleep、wakeup_count。
- earlysuspend机制介绍：
由上图可得，应用程序application层创建，申请，释放wake_lock锁，通过上层应用类PowerManagerService.java获得和释放wake_lock锁。
对于进入休眠，有两种情况：
- 一种是power键灭屏关闭LCD、TP,或者后台有一些进程正在执行，如音乐播放器、文件传输之类，此时系统会先进入early_suspend状态，然后当这些正在执行的进程执行完成，PowerManagerService检查系统已经没有wake_lock锁时，系统进入深度休眠状态，Early_suspend与late_resume成对出现。
- 另一种是，系统直接检查到没有wake_lock锁时，直接进入深度睡眠状态。
- Autosleep
- Wakeup_count
- Android在Linux内核原有的睡眠唤醒模块基础上，主要增加了下面三个机制
• Wake Lock 唤醒锁机制；
• Early Suspend 预挂起机制；
• Late Resume 迟唤醒机制；
其基本原理：当启动一个应用程序的时候，它可以申请一个wake_lock唤醒锁，每当申请成功后都会在内核中注册一下（通知系统内核，现在已经有锁被申请，系统内核的wake_lock_store把它加入锁中），当应用程序在某种情况下释放wake_lock的时候，会注销之前所申请的wake_lock。特别要注意的是：只要是系统中有一个wake_lock的时候，系统此时都不能进行睡眠。但此时各个模块可以进行early_suspend。当系统中所有的wake_lock都被释放之后，系统就会进入真正的kernel的睡眠状态。在系统启动的时候会创建一个主唤醒锁main_wake_lock，该锁是内核初始化并持有的一个WAKE_LOCK_SUSPEND属性的非限时唤醒锁。因此，系统正常工作时，将始终因为该锁被内核持有而无法进入睡眠状态。也就是说在不添加新锁的情况下，只需将main_wake_lock 解锁，系统即可进入睡眠状态。
从Android最上层（Java的应用程序），经过Java、C++和C语言写的Framework层、JNI层、HAL层最后到达android的最底层（Kernel层）。
相关代码位置：
Frameworks
// 供给上层应用程序调用的接口
frameworks/base/core/java/android/os/PowerManager.java
// 具体实现PowerManager类中的接口
frameworks/base/services/java/com/android/server/PowerManagerService.java
// 被PowerManagerService类调用
frameworks/base/core/java/android/os/ Power.java
• JNI
// 实现Power类中的JNI接口
frameworks/base/core/jni/android_os_Power.cpp
• HAL
// 进行sysfs用户接口的操作
hardware/libhardware_legacy/power/power.c
• Kernel
kernel/kernel/power/main.c
kernel/kernel/power/earlysuspend.c
kernel/kernel/power/suspend.c
kernel/kernel/power/wakelock.c
kernel/kernel/power/userwakelock.c
在应用程序框架层中，PowerManager类是面向上层应用程序的接口类，提供了Wake Lock机制（同时也是睡眠唤醒子系统）的基本接口（唤醒锁的获取和释放）。上层应用程序通过调用这些接口，实现对系统电源状态的监控。
• PowerManager类通过IBinder这种Android中特有的通信模式，与PowerManagerService 类进行通信。
PowerManagerService 是PowerManager 类中定义的接口的具体实现，并进一步调用Power 类来与下一层进行通信。PowerManagerService 类是WakeLock 机制在应用程序框架层的核心，他们对应用程调用PowerManager类接口时所传递的参数进行初步的分析和对应的设置，并管理一个唤醒锁队列，然后配合其他模块（例如WatchDog、BatteryService、ShutdownThread 等）的状态信息，做出决策，调用Power类的对应接口，最终通过JNI 接口，调用到硬件抽象层中的函数，对sysfs 的用户接口进行操作，从而触发内核态实现的功能。
- 获得wake_lock唤醒锁
比如在应用程序中，当获得wakelock唤醒锁的时候，它首先调用/android/frameworks/base/core/java/android/os/PowerManager类中的public void acquire（）办法，而此方法通过Binder将调用PowerManagerService类中的public void acquireWakeLock。
在用户态的调用流程如下：
上述write实质上是文件sysfs: /sys/power/wake_lock，当write时，它将调用userwakelock.c::wake_lock_store()函数，其实现如下：
1. 根据name在红黑树中查找user_wake_lock，若找到则直接返回；否则为它分配内存、调用wake_lock_init初始化、然后增加到红黑树中。
2. 调用wake_lock或wake_lock_timeout，它将调用wake_lock_internal
wake_lock_internal()函数流程：
1) 判断锁的类型是否有效,即是否为WAKE_LOCK_SUSPEND或WAKE_LOCK_IDLE某一种
2) 如果定义了CONFIG_WAKELOCK_STAT, 则更新struct wake_lock里面的用于统计锁信息的成员变量
3) 将锁从inactive_locks链表上取下,加到active_wake_locks链表上。如果是超期锁则设置锁的flag|=WAKE_LOCK_AUTO_EXPIRE,否则取消WAKE_LOCK_AUTO_EXPIRE标志。如果锁是WAKE_LOCK_SUSPEND型的,则继续下面的步骤。
4) 对于WAKE_LOCK_SUSPEND型的锁如果它是超期锁,则调用has_wake_lock_locked函数检查所有处于活动状态的WAKE_LOCK_SUSPEND锁（即在active_wake_locks链表上的WAKE_LOCK_SUSPEND锁,或者说当前被加锁了的WAKE_LOCK_SUSPEND锁）,是否有超期锁已经过期,如果有则把过期超期锁从active_wake_locks上删除,挂到inactive_locks上。同时它还检查链表上有没有非超期锁,如果有则直接返回-1,否则它最终返回的是所有超期锁过期时间的最大值
5) 如果has_wake_lock_locked函数返回的是-1（表示当前活动锁有非超时锁）或者0（表示所有活动锁都是超时锁,且全已经超时）,则删除expire_timer,并排队一个suspend工作到suspend_work_queue工作队列,最终系统会suspend。suspend函数完成suspend系统的任务，它是suspend_work这个工作的处理函数，suspend_workk排队到suspend_work_queue工作队列中，最终系统会处理这个work，调用其handler即suspend函数。该函数首先sync文件系统，然后调用pm_suspend(request_suspend_state)，接下来pm_suspend()就会调用 enter_state()来进入 linux的suspend流程。
- 系统进入休眠（suspend）
当按了MID上的power键，经过一系统列的事务处理后，它会调用到PowerManager类中的goToSleep。在用户态的调用流程如下所示：
最后一步write()写操作把”mem”写入/sys/power/state中。接下来，在kernel态，state_store函数将被调用。
• Android特有的earlysuspend： request_suspend_state(state)
• Linux标准的suspend： enter_state(state)
在state_store()首先判断用户写入的是否是”disk”字符串，如果是则调用hibernate()函数命令系统进入hibernation状态。如果是其他字符串则调用request_suspend_state()（如果定义 CONFIG_EARLYSUSPEND）或者调用enter_state()（如果未定义CONFIG_EARLYSUSPEND）。 request_suspend_state()函数是android相对标准linux改动的地方，它实现在earlysuspend.c中。在标准linux内核中，用户通过 sysfs 写入”mem”和”standby”时，会直接调用enter_state()进入suspend模式，但在android中则会调用request_suspend_state()函数进入early suspend状态。
static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr, const char *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 const char * const *s; #endif char *p; int len; int error = -EINVAL;
p = memchr(buf, ‘\n’, n); len = p ? p – buf : n;
if (len == 4 && !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 = 0; request_suspend_state(state); } #else #endif #endif Exit: return error ? error : n; } |
在request_suspend_state(state)函数中，会调用early_suspend_work的工作队列，从而进入early_suspend()函数中。
static DECLARE_WORK(early_suspend_work, early_suspend);
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; if (debug_mask & DEBUG_USER_STATE) { struct timespec ts; 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-d-d d:d:d. lu 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); } if (!old_sleep && new_state != PM_SUSPEND_ON) { state |= SUSPEND_REQUESTED; queue_work(suspend_work_queue, &early_suspend_work); } else if (old_sleep && new_state == PM_SUSPEND_ON) { state &= ~SUSPEND_REQUESTED; wake_lock(&main_wake_lock); queue_work(suspend_work_queue, &late_resume_work); } requested_suspend_state = new_state; spin_unlock_irqrestore(&state_lock, irqflags); } 在early_suspend()函数中，首先要判断当前请求的状态是否还是suspend，若不是，则直接退出了；若是，函数会调用已经注册的early_suspend的函数。然后同步文件系统，最后释放main_wake_lock。
|
在suspend()函数中，先判断当前是否有wake_lock，若有，则退出；然后同步文件系统，最后调用pm_suspend()函数。
static void suspend(struct work_struct *work) { int ret; int entry_event_num;
if (has_wake_lock(WAKE_LOCK_SUSPEND)) { if (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); 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-d-d d:d:d. lu 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); } } |
在pm_suspend()函数中，enter_state()函数被调用，从而进入标准linux休眠过程
int pm_suspend(suspend_state_t state) { if (state > PM_SUSPEND_ON && state <= PM_SUSPEND_MAX) return enter_state(state); return -EINVAL; } |
在enter_state()函数中，首先检查一些状态参数，再同步文件系统，然后调用suspend_prepare()来冻结进程，最后调用suspend_devices_and_enter()让外设进入休眠。
static int enter_state(suspend_state_t state) { int error;
if (!valid_state(state)) return -ENODEV;
if (!mutex_trylock(&pm_mutex)) return -EBUSY;
printk(KERN_INFO “PM: Syncing filesystems … “); sys_sync(); printk(“done.\n”);
pr_debug(“PM: Preparing system for %s sleep\n”, pm_states[state]); error = suspend_prepare(); if (error) goto Unlock;
if (suspend_test(TEST_FREEZER)) goto Finish;
pr_debug(“PM: Entering %s sleep\n”, pm_states[state]); error = suspend_devices_and_enter(state);
Finish: pr_debug(“PM: Finishing wakeup.\n”); suspend_finish(); Unlock: mutex_unlock(&pm_mutex); return error; } 外部设备在注册时，都会注册其自身的suspend函数，enter_state()函数通过回调这些设备的suspend使其进入suspend态 |
- Linux电源管理的基础培训
- 高通平台的电源管理机制是由RPM（running PowerManager）统一管理，每个子系统都有自己的休眠唤醒机制，当子系统进入待机时，其会发送消息给RPM，并让自身进入待机状态，RPM子系统根据各子系统的休眠状态，决定整个系统是否进待机（XO_SHUTDOWN）
- PMIC有单独的电源给子系统供电，这就决定了子系统待机时可以关闭自身的电源用于降低功耗。
- AP的待机有几种模式：
- WFI：wait for interrupt：正常的待机状态，AP电源关闭，GIC模块工作，用于接收中断
- Idle power collapse: 正常工作时CPU进低功耗模式
- 子系统的待机不受其他子系统的影响
- AP休眠
AP的休眠唤醒流程由应用层发起，统一由power manager service线程管理，其通过JNI调用libsuspend的库函数，对内核进行操作。 Powermanger service: /frameworks/base/service/core/java/com/android/server/power/powermanagerservice.java JNI: /frameworks/base/service/core/jni Libsuspend: /system/core/libsuspend内核的接口 Linux内核有两种休眠唤醒接口： /sys/power/autosleep /sys/power/state 其区别在autosleep的方式为当应用设置系统休眠时，其如果发现无法进待机，则会不断的尝试进行待机。State方式为用户空间设置系统待机，如果无法待机，则退出待机流程。 Autosleep方式目前默认不采用，主要原因是应用的控制流程上有无法规避的问题。
- 每个模块都会注册其自身的休眠唤醒流程，用于进行低功耗处理
对于系统核心模块的休眠是在最后一步syscore suspend中完成，如cpu、GIC、CLK、SMD的休眠处理。 
