如何通过从kernel log分析AP suspend状态下的异常漏电

[DESCRIPTION]

 

 AP suspend状态下，会因为GPIO配置不当，subsys/pll/clock没关，或者其他的原因造成26M没关，而导致底电流升高；

 

这种情况，可以从kernel log中找到一些端倪，以确定进一步分析的方向

 

 

[SOLUTION]

 

【1】查找没有关闭的subsys/clock/pll

[6589/6582/6592/6595/6795]

查找关键字“PWR_STATUS”，[7:0]对应每个bit对应一个subsys

如果bit为1，代表这个子系统没关

 

每个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)

 

【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】查看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状态）