kernel層:
其主要**在下列位置:
drivers/android/power.c
其對kernel提供的介面函式有
export_symbol(android_init_suspend_lock); //初始化suspend lock,在使用前必須做初始化
export_symbol(android_uninit_suspend_lock); //釋放suspend lock相關的資源
export_symbol(android_lock_suspend); //申請lock,必須呼叫相應的unlock來釋放它
export_symbol(android_lock_suspend_auto_expire);//申請partial wakelock, 定時時間到後會自動釋放
export_symbol(android_unlock_suspend); //釋放lock
export_symbol(android_power_wakeup); //喚醒系統到on
export_symbol(android_register_early_suspend); //註冊early suspend的驅動
export_symbol(android_unregister_early_suspend); //取消已經註冊的early suspend的驅動
提供給android framework層的proc檔案如下:
"/sys/android_power/acquire_partial_wake_lock" //申請partial wake lock
"/sys/android_power/acquire_full_wake_lock" //申請full wake lock
"/sys/android_power/release_wake_lock" //釋放相應的wake lock
"/sys/android_power/request_state" //請求改變系統狀態,進standby和回到wakeup兩種狀態
"/sys/android_power/state" //指示當前系統的狀態
android的電源管理主要是通過wake lock來實現的,在最底層主要是通過如下三個佇列來實現其管理:
static list_head(g_inactive_locks);
static list_head(g_active_partial_wake_locks);
static list_head(g_active_full_wake_locks);
所有初始化後的lock都會被插入到g_inactive_locks的佇列中,而當前活動的partial wake lock都會被插入到g_active_partial_wake_locks佇列中, 活動的full wake lock被插入到g_active_full_wake_locks佇列中, 所有的partial wake lock 和full wake lock在過期後或unlock後都會被移到inactive的佇列,等待下次的呼叫.
在kernel層使用wake lock步驟如下:
1. 呼叫函式android_init_suspend_lock初始化乙個wake lock
2. 呼叫相關申請lock的函式android_lock_suspend 或 android_lock_suspend_auto_expire請求lock,這裡只能申請partial wake lock, 如果要申請full wake lock,則需要呼叫函式android_lock_partial_suspend_auto_expire(該函式沒有export出來),這個命名有點奇怪,不要跟前面的android_lock_suspend_auto_expire搞混了.
3. 如果是auto expire的wake lock則可以忽略,不然則必須及時的把相關的wake lock釋放掉,否則會造成系統長期執行在高功耗的狀態.
4. 在驅動解除安裝或不再使用wake lock時請記住及時的呼叫android_uninit_suspend_lock釋放資源.
系統的狀態:
user_awake, //full on status
user_notification, //early suspended driver but cpu keep on
user_sleep // cpu enter sleep mode
其狀態切換示意圖如下:
系統正常開機後進入到awake狀態, backlight會從最亮慢慢調節到使用者設定的亮度,系統screen off timer(settings->sound & display-> display settings -> screen timeout)開始計時,在計時時間到之前,如果有任何的activity事件發生,如touch click, keyboard pressed等事件, 則將reset screen off timer, 系統保持在awake狀態. 如果有應用程式在這段時間內申請了full wake lock,那麼系統也將保持在awake狀態, 除非使用者按下power key. 在awake狀態下如果電池電量低或者是用ac供電screen off timer時間到並且選中keep screen on while pluged in選項,backlight會被強制調節到dim的狀態.
如果screen off timer時間到並且沒有full wake lock或者使用者按了power key,那麼系統狀態將被切換到notification,並且呼叫所有已經註冊的g_early_suspend_handlers函式, 通常會把lcd和backlight驅動註冊成early suspend型別,如有需要也可以把別的驅動註冊成early suspend, 這樣就會在第一階段被關閉. 接下來系統會判斷是否有partial wake lock acquired, 如果有則等待其釋放, 在等待的過程中如果有user activity事件發生,系統則馬上回到awake狀態;如果沒有partial wake lock acquired, 則系統會馬上呼叫函式pm_suspend關閉其它相關的驅動, 讓cpu進入休眠狀態.
系統在sleep狀態時如果檢測到任何乙個wakeup source, 則cpu會從sleep狀態被喚醒,並且呼叫相關的驅動的resume函式,接下來馬上呼叫前期註冊的early suspend驅動的resume函式,最後系統狀態回到awake狀態.這裡有個問題就是所有註冊過early suspend的函式在進suspend的第一階段被呼叫可以理解,但是在resume的時候, linux會先呼叫所有驅動的resume函式,而此時再呼叫前期註冊的early suspend驅動的resume函式有什麼意義呢?個人覺得android的這個early suspend和late resume函式應該結合linux下面的suspend和resume一起使用,而不是單獨的使用乙個佇列來進行管理.
android的電源管理
1.裝置的電源管理struct dev pm ops 在struct bus type,struct dev type,struct class,struct devic driver中包含有次結 構體對於rumtime，會一次檢查dev type,class,bus type,呼叫其中rumtim...
電源管理 電源變動試驗 CRANKING
需求描述 主機廠一般要求做emc試驗 如掉電試驗 時產品不能復位。比如da跑android系統，重啟的話需要20s左右 比如tbox cranking時候復位了，重啟約要1min 期間不能正常使用，影響使用者體驗。解決辦法 法1 很多情況下都是硬體計算好儲能電容，保證產品掉電後還能給mcu 4g w...
arm電源管理
由於arm系統中沒有bios裝置,所以只能為arm系統建立乙個虛擬的字元裝置與使用者空間進行通訊.這就是 arch arm kernel amp.c 1.工作原理 這個apm中實現乙個misc裝置,實質上也是乙個字元裝置,misc裝置的主裝置號是10,而apm bios作為一 個misc裝置,次裝置...