各種“擠牙膏式” 優化android 功耗

1、底電流調試（Rock Bottom Current Optimization）

底電流在手機飛行模式下調試。每個平臺的底電流數據可能不一樣，具體可以參考release出來相關平臺的Current Consumption Data文檔或者release note。
每個平臺的底電流都不一樣，一般情況下的底電流參考數據上限是：
512M RAM < 1.5mA; 1G RAM < 2mA; 2G RAM < 2.6mA

另，DDR多一個G，底電流一般會多高0.5mA，因爲待機時DDR內存都維持電源保持容性。

下面操作沒有步驟順序性！只是相關點！

1.1 校準硬件參數

保證RF的PA、Antenna switch、Tuner、APT、GPIO工作在正常狀態。
另，高通平臺板子先要燒寫QCN後modem才能休眠。

1.2 排除無關影響

開啓飛行模式、關閉GPS、關閉自動旋轉屏幕、關閉自動亮度調節、關閉其他特效效果設置。

• 開啓飛行模式，可以基本避免藍牙、wifi、NFC、網絡、FM等的一般影響；
• 關閉GPS，可以基本排除開啓GPS對底電流的影響；
• 關閉自動旋轉屏幕，可以基本排除sensor的影響；
• 關閉自動亮度調節，可以基本排除距離感應到的影響；
• 關閉其他特效效果設置，如指紋識別、黑屏手勢、智能體感、手勢隔空操作。。。。。。

1.3 使用perf_defconfig

修改device/qcom/<TARGET>/AndroidBoard.mk。如果KERNEL_DEFCONFIG := <TARGET>_defconfig，那麼改成KERNEL_DEFCONFIG := <TARGET>-perf_defconfig

同時，kernel代碼改用/kernel/arch/arm/configs/-perf_defconfig

<TARGET>是平臺名稱或者項目名稱

1.4 移除debugging APKs

/system/app/Logkit.apk
/system/app/com.qualcomm.qlogcat.apk
/system/xbin/qlogd

1.5 把應用盡量刪除

在設置–>應用，禁用正在運行的應用

1.6 去掉CPU佔用高的進程

adb shell
top

查看CPU佔用，去掉在休眠模式下CPU佔用大於0的進程。kill掉該進程，若kill不掉則rm掉相關應用。對於佔用CPU高的kwork，需要查找驅動原因。

1.7 手動移除所有可以移除的外設

手機連上安捷倫電源，手機開機，然後讓手機進入待機狀態。手動移除TP、LCM、前camera、後camera、sensor、SD卡、SIM卡等可以手動移除的外圍器件，同時觀察並記錄底電流變化。

直接移除WLAN芯片可能會導致開不了機，所以在移除WLAN之前，先對軟件做如下處理：

# mount -o rw,remount -t vfat /dev/block/bootdevice/by-name/modem 
# cd /firmware/image 
# rm wcnss.* 
# reboot 

或者

# lsmod
# rmmod WLAN

移除其他可以移除的芯片（sensor、NFC。。。）

1.8 移除驅動模塊

在/kernel/arch/arm/configs/-perf_defconfig中把sensor、TP、LCM、camera等的驅動模塊移除；
或者在對應驅動的Makefile裏面，移除驅動代碼，然後編譯bootimage，燒入手機觀察底電流變化

1.9 配置不用的GPIO

將不用的GPIO置爲輸入、拉低；配置成SPI、I2C的GPIO，若不用，置爲懸空。
在boot_images/core/systemdrivers/tlmm/config/platform/TLMMChipset.xml，修改GPIO配置。該處配置GPIO的初始狀態，驅動有可能會修改GPIO。
對比項目原理圖與平臺參考原理圖，項目原理圖中多出的NC GPIO要處理掉。

1.10 檢查power相關的NV items

需要跟CE確認。一般如下：

1027 = 0
1895 = 0
1892 = 0
1962 = 0
4679 = 16
4201 = 0
3851 = 0
3852 = 6
7157 = 1
69745 rxd_enable = 0
WCDMA NV:
NV3581 = 0
NV3852 = 6

1.11 排查GPIO、LDO、總線

