Deep ilde 现象分析

1. 功耗现象

灭屏情况下，飞行模式+静音模式+插耳，播放音乐，电流异常

1.1 测试数据

飞行模式+静音模式+插耳机	原生音乐播放器
DriverOnly	32.5mA
User版本	45mA

1.2 电流波形现象

上述看怀疑 CPU 未进入 Deep idle 导致？

2. Deep idle 分析

Deep idle是一种CPU进入空闲后的状态，也就是在idle进程执行的。简单地说，MTK会在CPU进入空闲的情况下，再去关闭一些不必要的power domain，以达到最省电的目的。通俗的理解就是CPU的空闲状态，即 CPU0 单核运行，其他CPUX不运行，即处于关核状态

2.1 是否能进 Deep idle

1. 方法 ：写入一个不释放的锁，查看待机电流和kernel日志

• adb shell “echo test > /sys/power/wake_lock”

2. 测试现象
   测试机的电流还是比参考机大，即无法进入 Deep idle 状态

2.2 分析 deep idle被block的情况

1. 看CNT(dpidle,rgidle)，如果dpidle一点没变，说明从没进过deep idle；有变化也不说明一定是正常的，要看变化的量。
2. 再看 dpidle_block_cnt 这一组数值的增加值，一般可以看到每个blocker的计数都有所增加，关键要看哪个是主要的：

• 如果主要是cpu，说明系统不只一颗cpu在运行，检查cpu loading；
• 如果主要是tmr，说明有任务繁忙，调度比较频繁，检查cpu loading；
• 如果主要是clk，那么看dpidle_block_mask，bit不为0的clk id就是嫌疑对象。

以下是 Kernel 日志 灭屏时间段为 13:39:57 ~ 14:17:31

<6>[  187.391041]  (0)[180:wdtk-0][thread:180][RT:187391030060] 2019-06-06 13:39:59.895301 UTC;android time 2019-06-06 13:39:59.895301

<4>[  187.524049] -(0)[0:swapper/0][Power/swap]CNT(dpidle,rgidle): [0] = (0,252679), [1] = (0,43671), [2] = (0,36229), [3] = (0,30398), 

<4>[  187.524068] -(0)[0:swapper/0][Power/swap]dpidle_block_cnt: [by_cpu] = 43533, [by_clk] = 17433, [by_tmr] = 0, [by_oth] = 0, [by_vtg] = 0, [by_frm] = 0, 

<4>[  187.524089] -(0)[0:swapper/0][Power/swap]dpidle_block_mask: 0x00000000, 0x00000000, 0x00000000, 0x00000011, 0x00000000, 0x00000010, 0x00002c03, 0x0000000c, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 

根据上述日志发现导致无法进入Deep idle原因是
dpidle_block_cnt: [by_cpu] 为主，CPU loading大导致，如何查cpu loading具体情况？这里的CPU loading信息我们需要抓Ftrace文件进行分析

3. Ftrace分析

抓取日志见其他博客的 Ftrace 抓取方法，可以使用本文的sh脚本

#!/system/bin/sh
rm -rf /sdcard/idle_log/*
mkdir /sdcard/idle_log;
i=0;
while [ i -le 3000 ];

do

## cat $i;
echo $i >> /sdcard/idle_log/dpidle_state.txt;
echo $i >> /sdcard/idle_log/soidle_state.txt;
echo $i >> /sdcard/idle_log/idle_state.txt;
echo $i >> /sdcard/idle_log/cpu.txt;

i=$(($i+1));

## print looping counts
cat /sys/kernel/debug/cpuidle/dpidle_state  >>/sdcard/idle_log/dpidle_state.txt;
cat /sys/kernel/debug/cpuidle/soidle_state  >>/sdcard/idle_log/soidle_state.txt;
cat /sys/kernel/debug/cpuidle/idle_state >> /sdcard/idle_log/idle_state.txt;
## cat /sys/devices/system/cpu/cpufreq/all_time_in_state >> /sdcard/idle_log/cpu.txt
echo cpu_online_info >> /sdcard/idle_log/cpu.txt;
cat /sys/devices/system/cpu/online >> /sdcard/idle_log/cpu.txt;
## cat /sys/devices/system/cpu/cpu0/online >> /sdcard/idle_log/cpu.txt;
cat /sys/devices/system/cpu/cpu1/online >> /sdcard/idle_log/cpu.txt;
cat /sys/devices/system/cpu/cpu2/online >> /sdcard/idle_log/cpu.txt;
cat /sys/devices/system/cpu/cpu3/online >> /sdcard/idle_log/cpu.txt;

##busybox usleep 2000000;
sleep 2;

done

查看 Ftrace 分析结果，在Google浏览器输入下述调试网址，即可加载Ftrace文件

• chrome://tracing/

综合上述不管是使用Ftrace 还是使用脚本工具，都检查到灭屏情况，功耗异常的机器无法进入Deep idle状态，且cpu loading 大，且2个CPU运行，由于这个问题是4.28号的修改导致，即内部改出来的问题，是否CPU策略变更？

4. CPU的实验测试

做一个 Disable CPU hotplug 实验

adb shell "echo 0 > /proc/hps/enabled"

关闭 CPU hotplug，机器电流恢复正常了

5. 查看CPU相关修改记录

• git diff e7a305d576a44042c8fa4f36c57b1a4e9ebdf515 961171a11857523e1296b6ba572cbbc55582d73e

发现确实存在 CPU_hotplug 相关的修改记录

user@chuanghangren-Lenovo-Product:/local/sda/local_sourcecode/xxx/kernel-4.9-lc$ git diff e7a305d576a44042c8fa4f36c57b1a4e9ebdf515 961171a11857523e1296b6ba572cbbc55582d73e
diff --git a/drivers/misc/mediatek/include/mt-plat/mt_hotplug_strategy_internal.h b/drivers/misc/mediatek/include/mt-plat/mt_hotplug_strategy_internal.h
index b250cca..bad7a20 100755
--- a/drivers/misc/mediatek/include/mt-plat/mt_hotplug_strategy_internal.h
+++ b/drivers/misc/mediatek/include/mt-plat/mt_hotplug_strategy_internal.h
@@ -22,7 +22,7 @@
 
 /* CONFIG - compile time */
 #define HPS_TASK_PRIORITY              (MAX_RT_PRIO - 3)
