1. 背景
在suspend状态(sleep mode)下,我们最关心的是系统底电流。SPM掌控着CPU suspend之后系统能否掉到最小电流的关键逻辑,你可以把它理解成一个投票机制,当系统的关键资源(memeory、clock)没有任何人使用的时候,它就会让系统进入一个真正的深睡状态(最小电流)。只要它检测到有任何资源请求还没有释放,系统就无法降到底电流。所以在底电流问题上的debug流程中,我们不仅仅要看CPU有没有suspend成功,还要看SPM的状态是否正确。
2. 查SPM的状态是否正确
2.1 关于 SPM
SPM = System Power Manager
因为整个系统不只是AP(MCU),还包括modem、connectivity等子系统;CPU进入WFI(wait for interrupt状态)后,整个系统就依靠一颗SCP:SPM来控制睡眠/唤醒的流程,它回去关注各个子系统的状态。跟SPM强相关的一个东西就是系统中的时钟请求信号,也就是26M时钟开关的控制逻辑:
2.2 查看 SPM的状态
看SPM的状态只需要看wake up by 、r13 和 debug_flag 关键字
<4>[ 923.097349] -(0)[1180:system_server][SPM] wake up byEINT, timer_out = 7440931, r13 = 0x10001000, debug_flag = 0x9f
这两个寄存器保留了SPM管理时钟的关键信号状态,寄存器的detail信息不对客户开发。
判断是否正常一般就只要看debug_flag的最后4个bit,如果是0xf(1111)就是正常的,如果是类似0Xc(1100)或者0x3(0011)这种的就是不正常的。
一般就只有这三种值,因为每2个bit是成对的,它们意味着26M有没有被打开/关闭过,1表示发生过,0表示没有。因为如果26M被关了,唤醒前必须打开,因此要么都是0(26M没有打开/关闭过),要么都是1(26M打开/关闭过),0就是不正常的。
如果发现debug_flag不是0xf,那么要看r13,r13是保存了每个输入SPM的时钟请求信号状态,这种状态下一定是有某个时钟请求信号是hold住了。因此可以简单地把r13理解是SPM的输入,而debug_flag是SPM输出SRCLKENA信号。
3. 结语
不同平台不同系统版本,上述log不一定有完整打印。故本分只是作为经验参考