Android在標準linux基礎上對休眠喚醒的實現（一）（轉貼）

說明：

1. Based on linux 2.6.32 and android 2.2，only support SDR(mem).

2.參考文章：

http://2695477.blog.51cto.com/blog/2685477/484751

http://www.docin.com/p-115475680.html

http://blogold.chinaunix.net/u3/113927/showart_2447111.html

http://www.cnmsdn.com/html/201003/1269407632ID2530.html

一、新增特性介紹

實際上，android仍然是利用了標準linux的休眠喚醒系統，只不過添加了一些使用上的新特性，early suspend、late resume、wake lock。

Early suspend -這個機制定義了在suspend的早期，關閉顯示屏的時候，一些和顯示屏相關的設備，比如背光、重力感應器和触摸屏等設備都應該被關掉，但是此時系統可能還有持有wake lock的任務在運行，如音樂播放，電話，或者掃描sd卡上的文件等，這個時候整個系統還不能進入真正睡眠，直到所有的wake lock都被釋放。在嵌入式設備中，背光是一個很大的電源消耗，所有android加入了這種機制。

Late resume -這個機制定義了在resume的後期，也就是喚醒源已經將處理器喚醒，標準linux的喚醒流程已經走完了，在android上層系統識別出這個物理上的喚醒源是上層定義的，那麼上層將會發出late resume的命令給下層，這個時候將會調用相關設備註冊的late resume回調函數。

Wake lock - wakelock在android的電源管理系統中扮演一個核心的角色，wakelock是一種鎖的機制,只要有task拿著這個鎖,系統就無法進入休眠,可以被用戶態進程和內核線程獲得。這個鎖可以是有time-out的或者是沒有time-out, 具有time-out的wake_lock會在時間過去以後自動解鎖。如果沒有鎖了或者超時了,內核就會啟動標準linux的那套休眠機制機制來進入休眠。

二、 kernel層源碼解析- early suspend和late resume實現

相關源碼：

kernel/ke​​rnel/power/main.c

kernel/ke​​rnel/power/earlysuspend.c

kernel/ke​​rnel/power/wakelock.c

kernel/ke​​rnel/power/userwakelock.c

kernel/ke​​rnel/power/suspend.c

之前標準的linux的sysfs的接口只需要一個state就夠了，現在至少需要3個接口文件：state、wake_lock、wake_unlock。現在為了配合android為休眠喚醒添加的幾種新特性，可以填入文件state的模式又多了一種：on,標準android系統中只支持state的on和mem模式，其餘的暫不支持。wake_lock和wake_unlock接口對應的讀寫函數在文件userwakelock.c中，對wakelock.c中的create wakelock或者release wakelock進行了封裝，供用戶空間來使用。

如果上層用戶執行:echo xxx(on or mem) > sys/power/state的話，將會調用到如下函數：

static ssize_t state_store (struct kobject *kobj, struct kobj_attribute *attr,

const char *buf, size_t n)

{

#ifdef CONFIG_SUSPEND // set

#ifdef CONFIG_EARLYSUSPEND    //set

       suspend_state_t state = PM_SUSPEND_ON;    // for early suspend and late resume

#else

       suspend_state_t state = PM_SUSPEND_STANDBY;

#endif

       const char * const *s;

#endif

       char *p;

       int len​​;

       int error = -EINVAL;

       p = memchr(buf, '/n', n);

       len = p ? p - buf : n;

       /* First, check if we are requested to hibernate */

       if (len == 4 && ! ​​strncmp(buf, "disk", len) ) {

              error = hibernate(); //  檢查是否要求進入disk省電模式，暫時不支持

  goto Exit;

       }

#ifdef CONFIG_SUSPEND         // def

       for (s = &pm_states[state]; state < PM_SUSPEND_MAX; s++, state++) {

              if (*s && len == strlen(*s) && !strncmp(buf, *s, len))

                     break;

       }

       if (state < PM_SUSPEND_MAX && *s)

#ifdef CONFIG_EARLYSUSPEND

              if ( state == PM_SUSPEND_ON || valid_state(state) ) {

//需要經過平台pm.c文件定義的模式支持檢查函數，mtk只支持mem，同時如果是android發送出來的late resume命令(on)，這裡也會放行，往下執行

                     error = 0;

                     request_suspend_state(state) ;      // android休眠喚醒的路線

              }

#else

              error = enter_state(state) ; //標準linux休眠喚醒的路線

#endif

#endif

 Exit:

       return error ? error : n;

}

@ kernel/ke​​rnel/power/earlysuspend.c

enum {

