电源功耗大概整理

1：

方法：自己读取底层节点的信息获取电池电量/温度/充电状态

/sys/class/power_supply/battery/status 读取充电状态，
–〉 Charging 对应正在充电
–〉 Full 充满

/sys/class/power_supply/battery/temp 读取电池温度， 200 表示 20 度

/sys/class/power_supply/battery/capacity 读取电池电量

5:Suspend/Resume 调试指导

1:System Suspend/Resume 是指系统在没有任务运行或者工程师通过 shell 强行写 sysfs 节点时，系统进入睡眠(deepsleep)和唤醒的过程。进入 system suspend 的过程中，应用程序被 freeze，所有外设被挂起， nonboot CPUs 被强行 unplug， CPU0 和 cluster 进入下电状态， DDR 保持上电但进入自刷新状态。

System Suspend/Resume 内核中的详细介绍可参考以下资料：
http://www.wowotech.net/pm_subsystem/suspend_and_resume.html
http://www.wowotech.net/pm_subsystem/wakelocks.html
http://www.wowotech.net/pm_subsystem/237.html
http://www.wowotech.net/pm_subsystem/suspend-irq.html

Linux电源管理(6)_Generic PM之Suspend功能:

[置顶] 展讯充电管理模块浅析(一):

从三个方面介绍：

Android 电池（一）：锂电池充电基本原理篇

android 电池（二）：android关机充电流程、充电画面以及电量显示

android 电池（三）：android电池系统

需要格外关注的文件sprd_power.c;sprd_8825_charge.c/sprd_8825_charge.h

充电驱动核心文件：power_supply_core.cpower_supply_sysfs.c

相关充电管理ic驱动代码bq27x00_battery.c,max17040_battery.c …

展讯充电管理ic模块集成在芯片内部，由各种寄存器直接操作！

一、锂电池充电基本原理篇

第一步：判断电压<1.1V，要先进行预充电，5ma电流；

第二步：判断1.1V<电压<2.7V，要先进行预充电，50ma电流；

第三步：判断 2.7V<电压<4.2V，恒流充电500ma-800ma电流

第四步：判断电压>4.2V,恒压充电,电压为4.2V,电流随电压的增加而减少，直到充满。

二、关机充电逻辑硬件逻辑

1、插入DC，charger IC从硬件上唤醒系统，相当于长按开机键开机。

DC插入，其实相当于关机状态下“按开机键”开机。第一步要走UBOOT、kernel、android init这一流程。

a：如何判断是DC插入；在函数dwc_otg_pcd_linux.c中usb_detect_works()函数中对usb插入做检测。

b：在cmd_cboot.c中有定义函数决定到底是什么方式启动开机，这个参数相当重要，这个参数决定系统是正常启动、还是关机充电状态。

SPRD平台功耗调试分享

转载自展讯

一、关于底电流偏大的问题，这里总结一下一般的调试步骤

1.如果底电流大于10ma以上的，首先需要抓串口log确定系统是否有睡眠，是否有外设一直在运行；从log中可以看有没有发生suspend,看state(0->3)是否有发生，如果有这些log,而且后面没有state(3->0)那说明睡下去了。首先请去掉所有的APK测试，看平均功耗是否有问题，如果跟去掉APK之前一样，说明跟APK没有关系

如果跟去掉APK之前相比，功耗有所降低，说明跟APK有一定的关系跟APK有关系，请自行分析APK。

2.从log确定系统正常睡眠的话，就开始逐个外设排除(排除顺序屏/backlight /wifi/bt/sensor/gps/camera/atv)，最好采用硬软件结合，硬件上去除芯片软件上去除驱动，同时将相关的输出的io口pinmap配置为高阻状态。

3.排除外设漏电情况后需要继续排除gpio漏电，方法是修改pinmap配置，特别需要关注与样机使用有差异的gpio。同时如果i2c电路外围有上拉，排除是否有漏电可能性。这需要结合硬件原理图。为方便测试，可使用工具lookat，具体请参考文档《 lookat使用说明.txt 》.

4.排除板子上所有外围下拉电容（与电池电压VBAT相关的），下拉二极管等，这需要硬件人员协助,主要是排除可能贴错了料或者器件偏位等PCBA问题，导致漏电。

5.排除memory漏电的可能性，一般确定是否是认证类型芯片、更换芯片尝试等。

6.测量睡眠时BB芯片每个ldo的电压，确定是否有电压，电压值是否正常，最后可以对ldo进行灌电流(高于其输出电压对其供电)确定是否有漏电情况。

7. 总体来说，调底电流主要分为粗调和细调两部分,对于粗调和细调并没有非常明显的界线，一般来说，当底电流大于10mA,或者大于20mA的时候需要进行的是粗调，当底电流小于10mA，但是比参考对比机要大出几个mA的时候就要开始进行细调了，

细调的定位和调试可能比粗调要复杂些。

（1）粗调，当拿到一块调试板，开始调试驱动的时候，粗调底电流就开始了，刚开始，我们一般都会先烧代码进去，看系统是否起来，看起来的过程中电流的大小，

如果能启动，过程中电流也不是特别大的话，一边就会开始调试屏，背光，touch之类的驱动，backlight是耗电大户，曾有一客户，亮屏的时候电流大近150mA,一摸板子，backlight烫得不敢摸，这是驱动跟芯片不匹配导致。Wifi/bt一般至少二合一，也是很容易产生耗电，最近的trout芯片，打开wifi待机要近30mA的电流，问题是如果去掉trout芯片还开不了机，我当时想了个办法，就是trout的供电做一个活动开关，正常时候打开，需要关闭的时候可以活动把它关闭，这样可以更好的测电流。诸如此类情况很多，具体的板子需要具体分析。

（2）细调，当底电流调到一定程度，软件上也都ok了，底电流如果还是大于参考机几个毫安，那这个时候就开始要细调了，首先要将gpio设置为高阻态，一些总线的上下拉，如I2C上拉，还有如二极管，电感等，这些主要是防止存在压差，有压差一定会存在漏电，另外每一个ldo都要进行确认，防止其漏电，主要测量压差及灌电流来确认。细调是一个系统的概念，需要对软硬件有一个比较深入的理解。

二、AP 睡不下去的各种情况

如果底电流大于10mA,很有可能是系统没办法睡下去。AP睡不下去可以分为一直睡不下去和偶尔会被中断或者其他外设唤醒。

1. 对于AP(基带，CPU)会被中断wakeup的情况：

（1）看中断号是多少，对比irqs.h里面的中断，再对比原理图和spec，确认是哪个模块产生中断，进而查找中断原因。例如：

侧键中断，如果手机放口袋里，总是会碰到侧键，这样会产生中断，进而产生不必要的功耗，并让机器持续发烫。

可做以下简单修改

static int sci_keypad_suspend(struct platform_device *dev, pm_message_t state)

{

keypad_writel(KPD_INT_EN, 0);

return 0;

}

