一、Opportunistic sleep引言
1. 背景
（1） android 面臨的問題
Opportunistic sleep: 當沒有任務時，需要尋找時機，進入suspended
（2） 3類同步問題
a. 內核:driver處理event的過程中，系統不能suspend
b. 用戶:用戶進程處理的過程中系統不能suspend
c. 內核與用戶交互:
休眠過程中，觸發event, 需abort suspend流程;
event 事件需用戶態處理完畢後，才能suspend;
2. earlysuspend
3. autosleep
4. wakeup_count
5. 三種休眠機制的比較
（1）有關earlysuspend的討論
a. 更改了suspend 流程，引入了earlysuspend 接口；
b. 社區對該patch,有誤解，認爲其要替代runtime；
c. wakelock 實現過於複雜，名稱易造成誤解；
d. mini-summit: 有nokia 開發者,缺乏android 開發者，引入了非技術性的討論；
e. 應該使用pm_runtime, cpuidle; susupend 不應該存在；
f. 喚醒源的處理過程，貫穿整個系統，影響較大；
（2）有關autosleep的討論
a. android 市場份額越來越大，很多driver src code 脫離了mainline；
b. Linus 認爲需要合併android 的特性：suspend block；
c. Rafael J. Wysocki 認爲時機已經成熟，提出了新的解決方案；
d. 社區對該opportunisic suspend patch, 有誤解，引入了非技術性的討論：重新設計後，命名爲autosleep；
e. 考慮到android 的兼容性，接口上保留了wakelock; 實現上，進行了改進；
（3）有關wakeup_count的討論
a. 在userspace 基於wakeup_count 實現的 opportunistic sleep 機制；(與autosleep 類似)；
b. 內核空間，無wake_lock 概念；
c. 無suspend block 概念；
d. suspend 觸發的時機，全部交由用戶空間負責；
6. 引入autosleep | wakeup count的理由
（1）earlysuspend 被內核拋棄，需自己打補丁；
（2）使用earlysuspend, 對內核改動較大，更改了suspend 流程, 無法合併入mainline；
（3）對設備驅動影響較大，需額外實現earlysuspend 接口,不利於upstream；
（4）earlysuspend 已存在的問題：例如只支持開關屏時執行earlysuspend, 不利於動態功耗的優化；
（5）pm_runtime 已經在display, usb 等設備使用；
（6）upstream 的需求；
二、opportunistic sleep 框架
三、wakeup source 框架
1. 功能
a. 抽象wakeup source和wakeup event的概念；
b. 向各個device driver提供wakeup source的註冊、使能等接口；
c. 向各個device driver提供wakeup event的上報、停止等接口；
d. 向上層的PM core（包括wakeup count、auto sleep、suspend、hibernate等模塊）提供wakeup event的查詢接
口，以判斷是否可以suspend、是否需要終止正在進行的suspend；
2. 數據結構
（1）registered wakeup events(cnt)和saved_count；
（2）wakeup events in progress(inpr)；
3. 相關接口
四、wakeup count框架
1. 目標
有喚醒事件需處理時：
若系統在運行過程中，不能進入suspend;
若已進入suspend 流程，需及時退出;
2. 接口
a. bool pm_get_wakeup_count(unsigned int *count, bool block);
b. bool pm_save_wakeup_count(unsigned int count);
3. 流程
