Android 功耗（4）---MTK平臺待機功耗分析流程

MTK平臺待機功耗分析流程

1.目的

2.MTK平臺各個場景功耗數據測試方法

不少功耗問題都是由於測試手法不對，列出一些經常使用場景功耗測試手法。

測試功耗數據以前，請先確認如下配置：

一、關閉 WIFI/BT/GPS，關閉數據鏈接，設置飛行模式。 （根據具體測試場景設置）

二、關閉 mobile log/modem log/net log，打開LOG會增長電流。注意：確認 /sdcard/mtklog （/data/mtklog） 中是否有 LOG 生成，肯定關閉成功。

三、確認各個模塊是否已經正常工做，各個模塊都會影響功耗，須要在模塊工做 OK 以後再測試功耗問題。

四、測試將全部第三方 APK 刪除，排除第三方 APK 問題。

各場景測試手法：

測試場景 測試方法 備註

飛行模式待機

一、設置飛行模式，關閉WIFI/BT/GPS，關閉數據鏈接

二、關閉mobile log、modem log、net log

三、按power 鍵滅屏，滅屏5分鐘後，開始測試電流，測試時間5 ~ 10分鐘 電流異常須要提供mobile log

四、關閉mobile log、modem log、net log

五、按power 鍵滅屏，滅屏5分鐘後，開始測試電流，測試時間5 ~ 10分鐘 實網待機須要先確認網絡問題及SIM卡問題：

六、用其餘對比機是否有一樣問題

七、同一手機在其餘地點是否有問題

八、其餘SIM卡是否有一樣問題

電流異常須要提供mobile log

雙SIM卡實網待機

單SIM卡實網待機 + 數據鏈接

一、關閉WIFI/BT/GPS

二、關閉mobile log、modem log、net log

三、按power 鍵滅屏，滅屏5分鐘後，開始測試電流，測試時間5 ~ 10分鐘

單SIM卡待機 + WIFI/BT/GPS

一、關閉數據鏈接

二、關閉mobile log、modem log、net log

三、按power 鍵滅屏，滅屏5分鐘後，開始測試電流，測試時間5 ~ 10分鐘

通話電流

一、關閉WIFI/BT/GPS，關閉數據鏈接

二、關閉mobile log、modem log、net log

三、通話後滅屏，等待2分鐘開始測試電流，測試時間5分鐘 電流異常須要提供mobile log

home界面idle電流

一、關閉WIFI/BT/GPS，關閉數據鏈接

二、關閉mobile log、modem log、net log

三、拔掉SIM卡、SD卡

四、保持在home界面，不開任何應用，設置自動滅屏時間爲30分鐘

五、保持默認背光

六、等待5分鐘後開始測試電流，測試時間5~10分鐘 home界面電流和背光、TP、LCM有關，須要先確認去掉背光、TP、LCM電流，請看下一場景

home界面idle + 去掉背光和TP

一、關閉WIFI/BT/GPS，關閉數據鏈接

二、關閉mobile log、modem log、net log

三、拔掉SIM卡、SD卡

四、保持在home界面，不開任何應用，設置自動滅屏時間爲30分鐘

五、拔掉LCM和TP

六、等待5分鐘後開始測試電流，測試時間5~10分鐘 home界面電流異常須要抓CPU信息，請參考FAQ04008，須要同時提供mobile log

FM電流 (耳機模式)

一、關閉WIFI/BT/GPS，關閉數據鏈接

二、關閉mobile log、modem log、net log

三、打開FM後滅屏，等待2分鐘後開始測試電流，測試時間5分鐘 一、FM SPEAKER模式 以及 I2S 通道電流都會偏大，是正常的。

四、FM電流異常須要抓deepidle數據，請參考 FAQ04519，須要同時提供mobile log

BT傳輸數據

一、關閉WIFI/GPS，關閉數據鏈接

二、關閉mobile log、modem log、net log

三、傳輸5M大小文件，滅屏，測試電流

四、BT傳輸電流異常須要抓CPU信息，請參考FAQ04008，須要同時提供mobile log

Audio - MP3 Play back (headset)

一、設置飛行模式

二、關閉mobile log、modem log、net log

三、播放mp3，滅屏，滅屏後等待2分鐘，開始測試電流，測試時間2分鐘

四、播放MP3和SD卡及音頻文件有關，須要換SD卡及音頻文件測試

五、MP3電流異常須要抓deepidle數據，請參考 FAQ04519，須要同時提供mobile log

Video - MP4 (720P) HW mode

一、設置飛行模式

二、關閉mobile log、modem log、net log

三、播放video，播放後等待2分鐘，開始測試電流，測試時間2分鐘