對比項目原理圖與平臺參考原理圖，排查硬件不一樣的GPIO、LDO、總線配置。
量測各GPIO、LDO、I2C在休眠時候的電壓，需用萬用表準確測量。
休眠時各路I2C GPIO的電壓是多少v，用萬用表準確測量。
如果條件允許，測量所有LDO在休眠前和休眠後的準確電壓。

對於LDO，調試方法如下：

（1）adb shell關閉LDO

如關閉L3：

cd /sys/kernel/debug/regulator/8916_l3/
echo 0 > enable

（2）LDO太多設備用到，不適合用adb shell來關。可以這樣調試：

cat /sys/kernel/debug/regulator/8916_l6/consumers 
shell@msm8916_32:/sys/kernel/debug/regulator/8916_l6 $ cat consumers 
Device-Supply EN Min_uV Max_uV load_uA 
0-000c-vio Y 1800000 1800000 0 
0-0068-vi2c N 1800000 1800000 0 
5-0038-vcc_i2c Y 1800000 1800000 0 
1a98000.qcom,mdss_dsi-vddio N 1800000 1800000 100 
1a98300.qcom,mdss_dsi_pll-vddio N 1800000 1800000 100 
8916_l6 N 0 0 0 

這樣就可以看到是哪些設備請求了LDO6。然後 找到對應的代碼，在休眠時關掉LDO，喚醒時再打開。

0-000c: 掛在I2C0上地址爲0xc 
5-0038: 掛在I2C0上地址爲0x38 

查看這兩個設備的驅動代碼是否有執行regulator_enable。

（3）通過寄存器地址關閉LDO

如LDO6的地址是0x14546，則關閉方法是：

# cd /sys/kernel/debug/spmi/spmi-0 
# echo 0x14546 > address 
# echo 1 > count 
# cat data 可以讀寄存器 
# echo 0x00 > data 關LDO6

（4）關閉MPP

在休眠前關閉MPP1、MPP2、MPP3、MPP4 。

如PM8916的寄存器地址分別是0xA046、0xA146、0xA246、0xA346

在關閉前先cat data以查看原來的值。

GPIO狀態讀取的方法如下：

（1）GPIO dump

爲了得到休眠時的GPIO狀態，增加下面的打印（最新平臺dump gpio代碼有差異，具體請提case）:

rpm_proc/core/power/sleep/src/lpr_definition_uber.c

#include "tlmm_hwio.h" 

void deep_sleep_enter(void) 
{ 
uint64 sleep_duration; 
... 

SWEVENT(SLEEP_DEEP_SLEEP_ENTER_COMPLETE, sleep_mode.deep_sleep_mode, sleep_duration); 

// For test 
{ 

int num; 
int i=11;/*LCM_I2C_SCL, GPIO_11*/ 
volatile uint32 cfg ,inout, val; 

num = 122; //8916 only. Need modify for 8974/8x10/8x26 etc. 

cfg = *(volatile uint32*)HWIO_TLMM_GPIO_CFGn_ADDR(i); //(0x61000000 + i * 0x1000) 
inout = *(volatile uint32*)HWIO_TLMM_GPIO_IN_OUTn_ADDR(i);//(0x61000004 + i * 0x1000) 
val = ((cfg << 16)&0xffff0000) | (inout&0xffff); 
SWEVENT(SLEEP_GPIO_DUMP, i, val); 

} 

mpm_sw_done(sleep_mode.deep_sleep_mode, sleep_duration); 

} while(FALSE); 

} 

增加for test下面這一段代碼。

然後再修改:

rpm_proc\core\power\sleep\build\SConscript

