Chinaunix首页 | 论坛 | 博客
  • 博客访问: 301969
  • 博文数量: 60
  • 博客积分: 442
  • 博客等级: 下士
  • 技术积分: 910
  • 用 户 组: 普通用户
  • 注册时间: 2010-03-27 14:53
文章分类

全部博文(60)

文章存档

2021年(1)

2018年(1)

2017年(14)

2016年(31)

2015年(1)

2013年(3)

2012年(9)

我的朋友

分类: Android平台

2017-08-08 23:37:54

wakelock申请流程:


kernel/power/
drivers/base/power/
drivers/hisi/hi3xxx/hisi_lpregs.c
drivers/hisi/hi3xxx/pm.c


frameworks/base/core/java/android/os/PowerManager.java
frameworks/base/services/core/java/com/android/server/power/PowerManagerService.java
frameworks/base/services/core/jni/com_android_server_power_PowerManagerService.cpp
hardware/libhardware_legacy/power/power.c




PowerManager.java
public void acquire()
public void acquire(long timeout)
对外提供以上两个接口


两个acquire都会调用到:
acquireLocked
mService.acquireWakeLock(mToken, mFlags, mTag, mPackageName, mWorkSource,
                            mHistoryTag); //通过binder调用到acquireWakeLock@PowerManagerService.java


PowerManagerService.java
acquireWakeLock-->acquireWakeLockInternal-->updatePowerStateLocked-->updateSuspendBlockerLocked
updateSuspendBlockerLocked
根据当前系统状态,判断需要调用
mWakeLockSuspendBlocker.acquire()
还是
mWakeLockSuspendBlocker.release()


在PowerManagerService的构造函数里:
mWakeLockSuspendBlocker = createSuspendBlockerLocked("PowerManagerService.WakeLocks");
mDisplaySuspendBlocker = createSuspendBlockerLocked("PowerManagerService.Display");


    private SuspendBlocker createSuspendBlockerLocked(String name) {
        SuspendBlocker suspendBlocker = new SuspendBlockerImpl(name);
        mSuspendBlockers.add(suspendBlocker);
        return suspendBlocker;
    }


private final class SuspendBlockerImpl implements SuspendBlocker {
        @Override
        public void acquire() {
nativeAcquireSuspendBlocker(mName); //mName是在SuspendBlockerImpl构造函数里传入的,即createSuspendBlockerLocked时指定的名字
}
}
 
nativeAcquireSuspendBlocker(mName); //com_android_server_power_PowerManagerService.cpp
acquire_wake_lock(PARTIAL_WAKE_LOCK, name.c_str()); // 如果按以上流程下来,这里的name就是"PowerManagerService.WakeLocks"


acquire_wake_lock //hardware/libhardware_legacy/power/power.c
write(fd, id, strlen(id)) //fd是open("/sys/power/wake_lock", O_RDWR | O_CLOEXEC)返回的文件描述符

wake_lock_store //kernel/power/main.c
pm_wake_lock(buf);
wakelock_lookup_add(buf, len, true);


wakelock_lookup_add //kernel/power/wakelock.c
先从wakelocks_tree里按名字查找要添加的wakelock是否已经存在,存在就return找到的wakelock,不存在再往下执行
wakeup_source_add(&wl->ws) //内核的wakelock其实只做记录,记录系统中所有申请的wakelock,真正阻止休眠的是wakeup source框架
rb_insert_color(&wl->node, &wakelocks_tree) //wakelocks_tree记录系统所有wakelock
wakelocks_lru_add(wl) //用于wakelock回收




class WakeLock implements IBinder.DeathRecipient
PMS的WakeLock实现了DeathRecipient接口。根据Binder系统的知识可知,当Binder服务端死亡后,Binder系统会向注册了讣告接收的Binder客户端发送讣告通知,因此客户端可以做一些资源清理工作。
在本例中,PM.WakeLock是Binder服务端,而PMS.WakeLock是Binder客户端。假如PM.WakeLock所在进程在release唤醒锁(即WakeLock)之前死亡,PMS.WakeLock的binderDied函数则会被调用,这样,PMS也
能及时进行释放(release)工作。对于系统的重要资源来说,采用这种安全保护措施尤其必要。