四、播放video電流和背光、TP、LCM有關，須要先確認去掉背光、TP、LCM電流
五、播放video和播放器和視頻文件有關，須要使用默認播放器及MTK提供的視頻文件

六、播放video電流異常須要抓CPU信息，請參考FAQ04008，須要同時提供mobile log

Video - MP4 (1080P) HW mode

Video - H.264 (720P) HW mode

Video - H.264 (1080P) HW mode

Camera - Video Record H264 (720 P)

Camera - Preview (720 P)

一、設置飛行模式

二、關閉mobile log、modem log、net log

三、打開preview，等待2分鐘，開始測試電流，測試時間2分鐘

四、camera電流和拍攝場景及camera相關設置有關，對比測試時請儘可能保持相同拍攝場景以及相同配置。

五、preview電流異常須要抓CPU信息，請參考FAQ04008，須要同時提供mobile log

3.功耗問題分析流程

目前咱們分析的功耗問題主要是待機低電流或者待機平均電流問題。

形成待機底電流偏大緣由基本能夠分爲3類: 各個外設模塊休眠漏電或未休眠，GPIO/subsys/pll/clock口漏電，wakelock致使沒法休眠，modem沒法休眠

關閉飛行模式測試待機底電流，排除是否modem未休眠，首先肯定是AP 仍是modem。

modem暫無系統的分析方法。

下面是AP的分析流程

3.1 外設模塊分析方法

外設模塊分析主要仍是靠硬件上一一移除，而後查看移除哪一個模塊後底電流有降下來，而後肯定到時哪一個模塊漏電 .如休眠時將TP camera LCD 逐一移除來肯定排查。

找到模塊後再取分析代碼來解決。

3.2 GPIO/SUBSYS/PLL/CLOCK分析方法

AP suspend狀態下，會由於GPIO配置不當，subsys/pll/clock沒關，或者其餘的緣由形成26M沒關，而致使底電流升高；

這種狀況，能夠從kernel log中找到一些端倪，以肯定進一步分析的方向

【3.2.1】查找沒有關閉的SUBSYS/CLOCK/PLL

[6589/6582/6592/6595/6795]
查找關鍵字「PWR_STATUS」，[7:0]對應每一個bit對應一個subsys
若是bit爲1，表明這個子系統沒關

echo 1 > /sys/module/mt_sleep/parameters/slp_ck26m_on
echo 1 > /sys/module/mt_sleep/parameters/slp_dump_regs

每一個bit的定義能夠看mt_spm_mtcmos.c

好比：#define MD1_PWR_STA_MASK （0x1 << 0）

[6732/6752/6735/6753]
查找關鍵字「slp_check_pm_mtcmos_pll」
若是有子系統沒關，下一行能夠看到相似下面的信息：
[Power/clkmgr] SYS_AUD: on

而後再往下看，就是各子系統的dump信息，以aud子系統爲例，找到SYS_AUD對應的部分，詳細解釋以下：
cnt不等於0表示這個clock沒關
後面每個括號內（可能有多個）是這個clock的其中一個user的信息
「audio」是使用clock的user的名字，代碼裏傳入的參數
「15」表示open clock的次數，
「14」表示close clock的次數，二者不同的話說明「audio」這個user使用這個clock有問題

[06][CG_AUDIO]* 
[02]state=1, cnt=1 (AUDIO,15,14) 
[08]state=0, cnt=0 (AUDIO,8,8) 
[09]state=0, cnt=0 (AUDIO,8,8) 
[18]state=0, cnt=0 (AUDIO,8,8) 
[19]state=0, cnt=0 (AUDIO,8,8)

【3.2.2】查看GPIO的狀態

默認是關閉的，須要用下面的命令打開

echo 1 > /sys/module/mt_sleep/parameters/slp_dump_gpio

而後在kernel log裏就能夠看到相似下面的信息：
PIN: [MODE] [PULL_SEL] [DIN] [DOUT] [PULL EN] [DIR] [IES]

對一下正常更異常的狀況就會有幫助

重點關注[mode][DIR][PULL_SEL]，其餘欄位的狀態即便改變不少狀況下也是正常的

有些平臺自己這塊代碼是註釋掉的，須要更改代碼才能夠，搜索slp_dump_gpio能夠找到相關代碼

【3.2.3】查看26M CLOCK是否關閉

搜索關鍵字「debug_flag」，跟wake up by在同一行，
bit[3:2]能夠顯示26M有沒有關閉過，

若是bit[3:2]=0b’11，說明sleep時26M正常關閉；

若是bit[3:2]=0b’00，說明sleep時26M一直沒關；

• 若是發生這種case，須要case by case去看
• 另外，若是前面是wake up by GPU，請忽略這行log信息（deepdile狀態，不是suspend狀態）

