Linux電源管理(7)_Wakeup events framework
1. 前言
本文繼續「Linux電源管理(6)_Generic PM之Suspend功能」中有關suspend同步以及PM wakeup的話題。這個話題，是近幾年Linux kernel最具爭議的話題之一，在國外Linux開發論壇，常常能夠看到圍繞該話題的辯論。辯論的時間跨度和空間跨度能夠持續很長，且沒法達成一致。linux
wakeup events framework是這個話題的一個臨時性的解決方案，包括wake lock、wakeup count、autosleep等機制。它們就是本文的話題。數據結構
2. wakeup events framework要解決的問題
咱們知道，系統處於suspend狀態，可經過wakeup events喚醒。具體的wakeup events能夠是按鍵按下，能夠是充電器插入，等等。可是，若是在suspend的過程當中，產生了wakeup events，怎麼辦？答案很確定，"wakeup"系統。因爲此時系統沒有真正suspend，因此這的"wakeup"是個假動做，實際上只是終止suspend。app
但因爲系統在suspend的過程當中，會進行process freeze、 device suspend等操做，而這些操做可能致使內核或用戶空間程序不能及時獲取wakeup events，從而使系統不能正確wakeup，這就是wakeup events framework要解決的問題：system suspend和system wakeup events之間的同步問題。async
3. wakeup events framework的功能總結
仔細推敲一下，上面所講的同步問題包括兩種狀況：學習
狀況1：內核空間的同步atom
wakeup events產生後，一般是以中斷的形式通知device driver。driver會處理events，處理的過程當中，系統不能suspend。
注1：同步問題只存在於中斷開啓的狀況，由於若中斷關閉，就不會產生wakeup events，也就不存在同步的概念。hibernate
狀況2：用戶空間的同步線程
通常狀況下，driver對wakeup events處理後，會交給用戶空間程序繼續處理，處理的過程，也不容許suspend。這又能夠分爲兩種狀況：
1）進行後續處理的用戶進程，根本沒有機會被調度，即該wakeup events沒法上報到用戶空間。
2）進行後續處理的用戶進程被調度，處理的過程當中（以及處理結束後，決定終止suspend操做），系統不能suspend。設計
所以，wakeup events framework就包括3大功能：指針
解決內核空間同步問題（framework的核心功能）；
解決用戶空間同步問題的情景1（wakeup count功能）；
解決用戶空間同步問題的情景2（wake lock功能） 。
注2：
用戶空間同步的兩種狀況，咋一看，很是合乎情理，kernel你得好好處理！但事實上，該同步問題牽涉到了另一個比較有爭議的話題：平常的電源管理機制。是否要基於suspend實現？系統什麼時候進入低功耗狀態，應該由誰決定？kernel仍是用戶空間程序？
這最終會決定是否存在用空間同步問題。可是，在當前這個時間點，對這個話題，Linux kernel developers和Android developers持相反的觀點。這也形成了wakeup events framework在實現上的撕裂。Kernel的本意是不肯處理用戶空間同步問題的，但爲了兼容Android平臺，不得不增長相關的功能（Wakeup count和Wake lock）。
蝸蝸會在下一篇文章和你們探討該話題，本文就先focus在wakeup events framework上。
4. wakeup events framework architecture
下面圖片描述了wakeup events framework的architecture：
圖片中紅色邊框的block是wakeup events相關的block：
抽象wakeup source和wakeup event的概念；
向各個device driver提供wakeup source的註冊、使能等接口；
向各個device driver提供wakeup event的上報、中止等接口；
向上層的PM core（包括wakeup count、auto sleep、suspend、hibernate等模塊）提供wakeup event的查詢接口，以判斷是否能夠suspend、是否須要終止正在進行的suspend。
2）wakeup events framework sysfs，將設備的wakeup信息，以sysfs的形式提供到用戶空間，供用戶空間程序查詢、配置。在drivers/base/power/sysfs.c中實現。
3）wake lock/unlock，爲了兼容Android舊的wakeup lock機制而留下的一個後門，擴展wakeup events framework的功能，容許用戶空間程序報告/中止wakeup events。換句話說，該後門容許用戶空間的任一程序決定系統是否能夠休眠。
4）wakeup count，基於wakeup events framework，解決用戶空間同步的問題。
5）auto sleep，容許系統在沒有活動時（即一段時間內，沒有產生wakeup event），自動休眠。
注3：在Linux kernel看來，power是系統的核心資源，不該開放給用戶程序隨意訪問（wake lock機制違背了這個原則）。而在運行時的電源管理過程當中，系統什麼時候進入低功耗狀態，也不是用戶空間程序能決定的（auto sleep中槍了）。所以，kernel對上述功能的支持，很是的不樂意，咱們能夠從kernel/power/main.c中sysfs attribute文件窺見一斑（只要定義了PM_SLEEP，就必定支持wakeup count功能，但autosleep和wake lock功能，由另外的宏定義控制）：
1: static struct attribute * g[] = {
2: &state_attr.attr,
3: #ifdef CONFIG_PM_TRACE
4: &pm_trace_attr.attr,
5: &pm_trace_dev_match_attr.attr,
6: #endif
7: #ifdef CONFIG_PM_SLEEP
8: &pm_async_attr.attr,
9: &wakeup_count_attr.attr,
10: #ifdef CONFIG_PM_AUTOSLEEP
11: &autosleep_attr.attr,
12: #endif
13: #ifdef CONFIG_PM_WAKELOCKS
14: &wake_lock_attr.attr,
15: &wake_unlock_attr.attr,
16: #endif
17: #ifdef CONFIG_PM_DEBUG
18: &pm_test_attr.attr,
19: #endif
20: #ifdef CONFIG_PM_SLEEP_DEBUG
21: &pm_print_times_attr.attr,
22: #endif
23: #endif
24: #ifdef CONFIG_FREEZER
25: &pm_freeze_timeout_attr.attr,
26: #endif
27: NULL,
28: };
5. 代碼分析
5.1 wakeup source和wakeup event
在kernel中，能夠喚醒系統的只有設備(struct device)，但並非每一個設備都具有喚醒功能，那些具備喚醒功能的設備稱做wakeup source。是時候回到這篇文章中了（Linux設備模型(5)_device和device driver），在那裏，介紹struct device結構時，涉及到一個struct dev_pm_info類型的power變量，蝸蝸說留待後面的專題講解。咱們再回憶一下struct device結構：
1: struct device {
2: ...
3: struct dev_pm_info power;
4: ...
5: };
該結構中有一個power變量，保存了和wakeup event相關的信息，讓咱們接着看一下struct dev_pm_info數據結構（只保留和本文有關的內容）：
1: struct dev_pm_info {
2: ...
3: unsigned int can_wakeup:1;
4: ...
5: #ifdef CONFIG_PM_SLEEP
6: ...
7: struct wakeup_source *wakeup;
8: ...
9: #else
10: unsigned int should_wakeup:1;
11: #endif
12: };
can_wakeup，標識本設備是否具備喚醒能力。只有具有喚醒能力的設備，纔會在sysfs中有一個power目錄，用於提供全部的wakeup信息，這些信息是以struct wakeup_source的形式組織起來的。也就是上面wakeup指針。具體有哪些信息呢？讓咱們看看struct wakeup_source的定義。
1: /* include\linux\pm_wakeup.h */
2: struct wakeup_source {
3: const char *name;
4: struct list_head entry;
5: spinlock_t lock;
6: struct timer_list timer;
7: unsigned long timer_expires;
8: ktime_t total_time;
9: ktime_t max_time;
10: ktime_t last_time;
11: ktime_t start_prevent_time;
12: ktime_t prevent_sleep_time;
13: unsigned long event_count;
14: unsigned long active_count;
15: unsigned long relax_count;
16: unsigned long expire_count;
17: unsigned long wakeup_count;
18: bool active:1;
19: bool autosleep_enabled:1;
20: };
所以，一個wakeup source表明了一個具備喚醒能力的設備，也稱該設備爲一個wakeup source。該結構中各個字段的意義以下：
name，該wakeup source的名稱，通常爲對應的device name（有個例外，就是wakelock）；
entery，用於將全部的wakeup source掛在一個鏈表中；
timer、timer_expires，一個wakeup source產生了wakeup event，稱做wakeup source activate，wakeup event處理完畢後（再也不須要系統爲此保持active），稱做deactivate。activate和deactivate的操做能夠由driver親自設置，也能夠在activate時，指定一個timeout時間，時間到達後，由wakeup events framework自動將其設置爲deactivate狀態。這裏的timer以及expires時間，就是用來實現該功能；
total_time，該wakeup source處於activate狀態的總時間（能夠指示該wakeup source對應的設備的繁忙程度、耗電等級）；
max_time，該wakeup source持續處於activate狀態的最大時間（越長越不合理）；
last_time，該wakeup source上次active的開始時間；
start_prevent_time，該wakeup source開始阻止系統自動睡眠（auto sleep）的時間點；
prevent_sleep_time，該wakeup source阻止系統自動睡眠的總時間；
event_count，wakeup source上報的event個數；
active_count，wakeup source activate的次數；
relax_count， wakeup source deactivate的次數；
expire_count，wakeup source timeout到達的次數；
wakeup_count，wakeup source終止suspend過程的次數；
active，wakeup source的activate狀態；
autosleep_enabled，記錄系統auto sleep的使能狀態（每一個wakeup source都重複記錄這樣一個狀態，這種設計真實不敢恭維！）
wakeup source表明一個具備喚醒能力的設備，該設備產生的能夠喚醒系統的事件，就稱做wakeup event。當wakeup source產生wakeup event時，須要將wakeup source切換爲activate狀態；當wakeup event處理完畢後，要切換爲deactivate狀態。所以，咱們再來理解一下幾個wakeup source比較混淆的變量：event_count, active_count和wakeup_count：
event_count，wakeup source產生的wakeup event的個數；
active_count，產生wakeup event時，wakeup source須要切換到activate狀態。但並非每次都要切換，所以有可能已經處於activate狀態了。所以active_count可能小於event_count，換句話說，頗有可能在前一個wakeup event沒被處理完時，又產生了一個。這從必定程度上反映了wakeup source所表明的設備的繁忙程度；
wakeup_count，wakeup source在suspend過程當中產生wakeup event的話，就會終止suspend過程，該變量記錄了wakeup source終止suspend過程的次數（若是發現系統老是suspend失敗，檢查一下各個wakeup source的該變量，就能夠知道問題出在誰身上了）。
5.2 幾個counters
在drivers\base\power\wakeup.c中，有幾個比較重要的計數器，是wakeup events framework的實現基礎，包括：
1）registered wakeup events和saved_count
記錄了系統運行以來產生的全部wakeup event的個數，在wakeup source上報event時加1。
這個counter對解決用戶空間同步問題頗有幫助，由於通常狀況下（不管是用戶程序主動suspend，仍是auto sleep），由專門的進程（或線程）觸發suspend。當這個進程判斷系統知足suspend條件，決定suspend時，會記錄一個counter值(saved_count)。在後面suspend的過程當中，若是系統發現counter有變，則說明系統產生了新的wakeup event，這樣就能夠終止suspend。
該功能便是wakeup count功能，會在後面更詳細的說明。
2）wakeup events in progress
記錄正在處理的event個數。
當wakeup source產生wakeup event時，會經過wakeup events framework提供的接口將wakeup source設置爲activate狀態。當該event處理結束後，設置爲deactivate狀態。activate到deactivate的區間，表示該event正在被處理。
當系統中有任何正在被處理的wakeup event時，則不容許suspend。若是suspend正在進行，則要終止。
思考一個問題：registered wakeup events在何時增長？答案是在wakeup events in progress減少時，由於已經完整的處理完一個event了，能夠記錄在案了。
1: /*
2: * Combined counters of registered wakeup events and wakeup events in progress.
3: * They need to be modified together atomically, so it's better to use one
4: * atomic variable to hold them both.
5: */
6: static atomic_t combined_event_count = ATOMIC_INIT(0);
7:
8: #define IN_PROGRESS_BITS (sizeof(int) * 4)
9: #define MAX_IN_PROGRESS ((1 << IN_PROGRESS_BITS) - 1)
10:
11: static void split_counters(unsigned int *cnt, unsigned int *inpr)
12: {
13: unsigned int comb = atomic_read(&combined_event_count);
14:
15: *cnt = (comb >> IN_PROGRESS_BITS);
16: *inpr = comb & MAX_IN_PROGRESS;
17: }
定義和讀取。
1: cec = atomic_add_return(MAX_IN_PROGRESS, &combined_event_count);
wakeup events in progress減1，registered wakeup events加1，這個語句簡直是美輪美奐，讀者能夠仔細品味一下，絕對比看xxx片還過癮，哈哈。
1: cec = atomic_inc_return(&combined_event_count);
wakeup events in progress加1。
5.3 wakeup events framework的核心功能
wakeup events framework的核心功能體如今它向底層的設備驅動所提供的用於上報wakeup event的接口，這些接口根據操做對象可分爲兩類，具體以下。
類型一（操做對象爲wakeup source，編寫設備驅動時，通常不會直接使用）：
1: /* include/linux/pm_wakeup.h */ 2: extern void __pm_stay_awake(struct wakeup_source *ws); 3: extern void __pm_relax(struct wakeup_source *ws); 4: extern void __pm_wakeup_event(struct wakeup_source *ws, unsigned int msec);
__pm_stay_awake，通知PM core，ws產生了wakeup event，且正在處理，所以不容許系統suspend（stay awake）；
__pm_relax，通知PM core，ws沒有正在處理的wakeup event，容許系統suspend（relax）；
__pm_wakeup_event，爲上邊兩個接口的功能組合，通知PM core，ws產生了wakeup event，會在msec毫秒內處理結束（wakeup events framework自動relax）。
注4：__pm_stay_awake和__pm_relax應成對調用。
注5：上面3個接口，都可以在中斷上下文調用。
類型二（操做對象爲device，爲設備驅動的經常使用接口）：
1: /* include/linux/pm_wakeup.h */ 2: extern int device_wakeup_enable(struct device *dev); 3: extern int device_wakeup_disable(struct device *dev); 4: extern void device_set_wakeup_capable(struct device *dev, bool capable); 5: extern int device_init_wakeup(struct device *dev, bool val); 6: extern int device_set_wakeup_enable(struct device *dev, bool enable); 7: extern void pm_stay_awake(struct device *dev); 8: extern void pm_relax(struct device *dev); 9: extern void pm_wakeup_event(struct device *dev, unsigned int msec);
device_set_wakeup_capable，設置dev的can_wakeup標誌（enable或disable，可參考5.1小節），並增長或移除該設備在sysfs相關的power文件；
device_wakeup_enable/device_wakeup_disable/device_set_wakeup_enable，對於can_wakeup的設備，使能或者禁止wakeup功能。主要是對struct wakeup_source結構的相關操做；
device_init_wakeup，設置dev的can_wakeup標誌，如果enable，同時調用device_wakeup_enable使能wakeup功能；
pm_stay_awake、pm_relax、pm_wakeup_event，直接調用上面的wakeup source操做接口，操做device的struct wakeup_source變量，處理wakeup events。
5.3.1 device_set_wakeup_capable
該接口位於在drivers/base/power/wakeup.c中，代碼以下：
1: void device_set_wakeup_capable(struct device *dev, bool capable)
2: {
3: if (!!dev->power.can_wakeup == !!capable)
4: return;
5:
6: if (device_is_registered(dev) && !list_empty(&dev->power.entry)) {
7: if (capable) {
8: if (wakeup_sysfs_add(dev))
9: return;
10: } else {
11: wakeup_sysfs_remove(dev);
12: }
13: }
14: dev->power.can_wakeup = capable;
15: }
該接口的實現很簡單，主要包括sysfs的add/remove和can_wakeup標誌的設置兩部分。若是設置can_wakeup標誌，則調用wakeup_sysfs_add，向該設備的sysfs目錄下添加power文件夾，並註冊相應的attribute文件。若是清除can_wakeup標誌，執行sysfs的移除操做。
wakeup_sysfs_add/wakeup_sysfs_remove位於drivers/base/power/sysfs.c中，對wakeup events framework來講，主要包括以下的attribute文件：
1: static struct attribute *wakeup_attrs[] = {
2: #ifdef CONFIG_PM_SLEEP
3: &dev_attr_wakeup.attr,
4: &dev_attr_wakeup_count.attr,
5: &dev_attr_wakeup_active_count.attr,
6: &dev_attr_wakeup_abort_count.attr,
7: &dev_attr_wakeup_expire_count.attr,
8: &dev_attr_wakeup_active.attr,
9: &dev_attr_wakeup_total_time_ms.attr,
10: &dev_attr_wakeup_max_time_ms.attr,
11: &dev_attr_wakeup_last_time_ms.attr,
12: #ifdef CONFIG_PM_AUTOSLEEP
13: &dev_attr_wakeup_prevent_sleep_time_ms.attr,
14: #endif
15: #endif
16: NULL,
17: };
18: static struct attribute_group pm_wakeup_attr_group = {
19: .name = power_group_name,
20: .attrs = wakeup_attrs,
21: }; 1: static struct attribute *wakeup_attrs[] = {
2: #ifdef CONFIG_PM_SLEEP
3: &dev_attr_wakeup.attr,
4: &dev_attr_wakeup_count.attr,
5: &dev_attr_wakeup_active_count.attr,
6: &dev_attr_wakeup_abort_count.attr,
7: &dev_attr_wakeup_expire_count.attr,
8: &dev_attr_wakeup_active.attr,
9: &dev_attr_wakeup_total_time_ms.attr,
10: &dev_attr_wakeup_max_time_ms.attr,
11: &dev_attr_wakeup_last_time_ms.attr,
12: #ifdef CONFIG_PM_AUTOSLEEP
13: &dev_attr_wakeup_prevent_sleep_time_ms.attr,
14: #endif
15: #endif
16: NULL,
17: };
18: static struct attribute_group pm_wakeup_attr_group = {
19: .name = power_group_name,
20: .attrs = wakeup_attrs,
21: };
1）wakeup
讀，得到設備wakeup功能的使能狀態，返回"enabled"或"disabled"字符串。
寫，更改設備wakeup功能的使能狀態，根據寫入的字符串（"enabled"或"disabled"），調用device_set_wakeup_enable接口完成實際的狀態切換。
設備wakeup功能是否使能，取決於設備的can_wakeup標誌，以及設備是否註冊有相應的struct wakeup_source指針。即can wakeup和may wakeup，以下：
1: /*
2: * Changes to device_may_wakeup take effect on the next pm state change.
3: */
4:
5: static inline bool device_can_wakeup(struct device *dev)
6: {
7: return dev->power.can_wakeup;
8: }
9:
10: static inline bool device_may_wakeup(struct device *dev)
11: {
12: return dev->power.can_wakeup && !!dev->power.wakeup;
13: }
2）wakeup_count
只讀，獲取dev->power.wakeup->event_count值。有關event_count的意義，請參考5.1小節，下同。順便抱怨一下，這個attribute文件的命名簡直糟糕透頂了！直接用event_count就是了，用什麼wakeup_count，會和wakeup source中的同名字段搞混淆的！
3）wakeup_active_count，只讀，獲取dev->power.wakeup->active_count值。
4）wakeup_abort_count，只讀，獲取dev->power.wakeup->wakeup_count值。
5）wakeup_expire_count，只讀，獲dev->power.wakeup->expire_count取值。
6）wakeup_active，只讀，獲取dev->power.wakeup->active值。
7）wakeup_total_time_ms，只讀，獲取dev->power.wakeup->total_time值，單位爲ms。
8）wakeup_max_time_ms，只讀，獲dev->power.wakeup->max_time取值，單位爲ms。
9）wakeup_last_time_ms，只讀，獲dev->power.wakeup->last_time取值，單位爲ms。
10）wakeup_prevent_sleep_time_ms，只讀，獲取dev->power.wakeup->prevent_sleep_time值，單位爲ms。
注6：閱讀上述代碼時，咱們能夠看到不少相似「!!dev->power.can_wakeup == !!capable」的、帶有兩個「！」操做符的語句，是爲了保證最後的操做對象非0即1。這從側面反映了內核開發者的嚴謹程度，值得咱們學習。
5.3.2 device_wakeup_enable/device_wakeup_disable/device_set_wakeup_enable
以device_wakeup_enable爲例（其它相似，就不浪費屏幕了）：
1: int device_wakeup_enable(struct device *dev)
2: {
3: struct wakeup_source *ws;
4: int ret;
5:
6: if (!dev || !dev->power.can_wakeup)
7: return -EINVAL;
8:
9: ws = wakeup_source_register(dev_name(dev));
10: if (!ws)
11: return -ENOMEM;
12:
13: ret = device_wakeup_attach(dev, ws);
14: if (ret)
15: wakeup_source_unregister(ws);
16:
17: return ret;
18: }
也很簡單：
a）若設備指針爲空，或者設備不具有wakeup能力，免談，報錯退出。
b）調用wakeup_source_register接口，以設備名爲參數，建立並註冊一個wakeup source。
c）調用device_wakeup_attach接口，將新建的wakeup source保存在dev->power.wakeup指針中。
wakeup_source_register接口的實現也比較簡單，會前後調用wakeup_source_create、wakeup_source_prepare、wakeup_source_add等接口，所作的工做包括分配struct wakeup_source變量所需的內存空間、初始化內部變量、將新建的wakeup source添加到名稱爲wakeup_sources的全局鏈表中、等等。
device_wakeup_attach接口更爲直觀，不過有一點咱們要關注，若是設備的dev->power.wakeup非空，也就是說以前已經有一個wakeup source了，是不容許再enable了的，會報錯返回。
5.3.3 pm_stay_awake
當設備有wakeup event正在處理時，須要調用該接口通知PM core，該接口的實現以下：
1: void pm_stay_awake(struct device *dev)
2: {
3: unsigned long flags;
4:
5: if (!dev)
6: return;
7:
8: spin_lock_irqsave(&dev->power.lock, flags);
9: __pm_stay_awake(dev->power.wakeup);
10: spin_unlock_irqrestore(&dev->power.lock, flags);
11: }
呵呵，直接調用__pm_stay_awake，這也是本文的index裏沒有該接口的緣由。接着看代碼。
1: void __pm_stay_awake(struct wakeup_source *ws)
2: {
3: unsigned long flags;
4:
5: if (!ws)
6: return;
7:
8: spin_lock_irqsave(&ws->lock, flags);
9:
10: wakeup_source_report_event(ws);
11: del_timer(&ws->timer);
12: ws->timer_expires = 0;
13:
14: spin_unlock_irqrestore(&ws->lock, flags);
15: }
因爲pm_stay_awake報告的event須要通過pm_relax主動中止，所以就再也不須要timer，因此__pm_stay_awake實現是直接調用wakeup_source_report_event，而後中止timer。接着看代碼：
1: static void wakeup_source_report_event(struct wakeup_source *ws)
2: {
3: ws->event_count++;
4: /* This is racy, but the counter is approximate anyway. */
5: if (events_check_enabled)
6: ws->wakeup_count++;
7:
8: if (!ws->active)
9: wakeup_source_activate(ws);
10: }
a）增長wakeup source的event_count，表示該source又產生了一個event。
b）根據events_check_enabled變量的狀態，決定是否增長wakeup_count。這和wakeup count的功能有關，到時再詳細描述。
c）若是wakeup source沒有active，則調用wakeup_source_activate，activate之。這也是5.1小節所描述的，event_count和active_count的區別所在。wakeup_source_activate的代碼以下。
1: static void wakeup_source_activate(struct wakeup_source *ws)
2: {
3: unsigned int cec;
4:
5: /*
6: * active wakeup source should bring the system
7: * out of PM_SUSPEND_FREEZE state
8: */
9: freeze_wake();
10:
11: ws->active = true;
12: ws->active_count++;
13: ws->last_time = ktime_get();
14: if (ws->autosleep_enabled)
15: ws->start_prevent_time = ws->last_time;
16:
17: /* Increment the counter of events in progress. */
18: cec = atomic_inc_return(&combined_event_count);
19:
20: trace_wakeup_source_activate(ws->name, cec);
21: }
a）調用freeze_wake，將系統從suspend to freeze狀態下喚醒。有關freeze功能，請參考相關的文章。
b）設置active標誌，增長active_count，更新last_time。
c）若是使能了autosleep，更新start_prevent_time，由於此刻該wakeup source會開始阻止系統auto sleep。具體可參考auto sleep的功能描述。
d）增長「wakeup events in progress」計數（5.2小節有描述）。該操做是wakeup events framework的靈魂，增長該計數，意味着系統正在處理的wakeup event數目不爲零，則系統不能suspend。
到此，pm_stay_awake執行結束，意味着系統至少正在處理一個wakeup event，所以不能suspend。那處理完成後呢？driver要調用pm_relax通知PM core。
5.3.4 pm_relax
pm_relax和pm_stay_awake成對出現，用於在event處理結束後通知PM core，其實現以下：
1: /**
2: * pm_relax - Notify the PM core that processing of a wakeup event has ended.
3: * @dev: Device that signaled the event.
4: *
5: * Execute __pm_relax() for the @dev's wakeup source object.
6: */
7: void pm_relax(struct device *dev)
8: {
9: unsigned long flags;
10:
11: if (!dev)
12: return;
13:
14: spin_lock_irqsave(&dev->power.lock, flags);
15: __pm_relax(dev->power.wakeup);
16: spin_unlock_irqrestore(&dev->power.lock, flags);
17: }
直接調用__pm_relax，以下：
1: void __pm_relax(struct wakeup_source *ws)
2: {
3: unsigned long flags;
4:
5: if (!ws)
6: return;
7:
8: spin_lock_irqsave(&ws->lock, flags);
9: if (ws->active)
10: wakeup_source_deactivate(ws);
11: spin_unlock_irqrestore(&ws->lock, flags);
12: }
若是該wakeup source處於active狀態，調用wakeup_source_deactivate接口，deactivate之。deactivate接口和activate接口同樣，是wakeup events framework的核心邏輯，以下：
1: static void wakeup_source_deactivate(struct wakeup_source *ws)
2: {
3: unsigned int cnt, inpr, cec;
4: ktime_t duration;
5: ktime_t now;
6:
7: ws->relax_count++;
8: /*
9: * __pm_relax() may be called directly or from a timer function.
10: * If it is called directly right after the timer function has been
11: * started, but before the timer function calls __pm_relax(), it is
12: * possible that __pm_stay_awake() will be called in the meantime and
13: * will set ws->active. Then, ws->active may be cleared immediately
14: * by the __pm_relax() called from the timer function, but in such a
15: * case ws->relax_count will be different from ws->active_count.
16: */
17: if (ws->relax_count != ws->active_count) {
18: ws->relax_count--;
19: return;
20: }
21:
22: ws->active = false;
23:
24: now = ktime_get();
25: duration = ktime_sub(now, ws->last_time);
26: ws->total_time = ktime_add(ws->total_time, duration);
27: if (ktime_to_ns(duration) > ktime_to_ns(ws->max_time))
28: ws->max_time = duration;
29:
30: ws->last_time = now;
31: del_timer(&ws->timer);
32: ws->timer_expires = 0;
33:
34: if (ws->autosleep_enabled)
35: update_prevent_sleep_time(ws, now);
36:
37: /*
38: * Increment the counter of registered wakeup events and decrement the
39: * couter of wakeup events in progress simultaneously.
40: */
41: cec = atomic_add_return(MAX_IN_PROGRESS, &combined_event_count);
42: trace_wakeup_source_deactivate(ws->name, cec);
43:
44:
45: split_counters(&cnt, &inpr);
46: if (!inpr && waitqueue_active(&wakeup_count_wait_queue))
47: wake_up(&wakeup_count_wait_queue);
48: }
a）relax_count加1（若是relax_count和active_count不等，則說明有重複調用，要退出）。
b）清除active標記。
c）更新total_time、max_time、last_time等變量。
d）若是使能auto sleep，更新相關的變量（後面再詳細描述）。
e）再欣賞一下藝術，wakeup events in progress減1，registered wakeup events加1。
f）wakeup count相關的處理，後面再詳細說明。
5.3.5 pm_wakeup_event
pm_wakeup_event是pm_stay_awake和pm_relax的組合版，在上報event時，指定一個timeout時間，timeout後，自動relax，通常用於不知道什麼時候能處理完成的場景。該接口比較簡單，就不一一描述了。
5.3.6 pm_wakeup_pending
drivers產生的wakeup events，最終要上報到PM core，PM core會根據這些events，決定是否要終止suspend過程。這表如今suspend過程當中頻繁調用pm_wakeup_pending接口上（可參考「Linux電源管理(6)_Generic PM之Suspend功能」）。該接口的實現以下：
1: /**
2: * pm_wakeup_pending - Check if power transition in progress should be aborted.
3: *
4: * Compare the current number of registered wakeup events with its preserved
5: * value from the past and return true if new wakeup events have been registered
6: * since the old value was stored. Also return true if the current number of
7: * wakeup events being processed is different from zero.
8: */
9: bool pm_wakeup_pending(void)
10: {
11: unsigned long flags;
12: bool ret = false;
13:
14: spin_lock_irqsave(&events_lock, flags);
15: if (events_check_enabled) {
16: unsigned int cnt, inpr;
17:
18: split_counters(&cnt, &inpr);
19: ret = (cnt != saved_count || inpr > 0);
20: events_check_enabled = !ret;
21: }
22: spin_unlock_irqrestore(&events_lock, flags);
23:
24: if (ret)
25: print_active_wakeup_sources();
26:
27: return ret;
28: }
該接口的邏輯比較直觀，先拋開wakeup count的邏輯不談（後面會重點說明），只要正在處理的events不爲0，就返回true，調用者就會終止suspend。
5.4 wakeup count、wake lock和auto sleep
這篇文章寫的有點長了，不能繼續了，這幾個功能，會接下來的文章中繼續分析。
- 1. Linux電源管理_Wakeup events framework－－（二）
- 2. 電源管理
- 3. Linux電源管理-Runtime PM
- 4. Linux電源管理
- 5. Linux電源管理_autosleep－－（五）【轉】
- 6. Linux電源管理（六）cpuhotplug
- 7. Linux電源管理研究筆記—動態電源管理 DPM
- 8. Linux電源管理研究筆記—動態電源管理(DPM)
- 9. Linux電源管理（一）電源管理系統架構
- 10. Android電源管理
- 更多相關文章...
- • Swarm 集羣管理 - Docker教程
- • Maven 依賴管理 - Maven教程
- • Docker 清理命令
- • ☆技術問答集錦（13）Java Instrument原理
-
每一个你不满意的现在，都有一个你没有努力的曾经。