if 'USES_QDSS_SWE' in env: 
QDSS_IMG = ['QDSS_EN_IMG'] 
events = [['SLEEP_DEEP_SLEEP_ENTER=320','deep sleep enter. (sleep mode: %d) (count: %d)'], 
	['SLEEP_DEEP_SLEEP_EXIT','deep sleep exit (sleep mode: %d)'], 
	['SLEEP_NO_DEEP_SLEEP','bail early from deep sleep. (sleep mode: %d) (reason: %d)'], 
	['SLEEP_RPM_HALT_ENTER','rpm halt enter'], 
	['SLEEP_RPM_HALT_EXIT','rpm halt exit'], 
	['SLEEP_MPM_INTS','pending mpm interrupts at wakeup: (interrupt_status_1 %d), (interrupt_status_2 %d)'], 
	['SLEEP_DEEP_SLEEP_ENTER_COMPLETE','deep sleep exit complete (sleep mode: %d)'], 
	['SLEEP_DEEP_SLEEP_EXIT_COMPLETE','deep sleep exit (sleep mode: %d)'], 
	['SLEEP_MPM_WAKEUP_TIME','mpm wake up time (wakeup time: 0x%0.8x%0.8x)'], 
	['SLEEP_GPIO_DUMP','gpio [%d] configuration is %d'],
	['SLEEP_EVENT_LAST=383','sleep last event placeholder'] 

增加SLEEP_GPIO_DUMP這一項。

編譯燒寫rpm.mbn。

讓機器休眠，進入download，抓dump，然後將如下日誌發給平臺技術支持分析。

CODERAM.bin 
MSGRAM.bin 
DATARAM.bin 

以及新編譯出來的RPM_AAAAANAZR.elf。

（2）GPIO寄存器讀取

在RPM可能不是很方便，也可以用busybox來讀取寄存器，例如讀GPIO11：

Physical Address for GPIO_CFG11 = 0x100B000 
root@Android:/data/busybox # ./busybox devmem 0x100B000 32 
./busybox devmem 0x100B000 32 
0x00000203 

GPIO_PULL = "11" PULL_UP 
FUNC_SEL = "0000" FUNCTION GPIO 
DRV_STRENGTH = "000" DRV_2_MA 
GPIO_OE = "1" Output Enable 

1.12 rpm dump

抓rpm dump，然後把log提供給平臺技術支持。

方法如下：

（1）ps_hold接地

在休眠狀態下，接ps_hold到地少於200mS，機器會進入緊急下載狀態，插入USB，QPST會自動得到memory dump，然後上傳以下幾個文件：

CODERAM.bin 
MSGRAM.bin
DATARAM.bin 

以及RPM_AAAAANAZR.elf（必須與機器的編譯時間一致匹配的elf)

（2）改reset爲download key

發這些命令改reset爲download key:

# cd /sys/kernel/debug/spmi/spmi-0 
# echo 0x844 > address 
# echo 4 > count 
# cat data 

00840 -- -- -- -- 0F 07 04 00 

# echo 0x00 0x00 0x01 0x00 > data 
# cat data 

00840 -- -- -- -- 00 00 01 00 

# echo 0x00 0x00 0x01 0x80 > data 
# cat data 

00840 -- -- -- -- 00 00 01 80 

然後長按下鍵，會進入download。之後抓取log方法同上。

如果進不了download，需要確認：

CONFIG_MSM_DLOAD_MODE=y 

另外也有可能與nv 4399和905有關係。

1.13 檢查rpm_stats

檢查rpm_stats是否進入vdd min或者xo/no shutdown。使用下面的命令檢查rpm lower power mode count:

cat /sys/kernel/debug/rpm_stats

如果vmin的count是0，則表明設備從來沒有進入vdd min；non-zero則說明設備進入過vdd_min。

RPM Mode: xosd
count:0
time in last mode(msec):0
time since last mode(sec):794
actual last sleep(msec):0

RPM Mode:vmin
count:11
time in last mode(msec):0
time since last mode(sec):359
actual last sleep(msec):110000

1.14 使用Trace32

可以dump出來完整詳細的gpio/clk/pmic信息，排除休眠時候的狀態異常。

2、待機電流優化（Standby Current Optimization）

2.1 通過adb log排查

adb logcat -v time > YearMounthDayHourMinute_logcat.txt   //main log
adb logcat -v time -b events > YearMounthDayHourMinute_logcat_event.txt   //event log
adb logcat -v time -b radio > YearMounthDayHourMinute_logcat_radio.txt    //radio log
adb shell dmesg > YearMounthDayHourMinute_dmesg.txt                 //kernel log

可以採用功耗問題時間追蹤表來精確追蹤功耗異常。
可以使用如下命令來打開指定文件的kernel log（以qpnp-adc-tm.c和qpnp-adc-common.c爲例）：

adb shell mount -t debugfs none /sys/kernel/debug
adb shell "echo 8 > /proc/sys/kernel/printk" 
adb shell "echo 'file qpnp-adc-tm.c +p' > /sys/kernel/debug/dynamic_debug/control"
adb shell "echo 'file qpnp-adc-common.c +p' > /sys/kernel/debug/dynamic_debug/control"
adb shell "echo 8 > /proc/sys/kernel/printk" 