       DEBUG_USER_STATE = 1U << 0,

       DEBUG_SUSPEND = 1U << 2,

};

int Earlysuspend_debug_mask = DEBUG_USER_STATE;

module_param_named(Earlysuspend_debug_mask, Earlysuspend_debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);

static DEFINE_MUTEX(early_suspend_lock);

static LIST_HEAD(early_suspend_handlers);

static void early_sys_sync(struct work_struct *work);

static void early_suspend(struct work_struct *work);

static void late_resume(struct work_struct *work);

static DECLARE_WORK(early_sys_sync_work, early_sys_sync);

static DECLARE_WORK(early_suspend_work, early_suspend);

static DECLARE_WORK(late_resume_work, late_resume);

static DEFINE_SPINLOCK(state_lock);

enum {

       SUSPEND_REQUESTED = 0x1,

       SUSPENDED = 0x2,

       SUSPEND_REQUESTED_AND_SUSPENDED = SUSPEND_REQUESTED | SUSPENDED,

};

static int state;              //初始化為0

static DECLARE_COMPLETION(fb_drv_ready);

void request_suspend_state (suspend_state_t new_state)

{

       unsigned long irqflags;

       int old_sleep;

       spin_lock_irqsave(&state_lock, irqflags);

       old_sleep = state & SUSPEND_REQUESTED; // state = 1 or 3

// state的值會在0->1->3->2->0循環變化，後面分析代碼都可以看出這些值代表系統目前處於什麼階段，簡單得說就是：正常->準備進early suspend ->開始early suspend並且對名為main的wakelock解鎖，如果此時沒有其餘wakelock處於lock狀態，那麼系統就走linux的休眠喚醒路線讓整個系統真正休眠，直到喚醒源發生，然後將處理器和linux層喚醒。之後android層判斷本次底層醒來是由於我所定義的喚醒源引起的嗎？如果不是，android將不予理會，過段時間沒有wakelock鎖，系統會再次走linux的休眠路線進入休眠。如果是，那麼android上層就會寫一個on的指令到state接口中，同樣是會調用到函數request_suspend_state() -> 準備執行late resume ->開始執行late resume，之後整個系統就這樣被喚醒了。

       if (Earlysuspend_debug_mask & DEBUG_USER_STATE) {

              struct timespec ts; //        打印出debug信息

              struct rtc_time tm;

              getnstimeofday(&ts);

              rtc_time_to_tm(ts.tv_sec, &tm);

              pr_info("[request_suspend_state]: %s (%d->%d) at %lld "

                     "(%d-%02d-%02d %02d:%02d:%02d.%09lu UTC)/n",

                     new_state != PM_SUSPEND_ON ? "sleep" : "wakeup",

                     requested_suspend_state , new_state ,

                     ktime_to_ns(k​​time_get()),

                     tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,

                     tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec);

       }

// eg: [request_suspend_state]: sleep (0->3) at 97985478409 (2010-01-03 09:52:59.637902305 UTC)， 這裡對時間的獲取和處理，在其他地方可以參考

       // ready to enter earlysuspend

       if ( !old_sleep && new_state != PM_SUSPEND_ON ) { // susepnd會進入這裡

              state |= SUSPEND_REQUESTED; // state = 1   

              pr_info("[request_suspend_state]:

sys_sync_work_queue early_sys_sync_work/n");

              queue_work(sys_sync_work_queue, &early_sys_sync_work);

              pr_info("[request_suspend_state]: suspend_work_queue early_suspend_work/n");

              queue_work(suspend_work_queue, &early_suspend_work);

//在wakelocks_init()函數(wakelock.c)中會創建這兩個工作隊列和工作者線程來專門負責處理sys_sync和early suspend的工作。關於工作隊列的詳情參考我工作隊列的文章

       }

       // ready to enter lateresume

       else if ( old_sleep && new_state == PM_SUSPEND_ON ) {

              state &= ~SUSPEND_REQUESTED; // state = 2

              wake_lock(&main_wake_lock);          //對main wakelock上鎖

              pr_info("[request_suspend_state]: suspend_work_queue late_resume_work/n" );

              if ( queue_work(suspend_work_queue, &late_resume_work) ) {

//提交late resume的工作項

            //

            //   In order to synchronize the backlight turn on timing,

            //   block the thread and wait for fb driver late_resume()

                  //   callback function is completed

                  //

            wait_for_completion(&fb_drv_ready);     

//等待完成量fb_drv_ready，他會在late resume結束之後完成

        }

       }

       requested_suspend_state = new_state;     

//存儲本次休眠或者是喚醒的狀態，供下次休眠或者喚醒使用

       spin_unlock_irqrestore(&state_lock, irqflags);

}

在系統suspend的時候提交的兩個工作項會陸續被執行到，那麼下面就來看一下執行early suspend的關鍵函數。

static void early_sys_sync (struct work_struct *work)

{

       wake_lock(&sys_sync_wake_lock);

       printk("[sys_sync work] start/n");

       sys_sync() ;    //同步文件系統

       printk("[sys_sync wrok] done/n");

       wake_unlock(&sys_sync_wake_lock);

}

static void early_suspend (struct work_struct *work)

{

       struct early_suspend *pos;

       unsigned long irqflags;

       int abort = 0;

       mutex_lock(&early_suspend_lock);

       spin_lock_irqsave(&state_lock, irqflags);

       if ( state == SUSPEND_REQUESTED )

              state |= SUSPENDED; // state = 3

       else

              abort = 1;

       spin_unlock_irqrestore(&state_lock, irqflags);

       if (abort) { // suspend     中止退出

              if (Earlysuspend_debug_mask & DEBUG_SUSPEND)

                     pr_info("[early_suspend]: abort, state %d/n", state);

              mutex_unlock(&early_suspend_lock);

              goto abort;

       }

       if (Earlysuspend_debug_mask & DEBUG_SUSPEND)

              pr_info("[early_suspend]: call handlers/n");

       list_for_each_entry(pos, &early_suspend_handlers, link) {

              if (pos->suspend != NULL)

                     pos->suspend(pos);

       }

//函數register_early_suspend()會將每一個early suspend項以優先級大小註冊到鍊錶early_suspend_handlers中，這裡就是一次取出，然後執行對應的early suspend回調函數

       mutex_unlock(&early_suspend_lock);

       // Remove sys_sync from early_suspend,

       // and use work queue to complete sys_sync

abort:

       spin_lock_irqsave(&state_lock, irqflags);

       if (state == SUSPEND_REQUESTED_AND_SUSPENDED)

       {

              pr_info("[early_suspend]: wake_unlock(main)/n");

              wake_unlock(&main_wake_lock);

// main wakelock解鎖。看到這裡，好像系統執行了early suspend之後就沒有往下執行標準linux的suspend流程了，其實不是，android的做法是，不是你執行完了early suspend  的回調就可以馬上走標準linux的suspend流程，而是會檢查還有沒有wakelock被持有，如果所有wakelock全是解鎖狀態，那麼就會執行標準linux的suspend步驟。

}

       spin_unlock_irqrestore(&state_lock, irqflags);

}

static void late_resume (struct work_struct *work)

{

       struct early_suspend *pos;

       unsigned long irqflags;

       int abort = 0;

    int completed = 0;

       mutex_lock(&early_suspend_lock);

       spin_lock_irqsave(&state_lock, irqflags);

    // return back from suspend

       if ( state == SUSPENDED )

              state &= ~SUSPENDED ; // state = 0   

       else

              abort = 1;

       spin_unlock_irqrestore(&state_lock, irqflags);

       if (abort) {

              if (Earlysuspend_debug_mask & DEBUG_SUSPEND)

                     pr_info("[late_resume]: abort, state %d/n", state);

              goto abort;

       }

       if (Earlysuspend_debug_mask & DEBUG_SUSPEND)

              pr_info("[late_resume]: call handlers/n");

       list_for_each_entry_reverse(pos, &early_suspend_handlers, link)

    {

        if (!completed && pos->level < EARLY_SUSPEND_LEVEL_DISABLE_FB) {

            complete(&fb_drv_ready);

            completed = 1;

        }

              if (pos->resume != NULL)

                     pos->resume(pos);

    }

//以和early suspend的逆序執行鍊錶early_suspend_handlers上的late resume回調函數

if (Earlysuspend_debug_mask & DEBUG_SUSPEND)

              pr_info("[late_resume]: done/n");

abort:

    if (!completed)

        complete(&fb_drv_ready); //   設置完成量ok

     mutex_unlock(&early_suspend_lock);

}

中斷 part 2

1.5 Interrupt Flow Handling （中斷流處理）

前面提到了 IRQ 子系統的三個 抽象層： High-level interrupt Service routine, Interrupt Flow Handling, Chip-level hardware Encapsulation. 本節描述 Interrupt Flow Handling 的過程， 即， 處理邊沿觸發、水準觸發等等的過程。

1.5.1 設置控制硬體 (Setting Controller Hardware)

內核提供了一些標準函數用於註冊 irq_chips 和設置 flow handlers ，如下：

int  set_irq_chip(unsigned int irq, struct irq_chip *chip);
int set_irq_handler(unsigned int irq, irq_flow_handler_t handle)
int  set_irq_chip_data(unsigned int irq, void *data);
void set_irq_chip_and_handler(unsigned int irq, struct irq_chip *chip,
                              irq_flow_handler_t handle);
void set_irq_chip_and_handler_name(unsigned int irq, struct irq_chip *chip,
                                   irq_flow_handler_t handle, const char *name);

• set_irq_chip: 該函數用於將一個 IRQ Chip (irq_chip 的實例) 與一個特定的中斷相關聯。 除了從 irq_desc 中選擇合適的元素外，該函數還負責設置 chip 中的指標， 並且設置預設的中斷處理函數。
• set_irq_handler 和 set_irq_chained_handler: 為指定的 IRQ 設置 flow handler function， 兩者在內部均使用 __set_irq_handler ， __set_irq_handler 進行一些檢查，並設置 irq_desc[irq]->handle_irq.
• set_chip_and_handler: 一個輔助函數，使用它可以避免逐個的使用前面提到的三個函數。

1.5.2 Flow Handling

前面提到，中斷有不同的觸發方式： edge-trggering 或者 level-triggering， 內核對他們的處理方式有所不同。但相同的是，這兩個處理中，都需要在 flow-handling 完成後負責調用 high-level 的中斷處理函數。

• 邊沿觸發中斷 (Edge-Triggered Interrupts)

邊沿觸發方式在現代的硬體中是最常見的一種方式，該方式的預設處理函數為 handle_edge_irq .

邊沿觸發中斷，在處理時候一般無需禁用該中斷源。這樣，在多處理器系統上，可能會出現這種情況： 一個處理器上正在處理這個Flow-Handnle，此時在這個處理過程尚未完成的時候，又產生了另外一個邊沿觸發的中斷。 對於這種情況， handler_edge_irq 的處理方法是：先更新這個 irq 的 irq_desc 上的狀態為 PENDING， 然後暫時將這個中斷 mask 掉（這裡的 mask 是通過 irq_chip 結構提供的函數在硬體上操作，而不是內核中軟體意義上的 mask）； 而前面負責處理這個 irq 的 CPU ， 在處理完了一個 IRQ 後，檢查這個 irq_desc 的狀態，如果為 PENDING， 則表示在前面的處理過程中又有新的中斷信號產生了，需要繼續處理，直到這個 irq_desc 的狀態不是 PENDING 為止。

在 Flow-Handle 的每個迴圈的結尾， hander_edge_irq 都會以 iqd_desc->action 為參數來通過 handle_IRQevent 調用 High-level 處理函數。

整體流程如下圖所示：

                  handle_edge_irq 流程

• 水準觸發中斷 (Level-Triggered Interrupts)

Level-Triggered Interrups 由函數 handle_level_irq 負責處理，他的流程比 handle_edge_irq 要簡單一些， 如下圖所示：

handle_level_irq 流程

需要注意的是， Level-Triggered Interrups 在處理的時候必須要將其 Mask 掉，這個 Mask 的過程通過函數 mask_ack_irq 來完成。 maks_ack_irq 不但將 irq_desc 的狀態設置為 mask ，同時還調用了 chip->mask_ack 來設置硬體的 mask ， 並向硬體發送 ACK 。 對於多核 CPU 所潛在的競爭冒險¹，可以通過檢測 irq_desc 的狀態來避免 —— 一旦檢測到 irq_desc->status 中包含了 IRQ_INPROGRESS ，則表明該 irq 正在被處理，直接退出即可。

同邊沿觸發的處理一樣，這裡也通過 handle_IRQ_event 來調用了 High-level 的處理函數。

• 其他類型的中斷

除了上述兩種類型的的中斷之外，還有一些其他不常用的中斷，內核為他們提供了默認的 handler 。

• handle_fasteoi_irq

很多現代的 IRQ 硬體僅需要做一點點流處理工作 （Flow-Handle），對他們來講，在 IRQ 處理完畢之後， 只需要調用一個 Chip-specific 的函數： chip->eoi 就可以了， 函數 handle_fasteoi_irq 負責這個工作。

• handle_simple_irq

一些實在是很簡單的中斷根本就不需要流控制，內核為他們提供了 handle_simple_irq 。

• handle_percpu_irq

有些 IRQ 只能發上在 SMP 上的某個指定的 CPU 上，這種 IRQ 被成為 Per-CPU IRQ ， 內核提供了 handle_percpu_irq 來處理他們。該函數負責在中斷處理完成之後向硬體彙報中斷的接收，並調用 EOI 。

1.6 IRQ 的初始化及預留

1.6.1 IRQ 的註冊

函數 request_irq 用於註冊 IRQ ， 其定義為：

static inline int __must_check
request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags,
        const char *name, void *dev)
{
    return request_threaded_irq(irq, handler, NULL, flags, name, dev);
}

