功耗优化之Sensor功耗分析

• 一、Sensor功耗问题分类
• 二、Sensor功耗问题分析方法
• * SSC子系统引起系统无法进入AOSD问题分析：
  • SSC子系统频繁唤醒AP问题分析方法
  • SSC子系统的GPIO/PMIC配置错误导致系统漏电问题分析方法
  • SSC子系统的sensor工作模式异常，导致系统功耗增大问题分析方法

一、Sensor功耗问题分类

目前所遇到的sensor功耗问题主要包括以下几类:
待机功耗：

• SSC子系统异常，导致系统无法进入AOSD
• SSC子系统异常，导致频繁唤醒AP
• SSC子系统的GPIO/PMIC配置错误，导致系统存在漏电

运行功耗：

• SSC子系统的sensor工作模式异常，导致系统功耗增大
• Android上层服务未正常关闭sensorservice，导致系统功耗增大

在sensor功耗问题的分析中，sensor自身工作行为所产生的耗电是非常小的，大多数功耗问题都是由SSC（Snapdragon Sensor Core）子系统异常或是Android上层服务异常调用sensorservice引起。

二、Sensor功耗问题分析方法

不同类型的sensor功耗问题有不同的分析方法，以下是一些通用的针对各类型sensor功耗问题的分析.

1.首先要确认系统待机时的是否是SSC子系统无法进入sleep而导致系统无法进入AOSD，可通过以下命令查看各个子系统的sleep count：
命令:

adb shell cat /sys/power/rpmh_stats/master_stats

输出如下:

APSS
Version:0x1
Sleep Count:0x2bf90
Sleep Last Entered At:0x48e7ec7af00
Sleep Last Exited At:0x48e7ecfe85e
Sleep Accumulated Duration:0x42b29deb96a


ADSP
Version:0x1
Sleep Count:0xf17
Sleep Last Entered At:0x48a16986465
Sleep Last Exited At:0x48a16980931
Sleep Accumulated Duration:0x487a6e075f7


CDSP
Version:0x1
Sleep Count:0x55
Sleep Last Entered At:0x1f39e3aadeb
Sleep Last Exited At:0x1f39e3a6d3b
Sleep Accumulated Duration:0x48e5fed220c


SLPI
Version:0x1
Sleep Count:0x1e341a
Sleep Last Entered At:0x48e7ed80b48
Sleep Last Exited At:0x48e7ed76c90
Sleep Accumulated Duration:0x473b8551197

其中子系统每进入sleep一次，相应的sleep count就会+1，如果某个subsystem的sleep count长时间没有增加，基本可断定该子系统无法进入sleep

2.接下来确认是否为sensor的使用导致SSC子系统异常，可用以下方法disable AP子系统与SSC子系统的通信来确认：
命令:

adb shell mv /vendor/lib64/libssc.so /vendor/lib64/libssc.so.bk
adb shell mv /vendor/lib/libssc.so /vendor/lib/libssc.so.bk
adb shell sync
adb reboot

3.若确认SSC异常与sensor使用无关，则请sensor team帮忙分析SSC无法进入LPM的原因
4.若确认SSC异常与sensor使用有关，则用如下命令确认系统灭屏时有哪些sensor正在被使用
命令:

adb shell dumpsys sensorservice

5.逐一关闭灭屏时正在使用的sensor，来找出引起SSC异常的sensor
6.关闭引起SSC异常的sensor，并使用如下命令验证该异常是SSC子系统自身引起，还是上层的sensor服务引起：

adb shell
自研校准 -d <simple_time_ms> <SensorName> &        //校准的工具的使用

7.将结果反馈给sensor team进行进一步分析

1.分析待机时的bugreport日志，通过以下log确认SSC子系统存在多次唤醒AP：

All wakeup reasons:
Wakeup reason Abort:Last active Wakeup Source: SensorService_wakelock, handle processSensorService: 16m 50s 349ms (1025 times)
realtime
Wakeup reason Abort:Wakeup IRQ detected during suspend: 103qcom,glink-smem-native-xprt-dsps: 2m 7s 108ms (126 times) realtime

2.确认是否为sensor的使用导致SSC子系统异常，可用以下方法disable AP子系统与SSC子系统的通信来确认：
命令:

adb shell mv /vendor/lib64/libssc.so/vendor/lib64/libssc.so.bk
adb shell mv /vendor/lib/libssc.so/vendor/lib/libssc.so.bk
adb shell sync
adb reboot

3.若AP频繁唤醒是由sensor使用引起的，则通过以下命令找出系统灭屏时正在使用的sensor，并通过排除法来确定引起AP唤醒的sensor
命令:

adb shell dumpsys sensorservice

4.检查是否为上层服务将sensor错误配置成了Wakeup模式，导致AP不断被唤醒，如：

Connection Number: 4
Operating Mode: NORMAL
com.qualcomm.qti.internal.telephony.DynamicSarController | WakeLockRefCount 0 | uid 1001 | cache size 0 | max cache size 0
sar_detector Non-wakeup 0x0000001e | status: active | pending flush events 0
SAR ADUX1050 Wakeup0x00000025 | status: active | pending flush events 0
Hall Effect Sensor 0x00000034 | status: active | pending flush events 0

在以上log中，由于modem服务将SAR sensor异常设置成了Wakeup模式，导致SAR sensor每隔1s就会频繁唤醒AP

5.若上层服务的sensor配置没有问题，但系统还是存在频繁的AP唤醒，就需要sensor team检查是否为SSC子系统在使用sensor时出现异常，导致AP频繁唤醒。

如：之前遇到的安装微信及QQ后，系统会频繁上报SSC中断，导致AP无法睡眠，经分析是由于微信及QQ同时使用了Non-wakeup pedometer，导致大量sensor中断产生。 但其本质原因是由于SensorHub问题导致Non-wakeup sensor会异常唤醒AP。

1.分析GPIO/PMIC的漏电问题是在系统已经成功进入AOSD以后，此时各个子系统都已成功进入sleep，故很难从各subsystem看出问题

2.这时最简单的办法就是通过Trace32来dump系统进入AOSD之前的GPIO/PMIC状态，检查各GPIO/PMIC是否存在漏电

3.但有时由于条件所限在无法使用Trace32工具的情况下，就需要对比出问题前后的两个版本，从regression的角度来找出漏电

1.sensor的工作模式异常导致的功耗问题主要出现在系统运行时，指可以使用interrupt mode的sensor被SSC子系统异常配置成了polling mode，导致功耗增大

2.分析方法主要是先通过dumpsys sensorservice找出系统使用了哪些sensor？再检查哪些sensor可以被配置成interrupt mode

3.若确认相应sensor可以工作在interrupt mode，却异常配成了polling mode，则找sensor team帮忙修正