cpu进入suspend过程中fw的逻辑

cpu能不能挂起，即cpu进入suspend状态一个很明显的现象就是很多的一段时间bugreport没有log输出，在此前一小段时间内在kernel里面也能看到PM:  suspend相关的log，在此之后cpu就完全进入suspend状态了，所有的进程也拿不到cpu相关的资源，进而被冻结。

那cpu是如何会被挂起，哪种场景下会被挂起的呢？我们先来看下cpu挂起的对android来说意味什么。大家最本能的反应是系统里面没有wake_lock的锁，那我们首先就来看下wake_lock和进suspend的关系。

如果有任何wake_lock变化，最终都将通过PowerMS的updatePowerStateLocked方法更新dirty相关的最终到updateSuspendBlockerLocked里面，这个就是计算出是否要suspend状态。

 

先说下这方法调用完成之后会最终调用的方法：

  setHalAutoSuspendModeLocked()

->nativeSetAutoSuspend()

->enableAutoSuspend()

           -> disableAutoSuspend()

acquire()

->nativeAcquireSuspendBlocker()

-> acquire_wake_lock()

从这个方法的逻辑和这两个调用逻辑来看，将手机唤醒，是先通过setHalAutoSuspendModeLocked方法将cpu从suspend退出，然后再通过acquire将锁写到底层去以保证cpu是suspend状态。

那这个是什么情况下会唤醒cpu什么情况下会让cpu进入suspend的，我们可以看下这些方法里面的控制逻辑和控制变量这个方法最里面涉及的变量分别为needWakeLockSuspendBlocker，这个可以明显的看出来看是否有wakelock锁，needDisplaySuspendBlocker和autoSuspend 其实都是一个由needDisplaySuspendBlockerLocked()这个方法决定的，另一个是用于input交互的变量，这里就不做过多的描述，也很简单。

也就是说这个最主要的方法是needDisplaySuspendBlockerLocked()方法。

这里大家重点主要下由于mDisplayReady是亮屏变化过程中经常改变的变量，所以正常亮灭屏的情况下这个变量决定了。

其他的几种if情况大家也能猜到都是什么，如第二个是psensor使能不能进suspend状态这里就不一一介绍了。结合这些场景也应该想的到上面的哪些return的情况都不能进suspend

   这里再给大家分享下亮屏和灭屏的时候分别是如何从suspend退出或者进入suspend的。

  正常亮屏流程： 因为mDisplayReady = false正在亮屏，所以第一次为false的时候， autospend必须为false，通过updateSuspendBlockerLocked方法从suspend退出的，即mHalAutoSuspendModeEnabled 为false。

这个是正常流程从逻辑上来讲也很好理解，不做过多的解释。

此过程的相关Log如下：

 

正常灭屏流程：和亮屏流程一样，只不过这个时候cpu的状态为suspend即mHalAutoSuspendModeEnabled在这个流程的初始状态为false，当要灭屏的时候虽然mDisplayReady = false，但到fw中去设置cpu

状态的setHalAutoSuspendModeLocked（）方法enable为false，mHalAutoSuspendModeEnabled变量也为false，这个时候cpu的状态保存不变，即还是非suspend状态，这个从逻辑上也是说的过去的，毕竟还有很多事情没有做完，

还不能挂起。

   那灭屏的时候哪里应该挂起呢？灭屏流程走完的时候会有会将mDisplayReady 变成true，但这个时候还是不能进suspend，因为还要判断是否要进doze，这个时候needDisplaySuspendBlockerLocked();方法里面的第四个大if会返回true，等判断完成之后，这个时候mDisplayReady也为true了，其他因素也考虑完成了，就到setHalAutoSuspendModeLocked方法里面将cpu挂起即mHalAutoSuspendModeEnabled为true了。这个从流程上来讲也是说的过去的，要做事情cpu就不能挂起。

对应的log如下：

转存失败重新上传取消