-#define HPS_TIMER_INTERVAL_MS          100
+#define HPS_TIMER_INTERVAL_MS          20
 
 #define HPS_PERIODICAL_BY_WAIT_QUEUE        (1)
 #define HPS_PERIODICAL_BY_TIMER             (2)
@@ -35,17 +35,17 @@
 #define CPU_DMIPS_BIG_LITTLE_DIFF      70
 
 /* CONFIG - runtime (execute time interval : 100 ms */
-#define DEF_CPU_UP_THRESHOLD           95
-#define DEF_CPU_UP_TIMES               2
-#define DEF_CPU_DOWN_THRESHOLD         85
-#define DEF_CPU_DOWN_TIMES             8
+#define DEF_CPU_UP_THRESHOLD           75
+#define DEF_CPU_UP_TIMES               1
+#define DEF_CPU_DOWN_THRESHOLD         30
+#define DEF_CPU_DOWN_TIMES             50
 #define DEF_TLP_TIMES                  1
 
 #define EN_CPU_INPUT_BOOST             1
 #define DEF_CPU_INPUT_BOOST_CPU_NUM    2
 
 #define EN_CPU_RUSH_BOOST              1
-#define DEF_CPU_RUSH_BOOST_THRESHOLD   98
+#define DEF_CPU_RUSH_BOOST_THRESHOLD   80
 #define DEF_CPU_RUSH_BOOST_TIMES       1
 
 #define EN_HPS_LOG                     1

查看具体修改原因：产品需要dEQP-EGL
CTS测试，就必须和入此patch，不然会导致CTS fail。这块芯片比较久了，性能不太好，需要尽量的去开核 确保perfect

CPU hotplug 的patch会导致dEQP-EGL
CTS fail。具体如下：
[Initial condition]
1. [gms]_alps-mp-p0.mp user
2. Select stay awake
3. Lock screen select none
4. connect WiFi AP

[Steps]
1. run cts in windows
2. input “run cts -m CtsDeqpTestCases -t dEQP-EGL.functional.get_frame_timestamps*"

[Actual Result]
dEQP-EGL.functional.get_frame_timestamps#rgb565_depth_no_stencil fail === with config {glformat=rgba8888d24s8ms0,rotation=unspecified,surfacetype=window,required=true} === Fail: Buffer displayed before rendering completed.!(1292160634076 < -2) 
dEQP-EGL.functional.get_frame_timestamps#rgb565_depth_stencil fail === with config {glformat=rgba8888d24s8ms0,rotation=unspecified,surfacetype=window,required=true} === Fail: Composite to present latency is more than 3 vsyncs.!(57889844 < 49642383) 
dEQP-EGL.functional.get_frame_timestamps#rgb888_depth_stencil fail === with config {glformat=rgba8888d24s8ms0,rotation=unspecified,surfacetype=window,required=true} === Fail: Composite to present latency is more than 3 vsyncs.!(57920384 < 49665288) 
dEQP-EGL.functional.get_frame_timestamps#rgb888_no_depth_no_stencil fail === with config {glformat=rgba8888d24s8ms0,rotation=unspecified,surfacetype=window,required=true} === Fail: Buffer displayed before rendering completed.!(1305430597769 < -2) 
dEQP-EGL.functional.get_frame_timestamps#rgba8888_depth_no_stencil fail === with config {glformat=rgba8888d24s8ms0,rotation=unspecified,surfacetype=window,required=true} === Fail: Composite to present latency is more than 3 vsyncs.!(57916176 < 49662132) 
dEQP-EGL.functional.get_frame_timestamps#rgba8888_depth_stencil fail === with config {glformat=rgba8888d24s8ms0,rotation=unspecified,surfacetype=window,required=true} === Fail: Composite to present latency is more than 3 vsyncs.!(57910252 < 49657689) 
dEQP-EGL.functional.get_frame_timestamps#rgba8888_no_depth_no_stencil fail === with config {glformat=rgba8888d24s8ms0,rotation=unspecified,surfacetype=window,required=true} === Fail: Composite to present latency is more than 3 vsyncs.!(57910944 < 49658208) 

基于产品需求定义，需确保 CTS 测试通过，故维持该 CPU hotplug 修改策略。