applogcat中的wakelock日志:
PowerManagerService: acquireWakeLockInternal: lock=165206168, flags=0x1000001a, packageName=lte.trunk.terminal.tmophone, ws=null, uid=1001, pid=1667
日志中flags=0x1000001a是指持有的wakelock类型,对于PARTIAL_WAKE_LOCK类型的wakelock不会打印日志
public static final int FULL_WAKE_LOCK = 0x0000001a; //PowerManager.java
--------------------------------------------------------------------------------
wakelock日志周期修改:


wakelock日志记录源码:vendor/huawei/chipset_common/modules/logs/sleeplogcat/sleeplogcat.c
启动:service sleeplogcat /system/bin/sleeplogcat -t 2 -p /data/android_logs/sleeplog/ -f /system/etc/pwrlog.cfg      这行代码在文件vendor/huawei/extra/rc_files/init.platform.rc
-t是时间,单位是秒
wakelock是20s记录一次,这个时间太长,查问题有时候需要修改记录时间,比方改为1s。
改动方法:
sleeplogcat.c文件有一个函数:
cat_node() {
/*
        int index;
        for (index=0;index         }
*/
--> sleep(1);
}
g_timedelay在main初始化,是上面service命令传过来的值-t 2,即2s。
--------------------------------------------------------------------------------
wakelock日志解读与wakeup source阻止系统休眠的实现:


name active_count event_count wakeup_count expire_count active_since total_time max_time last_change
PowerManagerService.WakeLocks 79 79 8 0 1015 53959 15018 871206
PowerManagerService.Display 7 7 1 0 708 91250 28823 871513
Mains       1 1 0 0 0 0 0 1213
USB         1 1 0 0 0 0 0 1213
Battery     27 28 0 0 0 34 6 829790
usb_wake_lock 1 1 1 0 0 660630 660630 829790
autosleep   0 0 0 0 0 0 0 180




active_count
当一个wakeup event被处理且产生该wakeup event的wakeup source处于inactive状态时,计数增加


event_count
当一个wakeup event被处理时,计数增加


wakeup_count
在休眠最后一步suspend_enter函数被调用时,会通过pm_wakeup_pending函数检查系统中是否存在active wakeup source,如果有,那么suspend失败,计数增加


expire_count
pm_wakeup_event/wake_lock_timeout调用会设置一个timeout值,timeout时间到计数增加


active_since
在wakeup框架对应active_time,inactive时为0,active时计算方法为,每次打印日志时取当前时间t,然后减去last_time,这个差就是active_time


total_time
在active时更新,保存着active_time的累加值


max_time
在active时才有机会更新,每次打印日志时,判断active_time的时间,如果这次active_time比上次active_time大,那么更新max_time,如果小不更新


last_change
在wakeup框架对应last_time,active/inactive时会取当时时间,然后赋给last_time






对active_count/event_count的说明:
通俗讲,就是调用wakeup source激活函数时,wakeup source会变成active状态,然后active_count/event_count计数有增加的机会
调用wakeup source吊销函数时wakeup source会变成inactive状态


有时候会看到event_count的计数比active_count多,是因为比方调用了一次wake_lock,但还未调用wake_unlock,wakeup source还处于active状态,
此时又调用了一次wake_lock,那么只增加event_count,active_count不变






wakeup source激活函数:wake_lock/wake_lock_timeout/pm_wakeup_event/pm_stay_awake
wakeup source吊销函数:wake_unlock/pm_relax


这些函数在什么时候使用呢?


wake_lock/wake_lock_timeout
驱动中我们很常用


pm_wakeup_event
和wake_lock_timeout相同,都会设置timeout时间,pm_wakeup_event例子可参考gpio_keys驱动


pm_stay_awake/__pm_stay_awake/__pm_wakeup_event
power_supply/wifi驱动会调用pm_stay_awake
用户空间申请wakelock最终会往sys/power/wake_lock写值,到内核空间是wake_lock_store@kernel/power/main.c,wake_lock_store调用了pm_wake_lock@wakelock.c,
pm_wake_lock又调用到了__pm_stay_awake/__pm_wakeup_event




struct device {
struct dev_pm_info  power;
};
struct dev_pm_info {
struct wakeup_source    *wakeup;
};


从以上结构体可以看出,内核里的设备就是一个wakeup source,
用户空间通过PowerManagerService获取wake lock,间接调用到内核wakeup框架,所以用户空间进程也可以是一个wakeup source,
wakeup source产生一个wakeup event。


