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。

總結

以上是生活随笔為你收集整理的Linux电源管理_Wakeup events framework－－（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。