1. 前言 本文繼續“Linux電源管理(6)_Generic PM之Suspend功能”中有關suspend同步以及PM wakeup的話題。這個話題，是近幾年Linux kernel最具爭議的話題之一，在國外Linux開發論壇，經常可以看到圍繞該話題的辯論。辯論的時間跨度和空間跨度可以持續很長， ...
1. 前言
本文繼續“Linux電源管理(6)_Generic PM之Suspend功能”中有關suspend同步以及PM wakeup的話題。這個話題，是近幾年Linux kernel最具爭議的話題之一，在國外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。
但由於系統在suspend的過程中，會進行process freeze、 device suspend等操作，而這些操作可能導致內核或用戶空間程式不能及時獲取wakeup events，從而使系統不能正確wakeup，這就是wakeup events framework要解決的問題：system suspend和system wakeup events之間的同步問題。
3. wakeup events framework的功能總結
仔細推敲一下，上面所講的同步問題包括兩種情況：
情況1：內核空間的同步
wakeup events產生後，通常是以中斷的形式通知device driver。driver會處理events，處理的過程中，系統不能suspend。
註1：同步問題只存在於中斷開啟的情況，因為若中斷關閉，就不會產生wakeup events，也就不存在同步的概念。
情況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
這篇文章寫的有點長了，不能繼續了，這幾個功能，會接下來的文章中繼續分析。