“wakeup event被处理”具体做什么处理呢?其实就是更新wakeup相关的计数,具体是更新event_count,wakeup_count,active_count,last_time,combined_event_count这些变量


wake_lock我们通常理解为持有一个锁,如果不想系统休眠那么调用该函数。其实从内核角度讲,看到的是计数。休眠时会判断计数,满足条件才休眠。


那么休眠时是如何判断计数的呢?
通过两个变量:
原子变量combined_event_count
无符号整型变量saved_count


static atomic_t combined_event_count = ATOMIC_INIT(0);
高16位保存着registered wakeup events,registered表示已经处理过的,当前处于inactive状态,所以registered wakeup events的意思是系统中阻止休眠的wakeup event总数,
用低16位保存着wakeup events in progress,意思是当前正在处理的wakeup event。


atomic_add_return(MAX_IN_PROGRESS, &combined_event_count)
这行代码执行完,registered wakeup events会加1,wakeup events in progress会减1。


atomic_add_return是原子操作,由arm汇编实现,简单可理解为combined_event_count = combined_event_count + MAX_IN_PROGRESS
比如,
combined_event_count = 0x00060001
MAX_IN_PROGRESS 即 0x0000ffff


MAX_IN_PROGRESS定义如下:
#define IN_PROGRESS_BITS    (sizeof(int) * 4)
#define MAX_IN_PROGRESS     ((1 << IN_PROGRESS_BITS) - 1)


那么,
combined_event_count = combined_event_count + MAX_IN_PROGRESS = 0x00060001 + 0x0000ffff = 0x00070000
实现了高16位加1,低16位减1。


combined_event_count值会在两个地方更新,wakeup_source_activate/wakeup_source_deactivate两个函数。


当调用wakeup source激活函数时,会调用到wakeup_source_activate函数,在此函数里会对combined_event_count低16位加1,说明有wakeup event正在处理。
当调用wakeup source吊销函数时,会调用到wakeup_source_deactivate函数,在此函数里会通过atomic_add_return对高16位加1,低16位减1。


saved_count在pm_save_wakeup_count函数中更新,值为combined_event_count的高16位,表示系统中阻止休眠的wakeup event历史总数。
在pm_wakeup_pending函数有两个判断条件,
1. 取一次combined_event_count的高16位和saved_count比较,看是否相等
2. 判断combined_event_count低16位是否为0
两个条件都成立就可以睡眠,否则就不能睡眠。
第一个条件满足表示从调用pm_save_wakeup_count开始到调用pm_wakeup_pending这段时间内,没有人调用wakeup source吊销函数;
第二个条件满足表示没有人调用wakeup source激活函数。
wakeup source吊销函数之前肯定会有wakeup source激活函数,这是成对出现的,wakeup source吊销函数不执行,说明也没有调激活函数,通俗讲就是在休眠最后时刻没有人用过wake lock。
第二个条件说明没有wakeup event在处理。
这里有个疑问,只判断第二个条件,即看有没有wakeup event处理不就行了吗,为什么要判断有没有人用过wake lock,有人用过,但现在已经释放了,还有影响吗?
我的理解是,pm_wakeup_pending在suspend_enter里调用,是休眠流程中最后一项检查,也就是在此之前freeze_processes/device_suspend已经执行过,
说明所有设备已经进入到休眠态,process也已经在冻结态。如果第一个条件不成立,说明有人用wake lock了,可以说有device或process醒来过,虽然现在wake lock已经释放,
但醒来就说不好可能还有其他未完成的事情,这时候就不适合继续休眠下去。
--------------------------------------------------------------------------------
android休眠流程:


android提供了三种休眠路径,earlysuspend、autosleep、wakeup_count。
earlysuspend:kernel里没有提供对应的sys结点,应该是废弃掉了。
autosleep:在适当时机,直接写sys文件触发休眠,echo mem > /sys/power/autosleep。
wakeup_count:结合kernel的wakeup count,在适当时机echo mem > /sys/power/state触发休眠。


适当时机是由PowerManagerService决定:
setHalAutoSuspendModeLocked@frameworks/base/services/core/java/com/android/server/power/PowerManagerService.java
nativeSetAutoSuspend@frameworks/base/services/core/jni/com_android_server_power_PowerManagerService.cpp
autosuspend_enable@system/core/libsuspend/autosuspend.c
autosuspend_ops->enable()