可見，該函數是 request_threaded_irq 的一個 wrapper ，並將 request_threaded_irq 的參數 thread_fn 設置為空。 request_threaded_irq 的流程圖如下圖所示：

request_threaded_irq

該函數首先從內核中獲取了這個 irq 對應的 irq_desc， 然後創建 irqaction， 設置這個 action 的 handler, flags, name, 和 dev_id 。 隨後，將其餘的工作交給了函數 __setup_irq， 由 __setup_irq 完後後續的工作。

__setup_irq 的主要作用如下：

• 設置內核熵池

前面提到過，內核通過一系列的事件的相關資訊來生成亂數 （/dev/random），這裡，如果傳入的 flags 中聲明了 IRQF_SAMPLE_RANDOM ，則調用 rand_initialize_irq 將 IRQ 添加到熵池所需的相關資料結構中。

• 添加 irqaction

前面提到，內核有一個全域的 irq_desc Array， 從這個 Array 中可以根據 IRQ Number 來找到相應的 irq_desc ； 此外，每個 irq_desc 中有一個 irqaction list ，這個 list 中記錄了該 irq 中斷發生時候需要調用的每一個 irqaction 。 __setup_irq 需要將傳入的 irqaction 添加到這個 list 的隊尾。

• 其他的 irq flags 檢查

