android
的電源管理還是比較簡單的
, 主要就是通過鎖和定時器來切換系統的狀態
,使系統的功耗降至最低
,整個系統的電源管理架構圖如下
: (注該圖來自
steve guo)
static struct platform_driver mxcbl_driver = , };
取乙個例子
加入suspend
和resume
mxc_board_init-->mxc_init_bl()-->platform_device_register()-->platform_device_add()-->device_add()-->device_pm_add()-->
，最終加入到了
dpm_list
的鍊錶中，在其中的
dpm_suspend
和dpm_suspend
中通過遍歷這個鍊錶來進行檢視哪個
device
中包含suspend
和resume
項。系統喚醒和休眠
kernel層[
針對android linux2.6.28
核心]:
其主要**在下列位置:
drivers/base /main.c
kernel/power /main.c
kernel/power/wakelock.c
kernel/power/earlysuspend.c
其對kernel
提供的介面函式有
export_symbol(wake_lock_init); //
初始化suspend lock,
在使用前必須做初始化
export_symbol(wake_lock); //
申請lock,
必須呼叫相應的
unlock
來釋放它
static define_timer(expire_timer, expire_wake_locks, 0, 0);//
定時時間到，加入到
suspend
佇列中；
export_symbol(wake_unlock); //
釋放lock
export_symbol_gpl(device_power_up);//
開啟特殊的裝置
export_symbol_gpl(device_power_down);//
關閉特殊裝置
export_symbol_gpl(device_resume);//
重新儲存裝置的狀態；
export_symbol_gpl(device_suspend);:
儲存系統狀態，並結束掉系統中的裝置；
export_symbol(register_early_suspend); //
註冊early suspend
的驅動export_symbol(unregister_early_suspend); //
取消已經註冊的
early suspend
的驅動函式的流程如下所示：
應用程式通過對
state_store
的寫入操作可以使系統進行休眠的狀態。
pm_states
包括pm_suspend_on
，pm_suspend_standby
，pm_suspend_m
滿足個狀態。當狀態位
pm_suspend_on
的狀態的時候，呼叫
request_suspend_state()
；當滿足休眠的狀態的時候，呼叫
queue_work(suspend_work_queue,&early_suspend_work),
呼叫了early_suspend
，然後在其中通過
wake_unlock()
啟動了expire_timer
定時器，當定時時間到了，則執行
expire_wake_locks
，將suspend_work
加入到佇列中，分析到這裡就可以知道了
early_suspend_work
和suspend_work
這兩個佇列的先後順序了，
suspend
呼叫了pm_suspend
，通過判斷當前的狀態，選擇
enter_state()
，在enter_state
中，經過了
suspend_prepare
，suspend_test
和suspend_device_and_enter()
，在suspend_device_and_enter
中呼叫了
device_suspend
來儲存狀態和結束系統的裝置，到了
dpm_suspend
中結束所有的
device
。到了這裡，我們就又可以看見在初始化的時候所看到的佇列
dpm_list
。android
的電源管理主要是通過
wake lock
來實現的
,在最底層主要是通過如下佇列來實現其管理:
list_head(dpm_list);
系統正常開機後進入到
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
一起使用
,而不是單獨的使用乙個佇列來進行管理.
[參考]http://blog.csdn.net/hzdysymbol/archive/2009/03/04/3956462.aspx
電源管理 電源變動試驗 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裝置,次裝置...
linux電源管理
一 acpid的實驗 1 我在機房的機器上的 etc apci events power.conf中加了 actions bin echo 111111111111 root 1.tmp 2 service acpid restart 3 我按了電源.呵呵，發現了 root 1.tmp 二 etc ...