如果注册的是wakeup_count,那么上述会调用到autosuspend_wakeup_count_enable,wakeup_count休眠路径是这样做的:
suspend_thread_func@system/core/libsuspend/autosuspend_wakeup_count.c {
while(1) {


msleep(100);


read(wakeup_count_fd, wakeup_count,
sizeof(wakeup_count)); //wakeup_count_show-->pm_get_wakeup_count@main.c 如果有正在处理的wakeup event,那么调用schedule休眠,否则返回历史wakeup count总数


sem_wait(&suspend_lockout); //等待合适的休眠时机,autosuspend_wakeup_count_enable函数会调用sem_post(&suspend_lockout);


write(wakeup_count_fd, wakeup_count, wakeup_count_len); //wakeup_count_store-->pm_save_wakeup_count@main.c 其实并没写东西到什么地方,只是判断传入的count值和
//当前从combined_event_count取出的count值是否相等,相等表示从读count到写count这段时间没有新的wakeup event产生,返回正值,否则返回负值


write(state_fd, sleep_state, strlen(sleep_state)); //state_store@main.c echo mem > /sys/power/state 如果上面写count的write调用返回正值,那么调用此write,触发系统休眠
}
}


echo mem > /sys/power/state在kernel里流程是:
state_store@kernel/power/main.c
state = decode_state(buf, n) //解析出来是这三个值 "freeze", "standby", "mem"
pm_suspend(state)@kernel/power/suspend.c //这个函数会打印PM: suspend entry 2016-12-19 08:31:07.846252600 UTC




如果注册的是autosleep,那么会调用到autosuspend_autosleep_enable,这个函数就直接echo mem > /sys/power/autosleep,kernel里的流程是:
autosleep_store-->pm_autosleep_set_state-->queue_up_suspend_work-->try_to_suspend
try_to_suspend
pm_save_wakeup_count
pm_suspend


两种都会调用到pm_suspend
pm_suspend
enter_state
sys_sync //将缓存中的数据写入块设备
suspend_prepare
pm_prepare_console //将当前console切换到一个虚拟console并重定向内核的kmsg
pm_notifier_call_chain(PM_SUSPEND_PREPARE)
suspend_freeze_processes
freeze_processes
__usermodehelper_disable(UMH_FREEZING)
try_to_freeze_tasks(true)
freeze_task
freeze_kernel_threads
try_to_freeze_tasks(false)
freeze_task
suspend_devices_and_enter
suspend_ops->begin(state)
suspend_console
ftrace_stop
dpm_suspend_start
dpm_prepare
device_prepare
dpm_suspend
cpufreq_suspend
__cpufreq_governor
device_suspend
__device_suspend
suspend_enter
dpm_suspend_end
disable_nonboot_cpus
arch_suspend_disable_irqs
syscore_suspend
pm_wakeup_pending
suspend_ops->enter
hisi_pm_enter
cpu_suspend


autosleep_lock@autosleep.c作用:
/*
 * Note: it is only safe to mutex_lock(&autosleep_lock) if a wakeup_source
 * is active, otherwise a deadlock with try_to_suspend() is possible.
 * Alternatively mutex_lock_interruptible() can be used.  This will then fail
 * if an auto_sleep cycle tries to freeze processes.
 */
就是说,mutex_lock(&autosleep_lock)的调用,必须在有active状态的wakeup_source才安全,否则在 try_to_suspend()时可能发生死锁,我的理解是: 
例如,pm_autosleep_set_state中,需要更改autosleep_state(一个全局变量),因而需要使用mutex_lock保护临界区。如果调用时序如下: 
1. 系统具备suspend的条件,调用try_to_suspend试图suspend系统,该接口调用mutex_lock(&autosleep_lock);,持有锁。 
2. 发生调度,执行pm_autosleep_set_state所在的进程,在该接口中调用mutex_lock(&autosleep_lock)。因为此时锁已经被try_to_suspend占用,
进程sleep,且状态为TASK_UNINTERRUPTIBLE(这个状态会导致task freezing失败)。 
3. 发生调度,继续执行try_to_suspend,直到执行freeze操作(suspend_freeze_processes)。由于有进程处于TASK_UNINTERRUPTIBLE状态,freeze失败,suspend失败。 
因此,出现了“具备suspend条件,却suspend失败了”,就是上面注释中所说的deadlock问题。所以在mutex_lock(&autosleep_lock)调用前,保持系统不会suspend,就可以解决这种问题。
阅读(2199) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~