爲指定的函數開啓log，以qpnpint_handle_irq爲例：

adb shell "echo 'func qpnpint_handle_irq +p' > /sys/kernel/debug/dynamic_debug/control" 

*#logkit#*調出logkit apk，可以保存logcat、dmesg、crash、QXDM、GPU log等日誌信息到手機裏面。

2.2 top

通過top命令，可以查詢到cpu佔用較高的應用。如果一個應用一直在佔用cpu，而此時並沒有打開該應用，那麼該應用很可能會導致待機異常。

adb shell
top

“該場景下CPU使用率”是User+System+IOW+IRQ
“模塊相關的CPU佔用率”是模塊相關進程佔用CPU使用率的總和

2.3 正在運行APP

設置–>應用–>正在運行，可以看到正在運行的應用或者服務。禁止掉應用或者服務，觀察待機電流變化。

2.4 wakeup debug mask

調試wakeup問題，可以使能debug功能，然後抓取log。Log中會增加一些debug信息。

mount -t debugfs none /sys/kernel/debug  
echo 1 > /sys/kernel/debug/clk/debug_suspend  
echo 1 > /sys/module/msm_show_resume_irq/parameters/debug_mask  
echo 4 > /sys/module/wakelock/parameters/debug_mask  
echo 1 > /sys/module/lpm_levels/parameters/debug_mask  
echo 0x16 > /sys/module/smd/parameters/debug_mask  

2.5 wakelock

1、wakeup_sources

kernel wakelock和userspace wakelock都有可能阻止系統睡眠。所有的wakeup_sources均保存在sys節點/sys/kernel/debug/wakeup_sources裏面。

該文件包含了如下信息：

（1）the total amount of time a wakeup source has prevented suspend
（2）the amount of time a wakelock has been active since the last activation etc. The unit of time is milliseconds.

2、active_since

active_since值可以用來確認wakelock是否正在阻止休眠。如果該值不是零，那麼這個wakelock正在工作並且阻止休眠。

3、獲取wakeup_sources的命令

adb root 67754400
adb remount
adb shell 
cat /sys/kernel/debug/wakeup_sources > /data/wakeup_sources.txt
adb pull /data/wakeup_sources.txt

獲得wakeup_sources.txt以後，通過Excel打開，active_since不爲0的項爲wakeup source。以表2爲例，msm_dwc3對應的active-since值481756>0，這意味着msm_dwc3驅動在阻止系統睡眠，下一步需要檢查msm_dwc3驅動代碼及相關log。

表格 2 Wakeup source opened in Excel

4、power:wakeup_source_activate and power:wakeup_source_deactivate events

當一個wakeup source被acquire或者release時候，power:wakeup_source_activate和power:wakeup_source_deactivate event將隨即被寫到trace buffer裏面，這樣可以記錄wakeup source被driver使用的頻率。

開啓該功能的方法：

echo "power:wakeup_source_activate power:wakeup_source_deactivate" > /sys/kernel/debug/tracing/set_event

The power:wakeup_source_activate and power:wakeup_source_deactivate events are written to the trace buffer any time a wakeup source is acquired or released and it can provide information on how often a wakeup source is being used by a driver.

To enable these events, you can enable following:

echo "power:wakeup_source_activate power:wakeup_source_deactivate" > /sys/kernel/debug/tracing/set_event 

Once the above done, the traces will be present in /sys/kernel/debug/tracing/trace.

5、PowerManagerService.WakeLocks

如果PowerManagerService.WakeLocks的 active_since 時間很長，可以dumpsys power 查看上層具體哪個鎖沒有釋放

2.6 powertop

powertop用來看CPU的運行統計以協助調試power問題。powertop的用法如下：

powertop --h
Usage: powertop [OPTION...]
n -d, --dump read wakeups once and print list of top offenders
n -t, --time=DOUBLE default time to gather data in seconds
n -r, --reset Reset PM stats data
n -h, --help Show this help message
n -v, --version Show version information and exit

獲取powertop log的方法：

1. 通過USB連接手機到電腦
2. adb shell，然後執行如下命令：
sleep 10 && /data/powertop [-r] -d -t 30 > /data/powertop.log & 
3. 拔掉USB線，等待10秒後開始功耗測試
4. 插上USB  
5. adb pull /data/powertop.log  

2.7 CPU freq log

打開CPU freq change log：

mount -t debugfs none /sys/kernel/debug  
cd /sys/kernel/debug 
echo -n 'file acpuclock-8x60.c +p' > dynamic_debug/control 
echo -n 'file acpuclock-krait.c +p' > dynamic_debug/control

查看cpu freq stats:

cat /sys/devices/system/cpu/cpu0/cpufreq/stats 
cat /sys/devices/system/cpu/cpu1/cpufreq/stats 
cat /sys/devices/system/cpu/cpu2/cpufreq/stats 
cat /sys/devices/system/cpu/cpu3/cpufreq/stats 

To lock cpu freg:

echo the same freq to following sys mode will lock cpu freq to the setting freq.

/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

To enable/disable specific freq for ACPU

ACPU freq table is defined in acpu_freq_tbl_* structure of specific platform.

arch/arm/mach-msm/acpuclock-<platform name>.c

For 8974, it is defined in arch/arm/mach-msm/acpuclock-8974.c. the first column of following table used to enable/disable freq in the row: 1:enable, 0:disable

static struct acpu_level acpu_freq_tbl_2p3g_pvs0[] __initdata = { 
{ 1, { 300000, PLL_0, 0, 0 }, L2(0), 800000, 72 }, 
{ 0, { 345600, HFPLL, 2, 36 }, L2(1), 800000, 83 }, 
{ 1, { 422400, HFPLL, 2, 44 }, L2(2), 800000, 101 }, 
{ 0, { 499200, HFPLL, 2, 52 }, L2(2), 805000, 120 }, 
{ 0, { 576000, HFPLL, 1, 30 }, L2(3), 815000, 139 }, 
{ 1, { 652800, HFPLL, 1, 34 }, L2(3), 825000, 159 }, 
{ 1, { 729600, HFPLL, 1, 38 }, L2(4), 835000, 180 }, 
{ 0, { 806400, HFPLL, 1, 42 }, L2(4), 845000, 200 }, 
{ 1, { 883200, HFPLL, 1, 46 }, L2(4), 855000, 221 }, 
{ 1, { 960000, HFPLL, 1, 50 }, L2(9), 865000, 242 }, 
{ 1, { 1036800, HFPLL, 1, 54 }, L2(10), 875000, 264 }, 
{ 0, { 1113600, HFPLL, 1, 58 }, L2(10), 890000, 287 }, 
{ 1, { 1190400, HFPLL, 1, 62 }, L2(10), 900000, 308 }, 
… 
{ 1, { 1958400, HFPLL, 1, 102 }, L2(19), 1040000, 565 }, 
{ 0, { 2035200, HFPLL, 1, 106 }, L2(19), 1055000, 596 }, 
{ 0, { 2112000, HFPLL, 1, 110 }, L2(19), 1070000, 627 }, 
{ 0, { 2188800, HFPLL, 1, 114 }, L2(19), 1085000, 659 }, 
{ 1, { 2265600, HFPLL, 1, 118 }, L2(19), 1100000, 691 }, 
{ 0, { 0 } } 
}; 

2.8 Hoplug cores

Core 0 can’t be hotplugged, Core 1/2/3 can be hotplugged,

To remove core :

echo 0 > /sys/devices/system/cpu/cpu1/online 
echo 0 > /sys/devices/system/cpu/cpu2/online 
echo 0 > /sys/devices/system/cpu/cpu3/online 

To add back core:

echo 1 > /sys/devices/system/cpu/cpu1/online
echo 1 > /sys/devices/system/cpu/cpu2/online
echo 1 > /sys/devices/system/cpu/cpu3/online

2.9 Scaling governor

To check scaling governor：

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

To set new governor：

echo <new_governor> > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

比如：

echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

2.10 Mpdecision

Use Mpdecison daemon to start/stop/enable debug with commands below:

Start mpdecison：

start mpdecision 

n 

Stop mpdecison：

stop mpdecision

Enable mpdecision debug ：

start mpdecision --debug 

2.11 Power feature enable/disable

Following sys node can be used to enable the lower resource,

echo 2 > /sys/module/lpm_resources/enable_low_power/l2 
echo 1 > /sys/module/lpm_resources/enable_low_power/pxo 
echo 1 > /sys/module/lpm_resources/enable_low_power/vdd_dig 
echo 1 > /sys/module/lpm_resources/enable_low_power/vdd_mem 
echo 1 > /sys/module/pm_8x60/modes/cpu0/power_collapse/suspend_enabled 
echo 1 > /sys/module/pm_8x60/modes/cpu1/power_collapse/suspend_enabled 
echo 1 > /sys/module/pm_8x60/modes/cpu2/power_collapse/suspend_enabled 
echo 1 > /sys/module/pm_8x60/modes/cpu3/power_collapse/suspend_enabled 
echo 1 > /sys/module/pm_8x60/modes/cpu0/power_collapse/idle_enabled 
echo 1 > /sys/module/pm_8x60/modes/cpu0/standalone_power_collapse/suspend_enabled
echo 1 > /sys/module/pm_8x60/modes/cpu1/standalone_power_collapse/suspend_enabled
echo 1 > /sys/module/pm_8x60/modes/cpu2/standalone_power_collapse/suspend_enabled 
echo 1 > /sys/module/pm_8x60/modes/cpu3/standalone_power_collapse/suspend_enabled
echo 1 > /sys/module/pm_8x60/modes/cpu0/standalone_power_collapse/idle_enabled 
echo 1 > /sys/module/pm_8x60/modes/cpu1/standalone_power_collapse/idle_enabled 
echo 1 > /sys/module/pm_8x60/modes/cpu2/standalone_power_collapse/idle_enabled 
echo 1 > /sys/module/pm_8x60/modes/cpu3/standalone_power_collapse/idle_enabled 

echo 0 to above sys node will disable related low power mode.

2.12 Check system alarm

get Android alarms and statistics:

adb dumpsys alarm > alarms.txt

enable android debug message in logcat：

setprop persist.alarm.debug 1

2.13 Kernel timer check

Sys node /proc/timer_stats can be used to check kernel timer stastics, customer can use following command to get timer statics in specific scenario:

echo 0 > /proc/timer_stats && sleep 10 && echo 1 > /proc/timer_stats && sleep 30 && cat /proc/timer_stats > /data/timer_stats & 

OEMs need to provide file /data/timer_stats to salesforce case for check.

3、場景功耗項的優化

3.1 屏幕對功耗的影響

屏幕亮度等級不同，功耗不同。亮度越低，功耗越低。調低屏幕默認背光亮度等級和屏幕最高亮度設置時候的背光亮度等級，可以優化手機整體功耗表現。

LCD背光等級的設備節點：

/sys/class/leds/lcd-backlight/brightness

默認背光等級和最高亮度背光等級需要同時考慮到用戶體驗和功耗表現，需要一起評估。
另外，調試LCD的fps幀率，也可以優化功耗。

3.2 CPU/GPU DVFS 總體場景

CPU/GPU的動態調頻調壓可以優化手機的功耗表現。該影響是整體性的，系統性的。
CPU降頻主要通過兩種方式實現，都可以達到降頻的目標。

1、設置CPU工作在powersave模式。設置該模式後，CPU將一直工作在最低頻率（300000hz）。此時手機最省電，但是有可能會出現手機運行變卡頓。

例如：將CPU0置爲powersave模式，命令爲：

echo "powersave" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

例如：將CPU1置爲powersave模式，命令爲：

echo "powersave" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

ex780共有4個CPU（CPU0~CPU3），都可以這樣處理

2、限制CPU最高頻率，以限制CPU的運行頻率上限

CPU（CPU0~CPU3）可以選擇的頻率值如下所列，即這些數值都可以用作CPU的頻率上限。選擇的頻率上限可以根據實際場景需要來設置。在超級省電模式下，CPU工作的宗旨是：CPU工作頻率低+運行不卡，兩項都要保障。

CPU可以選擇的頻率：

300000 422400 652800 729600 883200 960000 1036800 1190400 1267200 1497600 1574400 1728000 1958400 2265600 2457600

例如：將CPU0的頻率上限設置爲960000

echo 960000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

例如：將CPU0的頻率上限設置爲422400

echo 422400 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

GPU相關調試與CPU類似，設備節點路徑/sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0

3.3 CPU佔用率

應用對cpu的佔有率，如果佔有率過高，則該應用一般會導致功耗較大。

adb shell
top -m 6 

3.4 遊戲場景功耗

可以從下面幾個方面優化：
降低屏幕背光亮度等級；
採用CPU、GPU動態調頻調壓，並調低CPU、GPU頻率下限；
採用thermal-engine.conf 。

3.5 Camera場景功耗

降低camera幀率；
降低屏幕背光亮度等級；
採用CPU、GPU動態調頻調壓，並調低CPU、GPU頻率下限；
採用thermal-engine.conf 。

Camera場景是一個比較複雜的場景，需要系統層面上來調試功耗，主要包括幾個方面：

1.首先了解清楚客戶手機上camera相關feature和sensor的配置，請參考附件。

2.從clock dump分析

• VFE clock（sdm845和670叫IFE clock），提供信號將sensor數據讀取出camera模塊，不同模組，不同場景下會有不同的配置。會影響系統Cx的電壓模式，可以使能雙VFE來優化功耗。
• CPP clock（sdm845和670叫IPE clock），通常不會有問題，但還是需要確認。
• BIMC/DDR clock，與整個系統狀態有關，也會影響到Cx的電壓模式。可以通過對比log來進行分析。

3.Ftrace分析

• CPU頻率分佈以及top task, 通過top task可以找出佔用CPU高的負載從而進一步優化。
• DDR頻率分佈，從而進一步分析DDR BW votes log
• GPU頻率分佈
• Regulator電壓分佈

4.系統電壓分析

將Cx的電壓值讀出來看是否與ftrace中的一致。因爲Cx的電壓有整個系統決定，其他子系統也可能會投票。如果發現Cx的電壓狀態與DDRclock對應模式和ftrace上分析的不一致，需要抓ramdump來定位哪個子系統帶來的影響。如現在市面上流行的AI算法會調用GPU, HVX從而影響Cx的電壓模式。

5.Perf top/top分析，請參考***培訓文檔

6.功耗數據分解

• Camera功能上一般客戶會定製自己的許多feature，通常我們需要在高通release最基礎的版本上來調試功耗。然後通過去掉和加上一個feature來確認每一個feature對功耗的影響，從而優化每個feature的功耗。
• Camera sensor模組分解，通常需要HW工程師來做。

4、Modem 功耗優化

4.1 qcn燒寫

高通的新板子沒有導入qcn參數是沒法休眠Modem的，獲取rpm_master_state 可以看到MPSS部分的數據都是0。

4.2 分離PA功耗

一般高通qrd樣機通話時的PA功耗不會超過10mA，具體查看相關平臺的Current Consumption Data文檔分解PA數據，對比自己項目機子分解數據

4.3 協議網絡問題

用qxdn獲取相關場景log，查看小區信號質量，小區是否頻繁切換情況，是否一直在請求和註冊網絡。

4.4 電壓投票情況分析

同1.12節獲取RPM dump，用qpst或hansei腳本解析，分析相關場景下是哪個子模塊投票給CX/MX等電路的電壓比較高，重點分析相關子模塊。

CODERAM.bin 
MSGRAM.bin
DATARAM.bin 

4.5 Modem Active

1. MCPM vote: \modem_proc\mpower\mcpm\doc . expected working core freq/mx/cx.
   RRC connect: QXMD =>APEX

2. DPM (80-NU566-1_A_Data_Power_Manager_Overview.pdf)

3. PCH/PICH longer awake time/higher awake current.
   Longer awake time: NV check /F3 log…
   Higher awaken current: NPA power rail/clockdump for unused clock.
   Modem GPIO dump.
   modem_proc\core\systemdrivers\tlmm\scripts\tlmm_gpio_hw.cmm

注：本篇文章大部分內容參考一位同仁的文章https://blog.csdn.net/green1900/article/details/42496741，並修改一些錯誤，加上自己的見解，並補充一些額外內容。

Wu_Being博客聲明：本人博客歡迎轉載，請標明博客原文和原鏈接！謝謝！
《各種“擠牙膏式” 優化 android 功耗》：
https://wu-being.blog.csdn.net/article/details/88319690