本文主要是介绍ALPS04579480 灭屏播放音乐，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
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
- 方法 ：写入一个不释放的锁，查看待机电流和kernel日志
- adb shell echo test > /sys/power/wake_lock
- 测试现象 测试机的电流还是比参考机大，即无法进入 Deep idle 状态
2.2分析deep idle被block的情况
- 看CNT(dpidle,rgidle)，如果dpidle一点没变，说明从没进过deep idle；有变化也不说明一定是正常的，要看变化的量。
- 再看 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 修改策略。
这篇关于ALPS04579480 灭屏播放音乐的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
