MTK平台待機功耗分析流程
1.目的
2.MTK平台各個場景功耗數據測試方法
很多功耗問題都是因為測試手法不對，列出一些常用場景功耗測試手法。
測試功耗數據之前，請先確認以下配置：
1、關閉 WIFI/BT/GPS，關閉數據連接，設置飛行模式。 （根據具體測試場景設置）
2、關閉 mobile log/modem log/net log，打開LOG會增加電流。注意：確認 /sdcard/mtklog （/data/mtklog） 中是否有 LOG 生成，確定關閉成功。
3、確認各個模塊是否已經正常工作，各個模塊都會影響功耗，需要在模塊工作 OK 之后再測試功耗問題。
4、測試將所有第三方 APK 刪除，排除第三方 APK 問題。
各場景測試手法：
測試場景 測試方法 備注
飛行模式待機
1、設置飛行模式，關閉WIFI/BT/GPS，關閉數據連接
2、關閉mobile log、modem log、net log
3、按power 鍵滅屏，滅屏5分鍾后，開始測試電流，測試時間5 ~ 10分鍾 電流異常需要提供mobile log
4、關閉mobile log、modem log、net log
5、按power 鍵滅屏，滅屏5分鍾后，開始測試電流，測試時間5 ~ 10分鍾 實網待機需要先確認網絡問題及SIM卡問題：
6、用其他對比機是否有同樣問題
7、同一手機在其他地點是否有問題
8、其他SIM卡是否有同樣問題
電流異常需要提供mobile log
雙SIM卡實網待機
單SIM卡實網待機 + 數據連接
1、關閉WIFI/BT/GPS
2、關閉mobile log、modem log、net log
3、按power 鍵滅屏，滅屏5分鍾后，開始測試電流，測試時間5 ~ 10分鍾
單SIM卡待機 + WIFI/BT/GPS
1、關閉數據連接
2、關閉mobile log、modem log、net log
3、按power 鍵滅屏，滅屏5分鍾后，開始測試電流，測試時間5 ~ 10分鍾
通話電流
1、關閉WIFI/BT/GPS，關閉數據連接
2、關閉mobile log、modem log、net log
3、通話后滅屏，等待2分鍾開始測試電流，測試時間5分鍾 電流異常需要提供mobile log
home界面idle電流
1、關閉WIFI/BT/GPS，關閉數據連接
2、關閉mobile log、modem log、net log
3、拔掉SIM卡、SD卡
4、保持在home界面，不開任何應用，設置自動滅屏時間為30分鍾
5、保持默認背光
6、等待5分鍾后開始測試電流，測試時間5~10分鍾 home界面電流和背光、TP、LCM有關，需要先確認去掉背光、TP、LCM電流，請看下一場景
home界面idle + 去掉背光和TP
1、關閉WIFI/BT/GPS，關閉數據連接
2、關閉mobile log、modem log、net log
3、拔掉SIM卡、SD卡
4、保持在home界面，不開任何應用，設置自動滅屏時間為30分鍾
5、拔掉LCM和TP
6、等待5分鍾后開始測試電流，測試時間5~10分鍾 home界面電流異常需要抓CPU信息，請參考FAQ04008，需要同時提供mobile log
FM電流 (耳機模式)
1、關閉WIFI/BT/GPS，關閉數據連接
2、關閉mobile log、modem log、net log
3、打開FM后滅屏，等待2分鍾后開始測試電流，測試時間5分鍾 1、FM SPEAKER模式 以及 I2S 通道電流都會偏大，是正常的。
4、FM電流異常需要抓deepidle數據，請參考 FAQ04519，需要同時提供mobile log
BT傳輸數據
1、關閉WIFI/GPS，關閉數據連接
2、關閉mobile log、modem log、net log
3、傳輸5M大小文件，滅屏，測試電流
4、BT傳輸電流異常需要抓CPU信息，請參考FAQ04008，需要同時提供mobile log
Audio - MP3 Play back (headset)
1、設置飛行模式
2、關閉mobile log、modem log、net log
3、播放mp3，滅屏，滅屏后等待2分鍾，開始測試電流，測試時間2分鍾
4、播放MP3和SD卡及音頻文件有關，需要換SD卡及音頻文件測試
5、MP3電流異常需要抓deepidle數據，請參考 FAQ04519，需要同時提供mobile log
Video - MP4 (720P) HW mode
1、設置飛行模式
2、關閉mobile log、modem log、net log
3、播放video，播放后等待2分鍾，開始測試電流，測試時間2分鍾
4、播放video電流和背光、TP、LCM有關，需要先確認去掉背光、TP、LCM電流
5、播放video和播放器和視頻文件有關，需要使用默認播放器及MTK提供的視頻文件
6、播放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)
1、設置飛行模式
2、關閉mobile log、modem log、net log
3、打開preview，等待2分鍾，開始測試電流，測試時間2分鍾
4、camera電流和拍攝場景及camera相關設置有關，對比測試時請盡量保持相同拍攝場景以及相同配置。
5、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”，如果不知道怎么做，請聯系儀器廠商