前面聊的
最近在调试项目的亮屏速度，我们希望在按下power键后到亮屏这个时间能达到500MS以内，在Rockchip 3399和3288上面的时间都不能达到要求，因此引发了一系列的调试之路。
计算按下power键到亮屏的时间
Android 唤醒时间统计
刚开始的时候，我只在android阶段统计时间，也能看到时间的差异，但是不是最准确的，我统计的时间日志如下
01-18 09:13:40.992 683 772 D SurfaceControl: Excessive delay in setPowerMode(): 743ms
01-18 09:13:45.304 683 772 D SurfaceControl: Excessive delay in setPowerMode(): 757ms
01-18 09:13:49.559 683 772 D SurfaceControl: Excessive delay in setPowerMode(): 725ms
01-18 09:18:27.461 683 772 D SurfaceControl: Excessive delay in setPowerMode(): 741ms
01-18 09:18:32.766 683 772 D SurfaceControl: Excessive delay in setPowerMode(): 743ms
01-18 09:18:35.861 683 772 D SurfaceControl: Excessive delay in setPowerMode(): 745ms
01-18 09:18:38.345 683 772 D SurfaceControl: Excessive delay in setPowerMode(): 733ms
Kernel从Power到亮屏的时间统计
后来同事中的精英古总在他的代码上加入了从按下Power键到亮屏的时间，直接通过printk打印，代码如下
统计每个驱动的resume函数调用时间
上面的时间对我们调试非常有用，然后就需要细分到每个驱动的resume函数执行的时间，用的方法是我之前写过的，大概统计了下TP，LCD，sensor的resume时间，发现TP和LCD占用的时间非常多，然后跟同事一起看了下，同事把TP resume里面的代码用工作队列实现后速度明显有了提升。
然后有很长一段时间不知道干嘛，向打印其他每个驱动的resume时间，一直没找到方法，后面看到一个代码，非常有用。
kernel/drivers/base/power/main.c
这个函数用来打印resume的函数消耗的时间，但是如何去触发打印这个函数呢?
-
一定保证设备进入深度睡眠，串口也进入深度睡眠，没有任何打印后。
-
执行以下命令
打印的LOG类似下面的
[ 37.031413] bcmsdh_sdmmc_resume Exit
[ 37.082174] PM: resume of devices complete after 78.589 msecs
[ 37.085277] [BT_RFKILL]: ** disable irq
[ 37.087645] Restarting tasks ...
修改Lcd配置减小resume时间
古总在调试过程中展现了非常厉害的功底，第一步就是修改了LCD的参数，让亮屏时间加快。修改如下
--- a/arch/arm/boot/dts/rk3288-pad.dts
+++ b/arch/arm/boot/dts/rk3288-pad.dts
@@ -169,10 +169,10 @@
dsi,lanes = <4>;
prepare-delay-ms = <20>;
- init-delay-ms = <20>;
- enable-delay-ms = <100>;
- disable-delay-ms = <20>;
- unprepare-delay-ms = <20>;
+ //init-delay-ms = <20>;
+ enable-delay-ms = <1>;
+ disable-delay-ms = <1>;
+ unprepare-delay-ms = <1>;
panel-init-sequence = [
15 32 02 8F A5
15 01 02 83 00
修改DRM 超时时间减小唤醒时间
这是最关键的，DRM框架非常复杂，RK也是从开源的DRM移植过来使用，在DRM部分有个时间导致问题，最终跟RK拿到最新的patch让唤醒时间直接加速500MS.
我们在日志下发现问题，并给询问了RK，最终发现这部分代码没有更新到最新的部分。
hi rk:
为什么亮屏的时候有时候会打印这句VOP等待超时？请问下这是什么意思。
[ 1211.293492] rockchip-vop ff930000.vop: wait win close timeout
[ 1211.293514] rockchip-vop ff930000.vop: [drm:vop_crtc_enable] Update mode to 1200*1920, close all win
有时候却不会打印。
[ 1216.423283] rockchip-vop ff930000.vop: [drm:vop_crtc_enable] Update mode to 1200
1920, close all win [ 1223.899741] rockchip-vop ff930000.vop: [drm:vop_crtc_enable] Update mode to 1200
1920, close all win
[ 1234.386252] rockchip-vop ff930000.vop: [drm:vop_crtc_enable] Update mode to 1200*1920, close all win
代码如下
修改QOS相关代码
QOS为Quality Of Service（服务质量）的简称，对PM QoS而言，表示Linux kernel电源管理相关的服务质量。那到底什么是服务质量呢？
我们知道，Linux PM的主要功能，是节省功耗，但同时，会付出一定的性能代价，例如延迟（latency）增加、吞吐量（throughput）下降。可以把PM当作一种服务，把它对性能的影响，类比为服务的质量（QoS）。对性能的影响越大，QoS越低，反之越高。
我们可以这么认为，我们在某个时候需要增加代码的执行速度，就通过这个去控制CPU的运行策略，这样确保代码可以快速执行。
不过这个方法没有使用到，如果对某个resume时间不是十分满意，可以尝试这个方法。
休眠唤醒流程图
从网上拷贝了个休眠唤醒的流程图，如果以后有问题需要分析的话，可以跟进这个流程去排查。
参考