static int sci_keypad_resume(struct platform_device *pdev)

{

keypad_writel(KPD_INT_EN, KPD_INT_ALL);

return 0;

}

请在按键中断驱动中，做以下修改

suspend时，将KPD_INT_EN寄存器清o

resume时，执行probe里面enable动作。

下面是参考代码

{

value = KPD_INT_DOWNUP;

if (pdata->support_long_key)

value |= KPD_INT_LONG;

keypad_writel(KPD_INT_EN, value);

}

（2）定时器中断。很多第三方应用都有这个情况，比如qq等，微信，来往等第三方实时通信软件，这些软件会设定唤醒系统，定时器中断增加平均功耗，当你待机后去测试，是正常的，但放那里待机一晚上，电没了，就是这种情况。（想解决这个问题的话一般只能把wifi和数据给关了）

2. 对于AP根本无法睡眠的情况，一般都是wake lock锁所导致：android的AP 电源管理方案使用Google的wake_lock机制. 在内核中维护了一个wake_lock的链表,如果有应用或者内核模块希望系统不要进入睡眠就可以申请wake_lock,这时就会在wake_lock链表中增加一项,在释放wake_lock后就会删除链表中相应的项.

AP进入suspend前会判断当前是否有活动的wake_lock,如果有则AP不会进入suspend状态。（关于modem详见下面(1)描述）

（1）导致AP不能进睡眠原因

AP 电源管理方案使用Google的wake_lock机制. 在内核中维护了一个wake_lock的链表,如果有应用或者内核模块希望系统不要进入睡眠就可以申请wake_lock,这时就会在wake_lock链表中增加一项,在释放wake_lock后就会删除链表中相应的项。

AP进入suspend前会判断当前是否有活动的wake_lock,如果有则AP就不会进入suspend状态.

由于modem相对较稳定,目前碰到系统不能进入睡眠的原因主要是由于AP有wake_lock没有释放导致AP没有进入suspend造成的。

（2）查看什么申请了wake_lock导致系统不能睡眠

所有的进程(也包括workqueue/kthread) 都已经停止了，内核态进程有可能在停止的时候握有一些spinlock，所以如果这时候在外设里面去请求这个spinlock有可能会发生死锁，所以在外设suspend()函数里面作lock/unlock锁要非常小心，建议不要在外设的suspend()里面等待锁。而且suspend的过程中，有一些log是无法输出的，所以一旦出现问题，非常难调试。

<1>查看用户空间进程是否有活动的wake_lock使用adb shell登陆到手机的控制台查看/sys/power/wake_lock 节点看是否有活动的 wake_lock cat /sys/power/wake_lock 如果输出不为空则表示当前有应用申请了wake_lock比较常见的应用是PowerManagerService,java应用都是通过该服务来获得wake_lock。

通过logcat抓取的log可以查看相应的哪些应用通过PowerManagerService申请wake_lock

一般有如下log：

PowerManagerService( 259): mLocks 01Partial_wakelock_Appname

Partial_wakelock_Appname 代表应用程序的名字

<2>查看内核空间是否有活动的 wake_lock 需要将kernel/power路径下的wakelock.c文件中的打印消息的mask中加上DEBUG_WAKE_LOCK,这样, 内核如果有内核模块申请或释放wake_lock都会打印出来,通过打印就可以看出是那个模块申请了wake_lock

另外，内核中的可以通过看/proc/wakelocks，有哪些wakelock锁。

在kernel/kernel/power/wakelock.c中添加如下函数，那么在/proc/wakelocks下就能看到有哪些wakelock锁，这样看起来会比较清晰。

static void print_active_locks_sprd(struct seq_file *m,int type)

