mtk通用驱动安装教程介绍;理解mtk开启端口办法

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_onecho 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/shecho "Start monitor power..." > /sdcard/power.txtwhile echo "====================================================================================" >> /sdcard/power.txtdo 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 10done

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

  • 115 views
    A+
发布日期:2021年09月11日 11:00:00  所属分类:知识经验
标签: