android的電源管理

2021-06-09 16:12:46 字數 4454 閱讀 9424

1.裝置的電源管理struct dev_pm_ops

在struct bus_type,struct dev_type,struct class,struct devic_driver中包含有次結

構體對於rumtime,會一次檢查dev_type,class,bus_type,呼叫其中rumtime相關函式,一般是

最中呼叫到device_driver中的pm管理函式,從而進行硬體的runtime,device_driver一般

是device-specific的

如果struct device 中pm_domain 不為null,則優先呼叫其中的ops

2.__pm_runtime_set_status()設裝置的狀態,只有當裝置disable和出錯時才能改變其狀

態3.只有當裝置的usage_count為0時,裝置才能被suspend和idle

4.echo "mem" > /sys/power/state 螢幕變黑

echo "on"  > /sys/power/state 螢幕變亮

5.核心中的early suspend 執行:

在suspend的時候先執行優先等級低的handler,在resume的時候則先執行等級高的

handler

6.彙總:

linux的電源管理有兩種情況,system sleep pm ,和runtime pm,前者是針對系統中的所有

裝置而runtime是針對某種裝置,但最終的callback都在dev_pm_ops中定義,乙個裝置在系統

中用struct device 結構體表示,struct device中的dev_pm_ops的操作優先順序是:

pm_domain->pm_ops,dev_type->pm_ops,class->pm_ops,bus->pm_ops。這些介面都是在系

統進入深度休眠是才會呼叫.

android在linux kernel的基礎上增加了一種休眠,叫early suspend,進行淺度休眠,在手機

系統中,關閉lcd背光,tp等裝置來降低功耗,通過向/sys/power/state中寫「mem"就會進入淺

度休眠,寫」on",則退出淺度休眠,android讓裝置也能夠進入深度休眠,另外再增加了一種

wake_lock(醒鎖)的機制,當系統中不存在wake_lock的持有者時,系統將進入深度休眠階段,

此時就會呼叫device->pm_ops中的相關函式。

6.1 pm core init:

kernel/kernel/power/main.c

pm_init:

1.建立了乙個pm_wq工作佇列用於runtime時的電源管理

2.在/sys/目錄下建立了乙個power目錄,用於使用者空間的互動

3.在/sys/power目錄建立屬性檔案,其中最重要的是state檔案

其他有:

pm_async:設定裝置進行suspend時是同步執行還是非同步執行

wakeup_count:對系統中wakeup 事件進行統計

touch_event:功能暫不明確

//kernel/kernel/power/userwakelock.c中定義

wake_lock:從使用者空間申請wake lock

wake_unlock:從使用者空間釋放wake lock

wakelock core init:

kernel/kernel/power/wakelock.c

wakelocks_init:

1.主要申請了deleted_wake,main_wake,unknown_wake,suspend_backoff_wake等suspend類

型的wake_lock(wake_lock有兩種型別,suspend和idle,前者防止裝置進入休眠,或者防止設

備進入idle)

2.建立了suspend ,sync工作佇列用於進行early suspend 和同步

3.以及建立/proc/wake_lock目錄

6.2: early suspend 和late resume 分析

/kernel/kernel/power/earlysuspend.c

struct early_suspend ;

在kernel中用early_suspend_handlers去維護驅動註冊的early suspend

驅動呼叫register_early_suspend去註冊用於suspend和resume的callback

在使用者空間對/sys/power/state進行操作是會呼叫state_store函式

進而呼叫request_suspend_state函式進入early suspend流程,根據使用者空間傳遞進來的

state(mem,on,standy)進行操作,對於suspend呼叫suspend_work_queue上的early_suspend

函式,對於resume呼叫late_resume函式去執行掛起或者恢復。在suspend以後會釋放醒鎖

main_wake_lock(wake_unlock(&main_wake_lock)),在resuem時wake_lock

(&main_wake_lock)

6.3:wake_lock的實現

android在linux的基礎上增加了醒鎖,當系統中沒有醒鎖時就會進入深度睡眠,只要系統中

還存在乙個suspend型別的wake lock,那麼整個系統就不能進入深度休眠(這設計....)

系統在初始化時註冊了幾個主要的系統wake lock。而驅動程式可以通過以下api註冊醒鎖

wake_lock_init()

wake_lock()

在wake_unlock時,如果系統中已經不存在suspend型別的鎖,則會呼叫suspend_work上的

suspend函式進入深度休眠流程.

suspend->pm_suspend(休眠時,次函式不會返回,返回了說明已經resume完成了)最終

pm_suspend呼叫enter_state進入深度休眠。

enter_state主要呼叫的兩個函式:

suspend_prepare()//休眠前的準備,凍結程序。

suspend_devices_and_enter()//進入休眠,會呼叫到系統中所有device的

suspend_prepare,suspend,suspend_noirq函式

系統中維護在四個鍊錶,代表著電源管理的各個階段

list_head(dpm_list);//還沒有進行suspend,裝置執行正常

list_head(dpm_prepared_list);//prepared 的所有裝置

list_head(dpm_suspended_list); //suspend的所有裝置

list_head(dpm_noirq_list); //noirq階段

6.4 device與pm建立聯絡的過程

系統中的device是通過linux裝置模型(device model),與電源管理建立聯絡的

在呼叫device_register()裝置時分別呼叫了

device_initialize

device_add

在device_initialize中呼叫device_pm_init去初始化乙個device的電源管理相關項

在device_add中呼叫device_pm_add把device新增到pm_list鍊錶中,從而進行電源管理

6.5runtime 分析

/kernel/driver/base/power/runtime.c

runtime的callback也在pm_ops中,

主要涉及到rpm_suspend,rpm_resume,rpm_idle,定時器suspend_timer,和工作佇列

pm_wq,pm_wq用於非同步執行裝置的suspend和resuem

api 使用:

首先要執行下面的兩個函式,才能啟動裝置的runtime管理

pm_runtime_set_active(struct device *dev)

pm_runtime_enable(struct device *dev)

//如果裝置的使用計數不為0,那麼這個兩個函式立即返回,同步執行

pm_runtime_idle(struct device)//使裝置進入idle模式

pm_runtime_suspend(struct device)//是裝置進入suspend模式

pm_runtime_resume(struct device) //立即使裝置進入resume模式

int pm_request_idle(struct device )//非同步進入idle模式

int pm_request_resume(struct device)//非同步進入resuem模式

int pm_runtime_get(struct device)//非同步進入resuem模式,且增加引用計數

int pm_runtime_get_sync(struct device)//同步進入resume模式,且增加引用計數

Android電源管理 Healthd 2

adb shell進入到 sys class power supply目錄,我們可以看到power supply驅動建立的一些執行時檔案 我的裝置是nuxus 7,android 4.4.2,kernel 3.4.0 1adb root 2adb shell 3cd sys class power ...

電源管理 電源變動試驗 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裝置,次裝置...