{

struct wake_lock *lock;

bool print_expired = true;

unsigned int ret = 0;

BUG_ON(type >= WAKE_LOCK_TYPE_COUNT);

seq_printf(m,”\n************************* ACTIVE WAKE LOCKS: *************************\n”);

list_for_each_entry(lock, &active_wake_locks[type], link) {

if (lock->flags & WAKE_LOCK_AUTO_EXPIRE) {

long timeout = lock->expires – jiffies;

if (timeout > 0)

ret += seq_printf(m,”active wake lock %s, time left %ld\n”,lock->name, timeout);

else if (print_expired)

ret += seq_printf(m,”wake lock %s, expired\n”, lock->name);

} else {

ret += seq_printf(m,”active wake lock %s\n”, lock->name);

if (!(debug_mask & DEBUG_EXPIRE))

print_expired = false;

}

return ret;

}

这个函数是在原有函数的基础上添加的，需要在如下函数中添加调用它。

static int wakelock_stats_show(struct seq_file *m, void *unused)

{

unsigned long irqflags;

struct wake_lock *lock;

int ret;

int type;

spin_lock_irqsave(&list_lock, irqflags);

ret = seq_puts(m, “name\tcount\texpire_count\twake_count\tactive_since”

“\ttotal_time\tsleep_time\tmax_time\tlast_change\n”);

list_for_each_entry(lock, &inactive_locks, link)

ret = print_lock_stat(m, lock);

for (type = 0; type < WAKE_LOCK_TYPE_COUNT; type++) {

list_for_each_entry(lock, &active_wake_locks[type], link)

ret = print_lock_stat(m, lock);

}

print_active_locks_sprd(m, WAKE_LOCK_SUSPEND);

spin_unlock_irqrestore(&list_lock, irqflags);

return 0;

}

通过抓取的kernel的log可以查看相应的哪些驱动申请了wake_lock

三、MODEM睡不下去或者功耗过大

Ap影响&GPIO配置&Modem本身问题

1.客户使用双卡项目，编译双SIM卡项目，不插SIM手机开机进入待机电流0.9mA

插入双SIM卡的任何一张或者两张SIM一起插上，手机可以正常打电话，这个时候手机进入待机状态待机电流在50mA左右跳动，待机电流大是由于使用的pa芯片不支持edge功能，需要修改nv:

TD_TIANJI2_NV_TYPE\NV_PRAM_TYPE_PREV_UMTS_MS_RA_CAP\support_egprs = 0

pa芯片是否支持edge功能,需要具体查看芯片的手册.

2.平均功耗高怀疑与网络相关的处理流程,如果在实网的唤醒下，测试平均功耗的时候，

如果发现某些情况下，平均功耗比较高，并且怀疑跟网络相关的话:

找对比机在相同的环境，相同的时间地点，相同的SIM卡（比如说都是中国移动或者中国联通等）同样的后台运行APK然后看对比机是否有相同的问题，如果对比机也有相同的问题，那么可以肯定是网络问题引起的，因为网络环境比较复杂，而且各种case比较多，如果测试数据跟对比机不同，请您提供对比机的测试数据。

3.需要说明测试双卡待机电流时一定要在网络好的地方测试，网络差的地方GSM网和TD网会轮流切换，导致待机电流大

四、开机电流过大

连直流电源开机，当电流尖峰大于600mA的时候，甚至能达到1A,或者达到2A，开机开到一半重启甚至直接开不了机的情况。

1.直接开不了机的情况，连上直流电源，按开关机，直接过流保护，那这个时候一般是贴错料了，比如在cpu的供电的电容直接贴成了电阻，或者其他主要供电器件的电容贴成电阻，或者二极管贴成电阻，这样导致供电短路，这样需要检查元器件。

2.开机开到一半，电流过大重启，这一般需要软硬件一起检查，对于我们的8825平台，有一个情况是，当电池没有进行校准的时候，如果直流电源设置一个正常电压开机（比如3.9v），一般会出现开机重启，所以如果出现这种情况的话，可以将电压设置高一点（如4.5v）。对于开机开到一半，如果一些外设的驱动也没有调试，那可以采取排除法，先将屏和触摸都卸掉，直接查PCBA是否也会电流过大，再直接去掉一些芯片，比如背光IC，音频PA,modem PA，touch IC,WIFI,BT,ATV芯片等，这类芯片去掉后不影响开机，还可以去掉T卡，sim卡，确定是哪个芯片的问题后，不见得是硬件问题，有的时候是需要调试驱动，软件上进行修改等。另外一个方法是，当电流很大的时候，一般元器件或者芯片都会有发烫，可以用手感触一下或者用激光温度计测量下那个位置的温度上升特别快，这样可以更快定位模块。

3.开机的过程中有电流特别大的，但开机后是正常的，这种情况一般是软件问题，可以在连上直流电源的情况下，连接上打印log的串口，直接检查在电流大的时候是哪一模块在执行，这样可以很快定位问题出在哪里，偶尔软件上为了测试可以添加一些while循环，来达到延时，以便更多的时间来看log和比对电流大小从而更准确的来定位问题。

五、关机电流过大

手机关机后一般只有rtc在运行，其他所有设备都处于关闭状态，但我们的板子上vbat会直接给很多外设供电，理论上关机后手机的电流在1mA以下，但是有的板子会存在关机电流过大的问题，一般来说存在两种情况：

1.一种是由关机的时候，软件驱动对一些外部设备的下电时序不到位，一些芯片对下电时序也有要求，如果不正确的下电可能会使芯片接口不能完全处于高阻状态，这样可能会导致漏电，这种情况检查比较麻烦，如果漏点很小，可能不容易被发现，这种情况也只能用排除法，硬件上对一些芯片进行物理上断开，连了磁珠或者电感，或者电阻的，可以物理上断开来排查，另外使用万用表测量外设芯片接口pin是否存在电压，这种情况有时候是外设芯片的问题，需要软件来配合解决。

2.另外一种是纯硬件的问题，有元器件构成了环路，或者存在压差的电阻，二极管，或者像mos管的开关电路等，在关机后，都有可能会导致漏电。

六、在线看视频，播放MP3/MP4，玩游戏，录像电流过大

（1）对于在线视频的时候，机器的耗电可能是非常大的，因为有modem的功耗，cpu的功耗，

DSP的功耗，还有GPU,以及DDR和屏,如果这些模块的频率都调到最大的话，那整机功耗可能会非常高，还有比如像录像，播放mp3/mp4,玩游戏，这些都是需要用到CPU,DSP,GPU,DDR，屏的，如果要过移动入库之类的，对这些都有最高功耗要求，其实很多时候机器在执行这些动作的时候，频率可以比较低的情况下达到要求，所以可以在执行这些动作的时候在软件上对频率有一个限制，这个可以特定针对那个软件先自己进行测试，减cpu，gpu,ddr频率，以达到最低要求，

但这个是在不影响性能的前提下，还可以将backlight调暗，但也要基本不影响视觉效果为基础。

（2）还有一些外设是可以不用打开的时候就没必要打开，比如录像的时候蓝牙没必要打开，打开wifi的时候没必要把modem数据也打开，诸如此类。

案例

（1）由于蓝牙模块中的wake_lock导致手机不能进入睡眠,手机不能进入睡眠, 功耗偏高

通过打印log发现由于蓝牙模块申请了wake_lock没有释放导致系统不能进入suspend状态，最终导致手机不能进入睡眠。

（2）由于第三方应用的合入导致手机不能睡眠

可以查看/sys/power/wake_lock节点发现PowerManagerService申请了wake_lock,应用组通过将合入的应用逐一的卸载,排查出是由于世界地图应用导致系统不能进入睡眠.

(3）AP虽然睡了，但是DSP还火力很猛。

这个时候我们AP已经看不到log，系统睡了。

关于DSP那边，知识有限，下面仅就已经涉及到的问题做有限的讨论，仅供参考。

以下仅针对8825平台

如果查明系统已经睡眠，关注以下引脚是否被使用且配置为如下模式

REG_PIN_CLK_REQ1/GPIO189 – 配置为CLK_REQ1（输入）

REG_PIN_CLK_REQ2/GPIO190 – 配置为CLK_REQ2（输入）

REG_PIN_IIS0MCK – 配置为BTXT_LEN （输入）

REG_PIN_XTL_EN – 配置为XTL_EN （输出）

在以上模式情况下：

1>当CLK_REQ1/CLK_REQ2/BTXT_LEN任意一个为高电平，REG_PIN_XTL_EN输出为高电平；

2>VDD_RF随XTL_EN变动，默认将会输出2.85V；

该模式仅在dsp模式工作，因此，arm实际已处于睡眠模式。

可通过以下配置暂时避免，待功能完善恢复

{REG_PIN_IIS0MCK, BITS_PIN_DS(1)|BITS_PIN_AF(3)|BIT_PIN_WPD|BIT_PIN_SLP_WPD|BIT_PIN_SLP_Z}

{REG_PIN_CLK_REQ1, BITS_PIN_DS(1)|BITS_PIN_AF(3)|BIT_PIN_WPD|BIT_PIN_SLP_WPD|BIT_PIN_SLP_Z},

{REG_PIN_CLK_REQ2, BITS_PIN_DS(1)|BITS_PIN_AF(3)|BIT_PIN_WPD|BIT_PIN_SLP_WPD|BIT_PIN_SLP_Z},

（4）AP睡了，又醒了。

这里涉及唤醒中断的问题。简单的方法是将这个中断号打印出来。

（5）一切似乎都结束了,实际才刚刚开始

Ap睡了，BP也睡了，也没有人打扰了，可是电流还是不小。

大多数情况下，这种情况下电流不会很大，不插卡，一般也就不到4mA。但是不排除例外，最近的8825C1平台，含有trout情况下部分机器就会达到30-40MA。

排查到这里，主要就是关注外设啦，譬如外设未睡眠，漏电流，电流倒灌等等。

（6）外设的睡眠，很多设备AP睡眠时是不下电的，例如TP，这个时候我们就要在系统suspend时，对芯片做相应的动作。为了让系统最优，需要对外设进行分类，有些在灭屏就不用的，就在earlysuspend中处理，有些灭屏仍然需要工作的，就在suspend中来处理。

3.系统的LDO。

SC8810/SC8825集成了低电压和低静态电流低压差稳压器（LDO）用于供电，这些内部集成的LDO便于电源管理。一些备用LDO设计的目的是为了供外部设备使用。所有的LDO都有自己的旁路（掉电）控制信号。

Linux使用标准的regulator子系统来管理LDO，展讯平台也是基于regulator子系统实现了该部分代码。

设备睡眠时关于LDO的状态。我们知道，有些LDO我们希望睡眠时关闭，相反有些LDO我们希望睡眠是打开。但是我们在写驱动时却不太关注这部分。因此，可能默认的配置影响了功耗。

这部分的例子，最常见于WIFI的调试。

在打开WIFI时，系统可以睡眠，WIFI当然不能睡眠，它还得唤醒系统。可是有时候，我们默认配置却不小心将其关闭了。最近在调试8825C1的GPS就遇到了这个问题。

8825 LDO睡眠设置，相关寄存器定义如下：

arch/arm/mach-sc8825/include/mach/regs_ana_glb.h

#define ANA_REG_GLB_LDO_SLP_CTRL0 SCI_ADDR(ANA_REGS_GLB_BASE, 0x030)

#define ANA_REG_GLB_LDO_SLP_CTRL1 SCI_ADDR(ANA_REGS_GLB_BASE, 0x034)

#define ANA_REG_GLB_LDO_SLP_CTRL2 SCI_ADDR(ANA_REGS_GLB_BASE, 0x038)

#define ANA_REG_GLB_LDO_SLP_CTRL3 SCI_ADDR(ANA_REGS_GLB_BASE, 0x03c)

命令做简单设置，初步判断是否问题根本原因：

shell@android:/ # lookat -s 0xc7f1 0x42000630

shell@android:/ # lookat -l 1 0x42000630

代码修改 /arch/arm/mach-sc8825/pm_sc8825.c

void pm_ana_ldo_config(void)

{

unsigned int val;

* FIXME, should be more gental

val = sci_adi_read(ANA_REG_GLB_LDO_SLP_CTRL0);

val = 0xc7f1;

sci_adi_write(ANA_REG_GLB_LDO_SLP_CTRL0, val, 0xffff);

val = sci_adi_read(ANA_REG_GLB_LDO_SLP_CTRL1);

val |= BIT_FSM_SLPPD_EN;

val |= BIT_DCDC_ARM_BP_EN;

sci_adi_write(ANA_REG_GLB_LDO_SLP_CTRL1, val, 0xffff);

* set ARM_DCDC_ISONUM

* ISO_ON_NUM: (0xa << 8), ISO_OFF_NUM: (0x20)

val = (0xa << 8) | (0x20);

sci_adi_write(ANA_REG_GLB_LDO_SLP_CTRL2, val, 0xffff);

* set ARM_DCDC_DLY_NUM, DLY_NUM:0x2

sci_adi_write(ANA_REG_GLB_LDO_SLP_CTRL3, 0x2, 0xffff);

}

我们可以简单的修改pm_ana_ldo_config的value来改变LDO_SLP_CTRLX

ref code:

arch/arm/mach-sc8825/include/mach/__regulator_map.h

arch/arm/mach-sc8825/include/mach/regs_ana_glb.h

当然有一种更为合理的办法是使用函数控制，所有关于LDO睡眠时下电或不下电的配置都可以使用这种方式。

REGULATOR_MODE_NORMAL // 睡眠下电

REGULATOR_MODE_STANDBY // 睡眠保持供电

以下以8825C1 GPS不能下电为例子，做设置

regulator_gps = regulator_get(NULL, “vddcmmb1p2”);

…

err = regulator_set_voltage(regulator_wifi_bt, 1800000, 1800000);

…

regulator_set_mode(regulator_gps, REGULATOR_MODE_STANDBY);

regulator_enable(regulator_gps);

4.GPIO中断配置对于系统稳定的影响案例

如图所示状况，在外设未使用情况下如是断电状态，则此时外设给BB的中断信号是未知的，如果此时BB该管脚中断配置打开状态，这可能触发无效中断，造成系统状态错乱，严重可能引起死机。

解决方法1：

在不使用该外设的时候，将该管脚中断使能关闭，特别注意开机时的配置，建议在GPIO_CustomizeInit( )中配置完该中断后，即将该中断关闭，在使用该外设时再开中断，退出时关中断

解决方法2：

在Pin的初始配置表中对该中断脚配置FPD和SPD，以确保在外设不用的时候该管脚保持确定的低电平，防止不确定的电平误触发中断，并且防止漏电

建议：方法1和方法2的设置方法同时使用，这样最安全保险

5.GPIO中断配置对于系统稳定的影响案例

现象

系统收到中断，但在中断状态寄存器中无法找到具体中断源

影响

系统无法SLEEP或中断处理过于频繁造成死机

原因

SLEEP前后中断脚上电平不一致，进Sleep电平变为中断电平，唤醒后电平又恢复非中断电平，一般为SPU/SPD配置不合理造成

配置电平触发，但触发源脉冲过窄（可能是干扰引起），造成进入处理程序时触发电平已消失

解决方法

合理配置SPU/SPD，一般和FPU/FPD保持一致，以防止SLEEP前后的中断脚上的电平变化

增加触发脉冲宽度，如果触发源确实是窄脉冲，则建议使用边沿触发（但需注意边沿中断无法唤醒芯片Sleep），如是干扰则想办法消除干扰

6. Android GPIO 配置

可以参考arch/arm/mach-sc8825/board_sp8825XX/pinmap-board.h

例如：

{REG_PIN_GPIO139, BITS_PIN_DS(1)|BITS_PIN_AF(0)|BIT_PIN_NUL|BIT_PIN_SLP_NUL|BIT_PIN_SLP_IE},

前面是要配置的pin脚名字。后面是对pin脚的具体配置

下面具体描述

BITS_PIN_DS(_x_) 该宏可以配置pin的驱动能力，分为四级0~3

BITS_PIN_AF(_x_) 该宏可以配置pin的四个功能，值为0～3，由参考芯片手册确定需要的功能

BIT_PIN_WPU 正常运行模式下的弱上拉

BIT_PIN_WPD 正常运行模式下的弱下拉

BIT_PIN_NUL 正常运行模式下无上下拉

BIT_PIN_SLP_WPU 睡眠模式下的弱上拉

BIT_PIN_SLP_WPD 睡眠模式下的弱下拉

BIT_PIN_SLP_NUL 睡眠模式下无上下拉

BIT_PIN_SLP_IE 睡眠模式下的输入

BIT_PIN_SLP_OE 睡眠模式下的输出

BIT_PIN_SLP_Z 睡眠模式下的高阻

怎么配置gpio如上所述，找到gpio所对应的pin，然后对该pin进行配置。

　GPIO API使用的是LINUX的gpio lib里定义API，请参考linux/gpio.h，这个头文件也是你使用gpiolib API所必须包含的头文件。对常用API进行简单说明：

int gpio_request(unsigned gpio, const char *label) 该API是使用GPIO必须的第一步， gpio是gpio number，gpio number为新片spec上定义的gpio number， label为该gpio的说明，例如backlight。

void gpio_free(unsigned gpio) 使用完gpio后释放该gpio。

int gpio_direction_input(unsigned gpio) 配置gpio为输入。

int gpio_direction_output(unsigned gpio, int value) 配置gpio为输出，value为输出的电平，1为高，0为低

int gpio_get_value(unsigned gpio) 判断GPIO输入的电平高低，两点需要注意： 1，只对输入GPIO，不能对输出GPIO的电平进行判断。 2，返回的非零值为高电平，0为低电平。

void gpio_set_value(unsigned gpio, int value) 设置输出GPIO的电平高低， 1为高，0为低。不能对输入GPIO进行设置。其它高级用法请参考driver/gpio/gpiolib.c.

如 mount上debugfs，可以cat gpio查看使用的gpio情况。

#mount –t debugfs /d

#cat /d/gpio/

在用户空间设置GPIO电平

在kernel里配置完gpio后，可以通过如下步骤在sysfs接口里设置gpio电平：

调用gpio_export，有两个参数，一个是gpio number, 一个是是否改变输入输出，一般设为false。

进入/sys/class/gpio/gpio(gpio_number), 例如gpio42,

在该目录下，可以看到有value选项，这时你可以echo 1 > value设置为高，echo 0 > value设置为低

GPIO中断在使用gpio中断时，首先要包含#include <linux/irq.h>，<linux/gpio.h>,然后大致经过下列步骤：

调用sprd_mfp_config配置pin为gpio

gpio_request申请该gpio

gpio_direction_input配置为输入

gpio_to_irq为一个gpio分配中断，输入的参数是gpio number，返回的是分配的IRQ号，如果小于0，分配失败。

　　调用request_irq来申请中断。

FAQ案例

1.一个SC8825C项目待机电流偏大问题

待机电流为90mA左右（不插T卡,SIM卡）,SW VER: W13.38；

从串口log可以看到，系统进入睡眠状态；

取下G SENSOR(BMA250),待机电流变成了10.9mA,但是不取G SENSOR时，G SENSOR是正常工作，I2C ADDR也是对的；

检查电路，发现按键未使用的信号给了G SENSOR做中断用；

底层代码默认KEY为2*3，所以在设计中即使没用到这么多键盘，也需要预留或软件配置成2*3（如果不行请改为0*0）；

平台默认配置是 2*2

#define CUSTOM_KEYPAD_ROWS (SCI_ROW2)

#define CUSTOM_KEYPAD_COLS (SCI_COL2)

#define ROWS (2)

#define COLS (2)

改为：

#define CUSTOM_KEYPAD_ROWS (0)

2. FM后台播放待机电流偏大

不插T卡，进收音机播放，屏灭后测待机电流，大概50ma。

插上T卡，进收音机播放，屏灭后测待机电流，大概70ma。

测试发现插上T卡时FM后台播放的电流达到70ma，入库的要求是小于70ma。分析后初步确定问题为编写eng版本向T卡写log导致电流增大。

要禁止系统向T卡写log有三个办法：

（1）编译user版本

（2）在init.sp8810.3rdparty.rc中停止写log服务

service logs4android /system/bin/logwrapper /system/xbin/logs4android.sh disabled service logs4modem /system/bin/logwrapper /system/xbin/logs4modem.sh disabled

（3）adb shell setprop logs4android.enable 0

3. BT不睡眠导致底电流偏大

老版本W13.20.5待机底电流1.8mA，移植到W13.25后底电流增大到2.2mA，新版本上硬件工作正常，外围器件的驱动GPIO口等都已经移植

(1)对比W13.20和W13.25两个log，都有正常睡眠动作，睡眠前ldo等寄存器的值都一致，所以初步定位问题是有外设漏电的情况，进一步需要软件上和硬件上去除基本外设，相应的外设的输出功能的管脚pinmap配置需要配成输出高阻。定位问题是蓝牙没有睡眠，型号为BK3512

(2)追踪W13.20和W13.25两个log，发现在都不开启BT的情况下，W13.25的代码在唤醒时会调用BT的唤醒函数，如下：

01-01 00:14:03.994 <6>1[ 31.878785] request_suspend_state:

wakeup (3->0) at 31869681900 (2012-01-01 00:14:03.993701733 UTC)

01-01 00:14:04.003 <3>1[ 31.882872] Kb_SetBackLightBrightness:

Set KPLED_CTL : 0x1020

01-01 00:14:04.003 <3>1[ 31.882882]

01-01 00:14:04.036 <4>1[ 31.921336] sprd-gsensor: — lis3dh_acc_enable — !

01-01 00:14:04.041 <4>1[ 31.926433] sprd-gsensor: — lis3dh_acc_enable — success!

01-01 00:14:04.093 <3>1[ 31.978233] bluetooth_set_power blocked = 0

但是在睡眠的时候又没有调用bluetooth_set_power blocked = 1让BT睡眠，这种不对称导致BT不能正常睡眠

(3)对比样机和客户机器打开和关闭蓝牙android的log，发现有以下区别

客户机器关闭蓝牙：

D/BluetoothAdapterStateMachine( 257): BluetoothOn process message: 2

D/BluetoothAdapterStateMachine( 257): Bluetooth state 12 -> 13

D/BluetoothAdapterStateMachine( 257): Switching process message: 54

D/BluetoothAdapterStateMachine( 257): Bluetooth state 13 -> 10 客户机器打开蓝牙：D/BluetoothAdapterStateMachine( 257): HotOff process message: 1 D/BluetoothAdapterStateMachine( 257): Bluetooth state 10 -> 11

D/BluetoothAdapterStateMachine( 257): Switching process message: 54

D/BluetoothAdapterStateMachine( 257): Switching process message: 53

D/BluetoothAdapterStateMachine( 257): Bluetooth state 11 -> 12

样机关闭蓝牙：

D/BluetoothAdapterStateMachine( 262): BluetoothOn process message: 2 D/BluetoothAdapterStateMachine( 262): Bluetooth state 12 -> 13

D/BluetoothAdapterStateMachine( 262): Switching process message: 54

D/BluetoothAdapterStateMachine( 262): Bluetooth state 13 -> 10

D/BluetoothAdapterStateMachine( 262): HotOff process message: 102

D/BluetoothAdapterStateMachine( 262): Bluetooth state 10 -> 10 样机打开蓝牙：D/BluetoothAdapterStateMachine( 262): PowerOff process message: 1 D/BluetoothAdapterStateMachine( 262): Bluetooth state 10 -> 11

D/BluetoothAdapterStateMachine( 262): WarmUp process message: 101

D/BluetoothAdapterStateMachine( 262): WarmUp process message: 54

E/StateMachine( 262): BluetoothAdapterStateMachine – unhandledMessage: msg.what=54

D/BluetoothAdapterStateMachine( 262): WarmUp process message: 51

D/BluetoothAdapterStateMachine( 262): HotOff process message: 101

D/BluetoothAdapterStateMachine( 262): Switching process message: 54

D/BluetoothAdapterStateMachine( 262): Switching process message: 53

D/BluetoothAdapterStateMachine( 262): Bluetooth state 11 -> 12

上面代码反映了BT的状态机BluetoothAdapterStateMachine在BluetoothOn-Switching-WarmUp-HotOff-PowerOff五种状态之间转换的流程对比样机发现客户机器缺少了PowerOff状态，而该状态对于BK3512这款BT来说才是真正进入低功耗状态，正因为这个原因导致客户机器睡眠时BT没有完全关掉原因。

解决办法：是否有PowerOff状态是由变量config_bluetooth_adapter_quick_switch决定的，该值定义在 device\sprd\xxx\overlay\frameworks\base\core\res\res\values\config.xml

总结：对于不同的wifi，BluetoothAdapterStateMachine具有的状态不一样，例如BRCM的wifi只需要BluetoothOn-Switching-WarmUp-HotOff四种状态而BK3512这款wifi就还需要PowerOff这种状态。

————————————————

原文链接：https://blog.csdn.net/ldinvicible/article/details/45171241

打赏

关注

一键三连

SPRD_展讯文档集合

12-01

展讯内存，mmi, debug, 环境搭建，Logel

展讯 SPRD android8.1 编译系统介绍

07-05

展讯 SPRD android8.1 编译系统介绍，文档很详细。干货！

表情包

18. 功耗问题调试日志

mh公司功耗要求：整机(包括所有外设)在飞行模式灭屏下，待机电流在5ma以内

一、功耗问题一般调试办法 – 【逐个去掉】

1. 外接精确电源（实验室有）,电脑端有一个连接电源的软件(龙旗电流检测工具)，可以查看实时电流与平均电流

2. 切换为飞行模式 – 排查modem的影响

10ma 以上 -> 查看mtklog中的kernel_log看是否有休眠”suspend”

10ma 以下 -> 逐个去掉外设: lcm/tp/camera/fingerprint/sensor/小板(直接拔除), 看哪里漏电

二、常见外设功耗：

注：除了tp带手势，其他均为询问FAE得知，均未验证

lcm : uA级

tp : uA级

tp 带手势唤醒 : 1mA

camera : uA级

sensor : uA级

fingerprint : uA级

省晶体（节省gps晶体）也会导致电流较大 – 约1mA

每增大1G RAM 电流会增大: 约1mA

三、如何确实中断唤醒源：

（1）打开irq-mt-eic.c中的EINT_DEBUG宏，重新抓取kernel log // 实测80_c_m.git 不报错,7.0都报错

（2）在log中w“ake up by EINT”之后，查找EINT_STA的值

EINT_STA的值是中断状态寄存器，每个bit对应一个EINT channel，

所以EINT_STA的值就是0x1<<index（index即EINT channel）

eg：比如EINT_STA=0x200，对应的EINT channel就是9

（3）查看cust_eint.h，跟据EINT channel确定是哪个模块

至于log中“wake up by EINT (0x20)(0x4)”的0x20指的是EINT wakesrc的index，是WAKE_SRC_EINT这个宏的值

四、常见外设功耗不符合要求原因及解决办法:

lcm :

案例一: lcm没有完全休眠:

原因: lcm驱动中使用SET_RESET_PIN(0)在休眠时对reset进行拉低，实际上LCM的reset并未拉低，拉低后又会被拉高。

而很多显示屏在休眠下去时是要将LCM的reset的拉低，显示屏的待机电流才能正常的uA级别。

解决: 改用这种方式将reset拉低:

android5.1: (不支持dts)

由老的 SET_RESET_PIN() 改为 lcd_rst_en()

驱动中:

#include <mach/mt_gpio.h> // mt_set_gpio_mode()函数包含

static void lcd_rst_en(int enabled){

if(1 == enabled){

mt_set_gpio_mode(GPIO_LCM_RST, GPIO_MODE_00);

mt_set_gpio_dir(GPIO_LCM_RST, GPIO_DIR_OUT);

mt_set_gpio_out(GPIO_LCM_RST, GPIO_OUT_ONE);

}else{

mt_set_gpio_mode(GPIO_LCM_RST, GPIO_MODE_00);

mt_set_gpio_dir(GPIO_LCM_RST, GPIO_DIR_OUT);

mt_set_gpio_out(GPIO_LCM_RST, GPIO_OUT_ZERO);

}

static void lcm_init(void)

{

lcd_rst_en(1);//SET_RESET_PIN(1);

MDELAY(2);

lcd_rst_en(0);//SET_RESET_PIN(0);

MDELAY(2);

lcd_rst_en(1);//SET_RESET_PIN(1);

MDELAY(120);

push_table(lcm_initialization_setting, sizeof(lcm_initialization_setting) / sizeof(struct LCM_setting_table), 1);

}

static void lcm_suspend(void)

{

push_table(lcm_sleep_in_setting, sizeof(lcm_sleep_in_setting) / sizeof(struct LCM_setting_table), 1);

MDELAY(10);

lcd_rst_en(0); // 新增这一句

}

static unsigned int lcm_compare_id(void)

{

…

lcd_rst_en(1);

MDELAY(25);

lcd_rst_en(0);

MDELAY(25);

lcd_rst_en(1);

MDELAY(50);

…

read_reg_v2(0xbf, buffer, 5);

…

return (0x3350 == id)?1:0;

}

android6/7:

1.修改dts: 添加reset引脚的配置，方便驱动中使用

/* DISPSYS GPIO standardization */

&pio {

…

mtkfb_pins_lcm_reset0: lcm_rst_out0_gpio {

pins_cmd_dat {

pins = <PINMUX_GPIO70__FUNC_LCM_RST>;

slew-rate = <1>;

output-low;

};

mtkfb_pins_lcm_reset1: lcm_rst_out1_gpio {

pins_cmd_dat {

pins = <PINMUX_GPIO70__FUNC_LCM_RST>;

slew-rate = <1>;

output-high;

};

…

}

&mtkfb {

…

pinctrl-3 = <&mtkfb_pins_lcm_reset0>;

pinctrl-4 = <&mtkfb_pins_lcm_reset1>;

}

2.驱动中: (kernel中才能用dts)

#include “disp_dts_gpio.h” // mt_lcm_rst_set_gpio()函数包含

static void lcm_init(void)

{

mt_lcm_rst_set_gpio(1);

MDELAY(10);

mt_lcm_rst_set_gpio(0);

MDELAY(10);

mt_lcm_rst_set_gpio(1);

MDELAY(200);

push_table(lcm_initialization_setting,

sizeof(lcm_initialization_setting) /

sizeof(struct LCM_setting_table), 1);

}

static void lcm_suspend(void)

{

push_table(lcm_sleep_in_setting, sizeof(lcm_sleep_in_setting) / sizeof(struct LCM_setting_table), 1);

MDELAY(10);

mt_lcm_rst_set_gpio(0);

}

static unsigned int lcm_compare_id(void)

{

…

mt_lcm_rst_set_gpio(1);

MDELAY(25);

mt_lcm_rst_set_gpio(0);

MDELAY(25);

mt_lcm_rst_set_gpio(1);

MDELAY(50);

…

read_reg_v2(0xbf, buffer, 5);

…

return (0x3350 == id)?1:0;

}

tp :

案例一: 固件原因

原因: 固件

解决: 安排FAE来优化固件

示例: v618_p300项目，tp电流为1.5mA

->FAE优化下发参数之后，约为1mA

camera:

案例一 : 待机电流过大（18ma） – 后副摄没有休眠 – 掉电时序

现象 : 整机待机电流正常(7ma)，摄像头打开再关闭灭屏后整机待机电流过大(18ma)

平台 : androidN,MTK6737

排查过程: 1. 一个有后副摄，一个没有后副摄对照，发现无后副摄的机器电流正常

2. 引出后副摄的RST 与PDN脚，用万用表测量打开载关闭灭屏之后的电平 – 低

3. 对照gc0310的芯片手册 – PDN脚为高时休眠

4. 掉电时序中将PDN脚拉高

– mtkcam_gpio_set(pinSetIdx, CAMPDN, pinSet[pinSetIdx][IDX_PS_CMPDN + IDX_PS_ON]); // 拉低前面进行翻转

+ mtkcam_gpio_set(pinSetIdx, CAMPDN, pinSet[pinSetIdx][IDX_PS_CMPDN + IDX_PS_OFF]); // 拉高

5. 改掉电时序之后还是一样电流大，怀疑没跑到，修改的代码中添加log -> log没打印

询问姜工后，修改alps\kernel-3.18\drivers\misc\mediatek\imgsensor\src\mt6735m\kd_sensorlist.c:

在kd_MultiSensorClose()函数中，打开后副摄掉电时序:

– #ifdef CONFIG_KST_DUAL_CAM_YUV0

+ #if ((defined CONFIG_KST_DUAL_CAM_YUV0) || (defined CONFIG_KST_BOARD_V666))

6. log还是没打印，修改掉电时序中: (均打印得知:后副摄 pinSetIdx == 2)

– if((pinSetIdx == 0)&&(currSensorName && (0 == strcmp(SENSOR_DRVNAME_GC0310_MIPI_YUV, currSensorName))))

+ if((pinSetIdx == 2)&&(currSensorName && (0 == strcmp(SENSOR_DRVNAME_GC0310_MIPI_YUV, currSensorName))))

处理方案: 修改掉电时序

sensor:

案例一: 待机电流过大（6.6ma） – gsensor 中断脚漏电

原因: 原理图中gsensor的中断脚接了10k的上拉电阻，上拉到PMU1.8v 高电平, 而dws中没有配置GPIO60为中断模式，

处理: 1. 配置dws中的pin脚模式与中断的触发方式

dws配置pin脚:

EintMode|Def.Mode M0|M1|M2|M3|M4|M5|M6|M7|InPull En|InPull SelHigh|Def.Dir|In|Out|OutHigh|VarName1

– GPIO60 0:GPIO80 1 0 0 1 1 0 1 0 1 0 OUT 0 1 0

+ GPIO60 1 0:GPIO80 1 1 IN GPIO_GSE_1_EINT_PIN

dws配置EINT:

EINTVar|Debounce Time(ms)|Polarity|Sensitive_Level|Debounce En

– EINT60 NC 0

+ EINT60 GSE_1 0 High Level Disable

2. 或者在硬件中去掉上拉电阻，也就是将gsensor的中断脚NC掉

==> 配置dws后功耗正常(小于5ma)

案例二: 待机电流过大（8ma）去掉gsensor后5ma

原因: gsensor(qma6981)的第10脚只能悬空或接1.8v，而实际接到了2.8v

处理: 1. 查看log，休眠与唤醒函数都正常跑到了

2. 对比相同mtk6737 android7.0的其他项目。不同主板的gsensor 6981功耗正常。==>对比电路原理图

发现qma6981的第10脚接的电压不一样，正常主板接的是1.8v，问题主板接到2.8v。

3. 咨询fae后得知:[此芯片的Pin10 为VDDIO 电压域1.8v，当接入2.8V电压时会产生电压差导致待机电流偏大4-5mA，且无法通过软件改善] ，第10脚只能悬空或接1.8v

4. 尝试将正常主板的第10脚接到2.8v，功耗就变大了3个ma(正常主板原理图上做了1.8v/2.8v兼容，将接到1.8v的电阻挪到接2.8v的位置即可)

==> 硬件改版(问题主板没做1.8v/2.8v兼容) or 更换gsensor为3433(3433 芯片内部兼容1.8v/2.8v)

5. 也就是说3433与6981并不完全pin对pin

案例三 : gsensor兼容(3433 & 6981)导致功耗大(70ma)

平台: androidN,MTK6737

步骤: 1. 休眠时候打log: adb shell dmesg > e:gsensor_3433_6981.log

log显示由于设备(2-004c – mc3433)休眠失败，导致系统休眠失败，重新唤醒，

系统一直处于: 休眠->休眠失败->唤醒 ->休眠的循环中

[ 207.629520] (1)[1066:system_server]qma6981_suspend 2894 : liuzhigou 20171018 qma6981_suspend start

[ 207.635164] (1)[1066:system_server]qma6981_suspend 2914 : liuzhigou 20171018 qma6981_suspend end

[ 207.635254] (1)[1066:system_server]liuzhigou 20171018 mc3xxx_suspend start

[ 207.635291] (1)[1066:system_server]dpm_run_callback(): i2c_device_pm_suspend+0x0/0x38 returns -22

[ 207.635324] (1)[1066:system_server]PM: Device 2-004c failed to suspend: error -22

[ 207.635352] (1)[1066:system_server][name:suspend&]PM: Some devices failed to suspend, or early wake event detected

2. 在mc3433的休眠函数中，添加打印log:

static int mc3xxx_suspend(struct i2c_client *client, pm_message_t msg)

{

struct mc3xxx_i2c_data *obj = i2c_get_clientdata(client);

int err = 0;

if(msg.event == PM_EVENT_SUSPEND) {

if(obj == NULL) {

+ GSE_ERR(“liuzhigou 20171025 %s obj == NULL\n”,__FUNCTION__);

return -EINVAL;

}

[ 116.917907] (0)[1150:system_server]liuzhigou 20171018 mc3xxx_suspend start

[ 116.917926] (0)[1150:system_server]liuzhigou 20171018 mc3xxx_suspend msg.event == PM_EVENT_SUSPEND

[ 116.917943] (0)[1150:system_server]liuzhigou 20171018 mc3xxx_suspend obj == NULL

[ 116.917974] (0)[1150:system_server]dpm_run_callback(): i2c_device_pm_suspend+0x0/0x38 returns -22

[ 116.917996] (0)[1150:system_server]PM: Device 2-004c failed to suspend: error -22

[ 116.918016] (0)[1150:system_server]PM: Some devices failed to suspend, or early wake event detected

根据log，obj为空指针，出错判断后返回错误值

3. 根据标志位添加出错判断，如果没加载3433就直接return 0(成功)，终止3433的休眠函数

static int mc3xxx_suspend(struct i2c_client *client, pm_message_t msg)

{

struct mc3xxx_i2c_data *obj = i2c_get_clientdata(client);

int err = 0;

if(msg.event == PM_EVENT_SUSPEND) {

if(obj == NULL) {

+ if (MC3XXX_INIT_FAIL == s_nInitFlag){

+ GSE_ERR(“liuzhigou 20171025 %s obj == NULL MC3XXX_INIT_FAIL == s_nInitFlag \n”,__FUNCTION__);

+ return 0;

+ }

+ else{

+ GSE_ERR(“liuzhigou 20171025 %s obj == NULL MC3XXX_INIT_FAIL != s_nInitFlag \n”,__FUNCTION__);

return -EINVAL;

}

总结 : 此log为正常状态: 0x4000为pmu中断

[ 147.732936] -(0)[1066:system_server][name:mt_spm_internal&][SPM] wake up byEINT, timer_out = 18724959, r13 = 0x10001000, debug_flag = 0x9f

[ 147.732936] -(0)[1066:system_server][name:mt_spm_internal&][SPM] r12 = 0x20, raw_sta = 0x20, idle_sta = 0x9fa, event_reg = 0x90100000, isr = 0x0

[ 147.732936] -(0)[1066:system_server][name:mt_spm_sleep&][SPM] suspend dormant state = 0, md32_flag = 0x0, md32_flag2 = 0

[ 147.732936] -(0)[1066:system_server][name:mt_spm_sleep&][SPM] log_wakesta_index = 5

[ 147.732936] -(0)[1066:system_server][name:irq_mt_eic&]EINT_STA:

[ 147.732936] -(0)[1066:system_server][name:irq_mt_eic&]EINT Module – index:192,EINT_STA = 0x4000

[ 147.732936] -(0)[1066:system_server][name:irq_mt_eic&]EINT 206 is pending

[ 147.732936] -(0)[1066:system_server][name:irq_mt_eic&]

[ 147.732988] -(0)[1066:system_server][name:ccci&][ccci1/mcd]Resume cldma pdn register …11

[ 147.733070] -(0)[1066:system_server][name:irq_mt_eic&]EINT Module – expires:4294952066, jiffies:4294952065, deb_in_jiffies:1,

[ 147.733091] -(0)[1066:system_server][name:irq_mt_eic&]deb:1000, in mt_eint_set_timer_event

[ 147.733270] (0)[1066:system_server][name:cpu&]Enabling non-boot CPUs …

[ 147.733571] -(1)[0:swapper/1]CPU1: Booted secondary processor

fingerprint:

案例一: 指纹功耗约为2mA，不符合要求

原因: 没有休眠,指纹的休眠需要hal层下发休眠命令

处理: 添加相关hal层代码

实例: v618_p300项目(去掉上层mmi修改的测功耗版本)，指纹电流为2mA

->由于指纹没有收到休眠命令导致，添加上层mmi修改之后正常

充电IC:

案例一: 每隔30s左右会有一次大电流脉冲，导致平均功耗十几个毫安

现象: 30s一次大电流脉冲

原因: 1. mtklog中显示wake up by PCM_TIMER提示，但还是定位不到问题，只好git回退，

2. 通过git版本回退发现：对alps\kernel-3.18\drivers\power\mediatek\battery_meter.c中的获取电池电压

函数battery_meter_get_battery_voltage()做了【读取20次，求平均值的操作】

导致,30s一次大电流脉冲

处理: 去掉读取20次操作，还原为mtk默认即只读一次

存疑: 添加log得知,本函数每隔10s被调用一次，为何脉冲是是30s一次？

log: [cat /proc/kmsg | grep “20170713”]

[489.332438] 20170713 battery_meter_get_battery_voltage()

[489.503921] 20170713 battery_meter_get_battery_voltage()

[499.331495] 20170713 battery_meter_get_battery_voltage()

[499.503337] 20170713 battery_meter_get_battery_voltage()

[509.331463] 20170713 battery_meter_get_battery_voltage()

[509.502923] 20170713 battery_meter_get_battery_voltage()

主板功耗:

案例一: 双卡实网待机电流过大(标准需要小于12ma，实测约15ma)

原因: 谷歌服务

处理: 1. 测试的时候关闭：这种方式只能【关闭部分】谷歌服务

setting -> apps -> google play servicer 点击disable关闭

这样测出来的电流是15ma

2. 编译的时候在update\alps\system_conf.sh 【彻底关闭】（微掌客制化）

BUILD_GMS=no

这样测出来的电流是11.5ma（合格）

注意: 1. 双卡待机，数据只能开一卡，联通卡(CU)网络待机功耗较大，以移动卡(CMCC)网络待机为准

2. 切换：setting -> sim cards ->cellular data 点击选择sim卡：CMCC 移动 / CU 联通

3. 打开数据：下滑菜单打开：CMCC/CU -> cellular data 打开

打赏

关注

一键三连

3. tp调试日志

zhigouliu的博客

4032

零、点亮新tp 1. 修改kernel-3.18\arch\arm\configs\len6737m_35_m0_debug_defconfig、len6737m_35_m0_defconfig CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_MTK=y #CONFIG_TOUCHSCREEN_MTK_FT6X36=y CONFIG_T…

嵌入式系统降低功耗的方法研究

lanshixiong的专栏

2085

文章来源：http://www.jd37.com/tech/20097/52671.html 摘要低功耗嵌入式系统设计的能量消耗问题是近几年来在嵌入式系统设计中普遍关注的难点与热点，它严重制约着嵌入式系统的应用及发展。本文以降低嵌入式系统所耗电能为目标，提出了嵌入式系统降低功耗的综合措施，并对低功耗嵌入式系统各种经典措施进行优化改进，使之充分发挥降低功耗的作用。最后阐述了该解

表情包

电源功耗大概整理

SPRD平台功耗调试分享

18. 功耗问题调试日志

电源功耗大概整理的更多相关文章

随机推荐

热门专题

目录导航