MTK 驱动开发（35）---待机功耗分析流程

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 
单SIM卡实网待机 1、关闭WIFI/BT/GPS，关闭数据连接 
2、关闭mobile log、modem log、net log 
3、按power 键灭屏，灭屏5分钟后，开始测试电流，测试时间5 ~ 10分钟 实网待机需要先确认网络问题及SIM卡问题： 
1、用其他对比机是否有同样问题 
2、同一手机在其他地点是否有问题 
3、其他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分钟 
4、保持默认背光 
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 通道电流都会偏大，是正常的。 
2、FM电流异常需要抓deepidle数据，请参考 FAQ04519，需要同时提供mobile log 
BT传输数据 1、关闭WIFI/GPS，关闭数据连接 
2、关闭mobile log、modem log、net log 
3、传输5M大小文件，灭屏，测试电流 1、BT传输电流异常需要抓CPU信息，请参考FAQ04008，需要同时提供mobile log 
Audio - MP3 Play back (headset) 1、设置飞行模式 
2、关闭mobile log、modem log、net log 
3、播放mp3，灭屏，灭屏后等待2分钟，开始测试电流，测试时间2分钟 1、播放MP3和SD卡及音频文件有关，需要换SD卡及音频文件测试 
2、MP3电流异常需要抓deepidle数据，请参考 FAQ04519，需要同时提供mobile log 
Video - MP4 (720P) HW mode 1、设置飞行模式 
2、关闭mobile log、modem log、net log 
3、播放video，播放后等待2分钟，开始测试电流，测试时间2分钟 1、播放video电流和背光、TP、LCM有关，需要先确认去掉背光、TP、LCM电流 
2、播放video和播放器和视频文件有关，需要使用默认播放器及MTK提供的视频文件 
3、播放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分钟 1、camera电流和拍摄场景及camera相关设置有关，对比测试时请尽量保持相同拍摄场景以及相同配置。 
2、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

• 1
• 2

每个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不会再上面显示，必须使用命令去查看weaksou 
的脚本去抓取这两种信息，脚本源码如下：

#!/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

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14

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”，如果不知道怎么做，请联系仪器厂商