根據傳入參數的flags， 做一些別的檢查和設置，沒具體細看。

• 註冊 proc 檔案系統

__setup_irq 的最後，調用 register_irq_proc ，在 proc/irq 中為相應的 IRQ 創建了節點。 然後又調用 register_handler_proc ， 生成/proc/irq/NUM/NAME 。從而使用戶可以從 procfs 中得到該 IRQ 的信息。

1.6.2 釋放 IRQ

在釋放 IRQ 的時候，僅提供一個 IRQ Number 不行的，還必須提供這個 IRQ 對應的 dev_id. 該過程由函數 free_irq 來完成， free_irq 是 __free_irq 的一個包裝，調 用 __free_irq 來完成 irqaction 的註銷。

__free_irq 根據傳入的 dev_id 從這個 IRQ 的所有 irqaction 上找到設備對應的那個 irqaction ， 並將其從 IRQ 的 irqaction List 中移走； 如果移走的這個 handler 是這個 IRQ Line 上唯一的一個， 那麼還需要將這個 IRQ Line Diable。隨後，清理 proc 檔案系統中的結點， 並將 action 這個結構返回給 free_irq, 由 free_irq 負責將資料結構 free 。

1.6.3 中斷的註冊 (Registering Interrupts, 指系統中斷)

前面提到的 irq_request 僅用於外設的 IRQ 申請， 而對於 CPU 本身已經軟體上的中斷，處理的流程與此不同。 諸如軟體發出的中斷、異常以及陷阱，這些東西的註冊是在系統初始化的時候執行的，並且初始化完成之後，在整個系統的活動週期內不會發生改變。由於系統的中斷是不能共用的（也沒有必要共用，資源多得很），內核所需要做的，僅僅是將中斷號和處理函數相關聯。

一般來講，內核對於這種系統中斷的回應有如下兩種：

• 當錯誤發生的時候，向當前使用者進程發送信號：

例如，在 IA-32 和 AMD64 系統，當一個數位被0除的時候，會產生中斷 0 ， 這個中斷會調用處理函數 divide_error ，並向使用者進程發送信號 —— SIGPFE 。

• 錯誤發生後， 內核自動校正錯誤：

例如 IA-32 系統下， 中斷 14 被用來作為 page fault （記憶體卻頁或者分頁錯誤）的信號，當這個錯誤發生的時候，內核可以自動對該錯誤進行糾正。

Footnotes:

¹ 競爭冒險和前面提到的邊沿觸發中斷的嵌套不同，由於處理 Level-Triggered Interrups 時候， 中斷源那個硬體已經被暫時 Mask 掉，因此在一個水準觸發中斷的處理期間，同一個設備不會產生另外一個水準觸發中斷。 因此，競爭冒險指的是多個 CPU 同時選定要處理同一個 irq 。