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：
1）wakeup events framework core，在drivers/base/power/wakeup.c中實現，提供了wakeup events framework的核心功能，包括：
抽象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了，可以記錄在案了。
基於這種特性，kernel將它倆合併成一個32位的整型數，以原子操作的形式，一起更新。這種設計巧妙的讓人叫絕，值得我們學習。具體如下：
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）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
這篇文章寫的有點長了，不能繼續了，這幾個功能，會接下來的文章中繼續分析。
原創文章，轉發請註明出處。蝸窩科技，www.wowotech.net。