3.3 WAKELOCK 分析

Kernel或者system持有wakelock會致使系統沒法進入深度休眠，直接致使待機底電流偏高

【STEP1-找KERNEL層和USER層的WAKELOCK】

使用命令，查看kernel或者上層的wakelock

cat /proc/wakelock 
dumpsys power`

相關weaklock都會被打印出來

【STEP2-找USER層的WAKESOURCE】

中間層申請的weaklock不會再上面顯示，必須使用命令去查看weaksource的腳本去抓取這兩種信息，腳本源碼以下：

#!/system/bin/sh
echo "Start monitor power..." > /sdcard/power.txt
while echo "====================================================================================" >> /sdcard/power.txt
do
    date >> /sdcard/power.txt
    echo "**********dumpsys power**********" >> /sdcard/power.txt
    dumpsys power | cat >> /sdcard/power.txt
    echo "" >> /sdcard/power.txt
    echo "**********cat /sys/kernel/debug/wakeup_sources**********" >> /sdcard/power.txt
    cat /sys/kernel/debug/wakeup_sources >> /sdcard/power.txt
    echo "" >> /sdcard/power.txt
    sleep 10
done

4.FAQ

[FAQ09542][POWER]待機電流問題，如何查找WAKELOCK

【使用說明】

(1) 如下是列出的整個按鍵喚醒的log關鍵點，每條都有粗體字說明其含義以及該注意的關鍵字；

(2) 紅色的是kernel log，其餘都是main log；

(3) 一條一條依次檢查，直到若是發現某條log找不到，那問題就出在這個地方；

(4) 僅限於JB2以後的Android版本，JB2以前流程相對比較簡單；

kernel-Check Point【1】：按鍵中斷

<5>[ 78.721504] 1)[Power/PMIC] [pwrkey_int_handler] Press pwrkey 
——————————————————————————————————————————————————– Check Point【2】：上層收到按鍵事件 01-09 03:37:40.102 513 561 D 
WindowManager: interceptKeyTq keycode=26 
——————————————————————————————————————————————————– Check Point【3】：PMS的wakeUp被調用 01-09 03:37:40.171 513 531 D 
PowerManager_performance: wakeUpNoUpdateLocked: eventTime=78826 
——————————————————————————————————————————————————– Check Point【4】：發出MSG_BROADCAST 01-09 03:37:40.171 513 531 D 
PowerManagerNotifier: onWakeUpStarted 
——————————————————————————————————————————————————– Check Point【5】：發出第一個MSG_UPDATE_POWER_STATE 01-09 03:37:40.174 513 
531 D PowerManagerDisplayController: sendMessage 
——————————————————————————————————————————————————– Check Point【6】：收到並處理MSG_BROADCAST，而且狀態是從2變到1 01-09 03:37:40.194 513 
530 D PowerManagerNotifier: sendNextBroadcast, 
mBroadcastedPowerState=2, mActualPowerState=1 
——————————————————————————————————————————————————– Check Point【7】：開始繪製keyguard的流程，發出NOTIFY_SCREEN_ON，等windowToken 01-09 
03:37:40.217 513 530 D KeyguardViewMediator: notifyScreenOnLocked 
——————————————————————————————————————————————————– Check Point【8】：收到並處理NOTIFY_SCREEN_ON 01-09 03:37:40.224 513 531 D 
KeyguardViewMediator: handleNotifyScreenOn 
——————————————————————————————————————————————————– Check Point【9】：完成繪製keyguard，拿到windowToken 01-09 03:37:40.370 513 
531 I WindowManager: Lock screen displayed 
——————————————————————————————————————————————————– Check Point【10】：調用回調函數mSceenOnListener，解除Screen on 
Blocker，mNestCount必須是0 01-09 03:37:40.371 513 531 D 
PowerManagerService: Screen on unblocked: mNestCount=0 
——————————————————————————————————————————————————– Check Point【11】：處理第一個MSG_UPDATE_POWER_STATE，這裏會第一次scheduleScreenUpdate 
01-09 03:37:40.254 513 546 D PowerManagerDisplayState: 
setScreenOn: on=true 
——————————————————————————————————————————————————– Check Point【12】：第一次執行scheduleScreenUpdate，進入setState 01-09 
03:37:40.330 513 546 D PowerManagerDisplayState: Requesting new 
screen state: on=true, backlight=0 
Check Point【13】：發出第二個MSG_UPDATE_POWER_STATE 01-09 03:37:40.334 513 546 D PowerManagerDisplayController: sendMessage. 
——————————————————————————————————————————————————– Check Point【14】：第一次執行mTask， on跟onChanged 必須都是true 01-09 03:37:40.334 
513 546 D PowerManagerDisplayState: mTask: on = true, onChanged = 
true, backlightChanged = false 
——————————————————————————————————————————————————– kernel-Check Point【15】：進入unblankAllDisplays，開始底層late_resume流程 01-09 
03:37:40.334 513 546 D PowerManagerService: unblankAllDisplays in 
… 
——————————————————————————————————————————————————– Check Point【16】：底層late_resume流程結束 01-09 03:37:40.673 513 546 D 
PowerManagerService-JNI: Excessive delay in autosuspend_disable() 
while turning screen on: 337ms 
——————————————————————————————————————————————————– Check Point【17】：unblankAllDisplays流程結束 01-09 03:37:40.701 513 546 
D PowerManager_performance: unblankAllDisplays out … 
——————————————————————————————————————————————————– Check Point【18】：處理第二個MSG_UPDATE_POWER_STATE 01-09 03:37:40.702 513 
546 D PowerManagerDisplayController: setScreenOn true 
——————————————————————————————————————————————————– Check Point【19】：前面的Screen On Blocker被解除，纔會調用這裏 01-09 03:37:40.702 
513 546 D PowerManagerDisplayController: Unblocked screen on after 
447 ms 
——————————————————————————————————————————————————– Check 
Point【20】：設置ElectronBeamLevel，值不爲0才能點亮背光，而且這裏會第二次scheduleScreenUpdate 
01-09 03:37:40.704 513 546 D PowerManagerDisplayState: 
setElectronBeamLevel: level=1.0 
——————————————————————————————————————————————————– Check Point【21】：第二次執行scheduleScreenUpdate，進入setState，注意backlight值不爲0 
01-09 03:37:40.718 513 546 D PowerManagerDisplayState: Requesting 
new screen state: on=true, backlight=86, 
——————————————————————————————————————————————————– Check Point【22】：第二次執行mTask，backlightChanged必須是true 01-09 03:37:40.721 
513 546 D PowerManagerDisplayState: mTask: on = true, onChanged = 
false, backlightChanged = true 
——————————————————————————————————————————————————– Check Point【23】：調用light service，寫backlight節點，light 0表示backlight 01-09 
03:37:40.721 513 546 D LightsService: setLight_native: light=0, 
colorARGB=0xff565656, flashMode=0, 
——————————————————————————————————————————————————– kernel-Check Point【24】：驅動底層背光生效 <4>[ 79.447236] 
(1)[546:PowerManagerSer]mt65xx_leds_set_cust: set brightness, 
name:lcd-backlight, mode:6, level:86 
[FAQ11906][LTE功耗]6582/92與6290鏈接的UART IO漏電

[DESCRIPTION]

現象：fly mode下會有幾mA的漏電，並且很是大的可能關閉fly mode底電流反而會降一些；若是能斷開6290/65X2之間的UART連線，能夠看到電流恢復正常

緣由：fly mode模式下，正常的話，6339/6290是沒有電的，所以6290上的UART電平狀態就會是低電平；若是AP側跟6290鏈接的UART 配置是高電平就會引發漏電。

注意：6582+6290跟6592+6290的狀況有所不一樣，兩種項目均可能產生這個問題，可是具體的錯誤點不同，緣由是6582 UART代碼中在關閉modem時會去切換GPIO的pull狀態爲pull enable / pull low，而6592沒有這段代碼；所以6582+6290須要關注的是dws中UART pin的var Name必定要配，不然軟件就不會有動做；而6592+6290要關注的不只是var Name，還有前面的pull設定

[SOLUTION]

解決方案：
Release出去的配置都是對的，只是客戶有可能根據以往的經驗把UART配置成pull enable / pull high，就可能產生問題，若是真的出現這個問題，那麼請按照如下方式正確配置UART：

特別注意：硬件原理圖上的UART2對應的是dws中的UART3，千萬不要錯位

[FAQ11917][LTE功耗] 實網待機功耗測試注意AUTO MODE的影響

【問題類型1】————————————————————————————-

現象：連CMU500，4G待機電流200mA+，一直下不來，4G實網下反而正常

緣由：CMU500的儀器默認配置了 「keep RRC connection」，會致使modem一直處於工做狀態
注意：8820C 默認沒有開這個配置，因此沒問題

解決方案：
去掉儀器上「keep RRC connection」的選項，若是不知道怎麼作，請聯繫儀器廠商

【問題類型2】————————————————————————————-

現象：連儀器， 4G待機電流70mA+，一直下不來，4G實網下反而正常

Kernel log中能夠很規律地看到固定每隔10s或者7s左右被EINT 7（LTE）喚醒
緣由：沒有勾選「DRX disconnect」

解決方案： 勾選「 RX disconnect」，若是不知道怎麼作，請聯繫儀器廠商