[转]功耗分析-判断 suspend 是否成功

本文主要是介绍[转]功耗分析-判断 suspend 是否成功，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

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信号。