当前位置：首页 > article >正文

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

article 2024/12/24 16:46:59

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 ];

## 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)