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
這篇文章寫的有點長了，不能繼續了，這幾個功能，會接下來的文章中繼續分析，
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/24224.html
標籤：嵌入式