Linux电源管理(13)_Driver的电源管理
作者:Physh 发布于:2014-12-26 18:31 分类:电源管理子系统
首先,回想一下wowo电源管理系列文章中提到的几个PM特性:
B. Wake Lock
C. Auto Sleep
这篇文章就简单简单整理一下以上特性的在Driver中的使用场景,理解可能有偏差,大家多指教。来看看这个几个特性的实现分别在内核代码树的位置:
WakeUp Count/WakeUp Source:
/linux/driver/base/power/wakeup.c
Wake Lock :
对用户层的:/linux/kernel/power/wakelock.c
对内核层的:/linux/include/linux/wakelock.h
Auto Sleep:
/linux/kernel/power/autosleep.c
Runtime Suspend:
/linux/driver/base/power/runtime.c
有关PM的,集中在/kernel/power/目录(PM Core),以及/driver/base/power/目录(PM Function)。一个个来看看在驱动中怎么用这些特性吧。
先来看看WakeUp Count/WakeUp Souce。
刚开始接触这个东西,总容易被Wake Souce这个关键词迷惑,第一反应是把这东西跟HW Wake Souce牵连起来,但其实这东西跟硬件没什么关系,只是一个软件抽象出来的一种设备属性,所以如果在驱动开发过程中,需要该设备具备将系统从Low Power Mode唤醒的功能,还是不要被这个特性的名字所迷惑为好。
那么,这个特性怎么使用呢?回想一下wowo描述这个特性时提到的,wakeup count的目的是为了解决同步问题,也即是为了解决”在睡眠的过程中,接收到事件而想退出睡眠“的问题以及判断“在用户层发起睡眠请求时,当前系统是否符合睡眠条件”,关于wakeup_count在用户层的应用可以简单总结为如下代码:
#define WAKEUP_COUNT "/sys/power/wakeup_count"
#define POWER_STATE "/sys/power/state"
int ret;
int wakeup;
FILE *f_wakeup = fopen(WAKE_COUNT, "rb+");
FILE *f_state = fopne(POWER_STATE, "rb+");
do {
fscanf(f_wakeup, "%d", &wakeup);
ret = fprintf(f_wakeup, "%d", wakeup);
}while (ret < 0);
fprintf(f_state, "mem");
用户层的应用就不过多考虑了,这里主要看Driver层。那么,看看Driver中关于wc/ws的应用场景:1. 在事件处理完之前主动阻止suspend,有点类似于锁,关于这点的应用就是之后要提到的对内核层的wake lock;2. 系统已经suspend了,唤醒系统上报事件,并在时间处理完之前主动阻止suspend,这就跟硬件唤醒源有关系了,而且肯定跟中断有关系。
来看第一种应用:
#include <xxx.h> ... #include <linux/platform_device.h> #include <linux/pm_wakeup.h> int xxx(struct device *dev) { pm_stay_awake(dev); .... pm_relax(dev); ... } int xxx_probe(struct platform_device *pdev) { struct device *dev = pdev->dev; ... device_init_wakeup(dev, true); ... } int __init xxx_init(void) { return platform_driver_register(&xxx_device_driver); } module_initcall(xxx_init); MODULE_LICENSE("GPL");
device_init_wakeup()给这个device赋予了ws的属性,并且在执行xxx()函数过程可以阻止系统休眠。这种是主观上的阻止,也即驱动开发者预见到这段代码执行过程中不能休眠,从而主动给PM Core报告事件,这种使用场景跟中断没有关系,可以根据需求在任何内核执行路径上报告事件,目的只是为了阻止休眠而已,需要注意的是,这种设置是没办法唤醒已经休眠的系统的。
接下来看一种比较迷惑的情况:
#include <xxx.h> ... #include <linux/platform_device.h> #include <linux/pm_wakeup.h> struct device * dev; int xxx_isr(int irq, void *dev_id) { pm_stay_awake(dev); .... pm_relax(dev); return IRQ_HANDLED; } int xxx_probe(struct platform_device *pdev) { int ret; dev = pdev->dev; ... ret = request_irq(irq, xxx_isr, xxx, xxx, xxx); ... device_init_wakeup(dev, true); ... } int __init xxx_init(void) { return platform_driver_register(&xxx_device_driver); } module_initcall(xxx_init); MODULE_LICENSE("GPL");
这种情况和IRQ有关,之前以为这么做了之后这个设备就具备硬件唤醒功能了,现在想想还真是....其实,这样做了也只能保证在ISR执行期间不会休眠而已,这个设备中断是否具备硬件唤醒功能和wc/ws还是没什么关系。
那么,当确实需要具备硬件唤醒功能,怎么办呢?这里就要谈及一个硬件概念,唤醒中断源。
这个硬件功能不同厂商的处理方法不一,如三星有些SoC从硬件电气性上就使得某些中断Pin具备了唤醒CPU的功能,再如CSR的SoC规定了只有若干个Pin可以作为唤醒Pin使用,而Atmel的SoC则采用了软件的方式来创造唤醒中断源,也即先将所有中断禁止,之后在使能开发者设置的唤醒中断。说这么多中断的事,是因为Suspend的最终形态是WFI,wait for interrupt。要具备硬件唤醒功能,好歹得是一个能到达CPU Core的中断才行,而这中间经过各级中断管理器,并不说只要是一个中断就能唤醒系统的。
那么,想要具备唤醒系统的功能,就要从中断上下功夫,如下:
#include <xxx.h> ... #include <linux/platform_device.h> #include <linux/pm_wakeup.h> struct device * dev; int xxx_isr(int irq, void *dev_id) { pm_stay_awake(dev); .... pm_relax(dev); return IRQ_HANDLED; } int xxx_probe(struct platform_device *pdev) { int ret; int irq; int flag; dev = pdev->dev; ... ret = request_irq(irq, xxx_isr, flag | IRQF_NO_SUSPEND, xxx, xxx); ... enable_irq_wake(irq); device_init_wakeup(dev, true); ... } int __init xxx_init(void) { return platform_driver_register(&xxx_device_driver); } module_initcall(xxx_init); MODULE_LICENSE("GPL");
这段代码中对中断做了两个特殊的处理,一个是在申请中断时加上了IRQF_NO_SUSPEND, 另一个是irq_enable_wake(irq); 这两个函数都可以赋予IRQ唤醒系统的能力,前者是在suspend过程中dpm_suspend_noirq()->suspend_devices_irq()时保留IRQF_NO_SUSPEND类型的中断响应,而后者直接跟irq_chip打交道,把唤醒功能的设置交由irq_chip driver处理。在Atmel的BSP中,这一个过程只是对一个名为wakeups的变量做了位标记,以便其随后在plat_form_ops->enter()时重新使能该中断。从使用角度我觉得,irq_enable_wake()会是一个更为保险且灵活的方法,毕竟更为直接而且禁用唤醒功能方便,disable_irq_wake()即可。
关于Wake Lock的使用,可以参考关于wc/ws的使用场景的前两种情况, wake_lock()只是对wc/ws应用的一种封装。
可以把wake_lock()当做一种锁来用,其内部使用了__pm_stay_awake()来使系统保持唤醒状态。别忘记,这还是一种开发者主观上的使用,即开发者希望wake_lock() ---> wake_unlock()期间系统不休眠,类似一种特殊的临界区。
同时,相对wc/ws,wake_lock()更像是一种快捷方式,开发者不用去使能设备的唤醒属性,也不用再去主动上报事件,只要在希望保持唤醒的特殊临界区的前后使用wake lock就可以达到目的。
Auto Sleep跟Wake Lock是一对冤家,一个没事就让系统休眠,一个偏不让系统休眠。简单来讲,Auto Sleep就是一直尝试sleep,如通过条件不满足,比如有事件pending(这可能是用户层持有wake_lock, driver持有wake lock,以及上报的pending时间还没有处理完),就返回,过一会再来尝试。所以,如果使能了Auto Sleep这个特性,那写驱动的时候就要考虑到某段代码是否允许休眠后起来接着运行,如果不能,就要使用wake_lock()保护起来。毕竟Auto Sleep这个特性是对于Driver来说,是被动的,异步的,不可预期的,如果Driver不想让PM Core逮着机会就休眠,就干脆别让系统休眠,而是先把自己的事情处理完了再说。
Runtime Suspend相对Auto Sleep而言就是更为Driver主观的行为了,虽然不一定但可以预期,到在调用pm_runtime_put()之后该设备可能进入runtime_idle的状态。runtime_idle的行为是Driver确定的,之后的runtime_suspend也是Driver确定的,PM Core只是在维持设备的引用计数,当确定设备空闲时调用Driver提供的接口,使得设备进入idle或suspend。
所以,开发者需要注意的事情,是保证设备的电源行为符合内核文档所描述的行为,即suspend的状态下,不占用CPU,不与主存交互等(但不一定需要进入low power mode),以及,使得设备的suspend/resume功能正常。另外就是同步问题,pm_runtime_put()之后的代码可能会在runtime_idle之后执行,所以重要的代码等还是在pm_runtime_put()之前完成更好。
抛砖引玉,大家多讨论。

评论:
2018-04-27 17:29
Android7.0平台,看log发现进入深度休眠前会先尝试进入sleep,最终退出(大概5秒)后,第二次进入sleep后持续稳定,直至用户去唤醒他。我不知道是什么方便导致的第一次sleep很快就退出了。第一次sleep的log如下:
[ 828.004427] PM: suspend entry 2018-04-27 09:07:12.854119570 UTC
[ 828.004445] PM: Syncing filesystems ... done.
[ 828.026200] PM: Preparing system for mem sleep
[ 828.028988] Freezing user space processes ...
[ 828.082561] Error: returning -512 value
[ 828.086992] (elapsed 0.057 seconds) done.
[ 828.087022] Freezing remaining freezable tasks ... (elapsed 0.008 seconds) done.
[ 828.095523] PM: Entering mem sleep
[ 828.095540] Suspending console(s) (use no_console_suspend to debug)
[ 828.164952] PM: suspend of devices complete after 65.764 msecs
[ 828.171029] PM: late suspend of devices complete after 6.050 msecs
[ 828.181415] PM: noirq suspend of devices complete after 10.366 msecs
[ 828.181578] Disabling non-boot CPUs ...
[ 828.189844] migrate_irqs: 15775 callbacks suppressed
[ 828.189851] IRQ7 no longer affine to CPU1
[ 828.189857] IRQ8 no longer affine to CPU1
[ 828.189865] IRQ9 no longer affine to CPU1
[ 828.189872] IRQ10 no longer affine to CPU1
[ 828.189880] IRQ11 no longer affine to CPU1
[ 828.189886] IRQ12 no longer affine to CPU1
[ 828.189894] IRQ13 no longer affine to CPU1
[ 828.189901] IRQ14 no longer affine to CPU1
[ 828.189908] IRQ15 no longer affine to CPU1
[ 828.189916] IRQ16 no longer affine to CPU1
[ 828.279435] Suspended for 0.000 seconds
[ 828.280625] Enabling non-boot CPUs ...
[ 828.288770] CPU1 is up
[ 828.297005] CPU2 is up
[ 828.303590] CPU3 is up
[ 828.314480] CPU4 is up
[ 828.322787] CPU5 is up
[ 828.331437] CPU6 is up
[ 828.339823] CPU7 is up
[ 828.343668] PM: noirq resume of devices complete after 2.891 msecs
[ 828.350323] PM: early resume of devices complete after 2.737 msecs
[ 828.481451] PM: resume of devices complete after 131.102 msecs
[ 828.486712] PM: Finishing wakeup.
[ 828.486725] Restarting tasks ... done.
[ 828.579814] PM: suspend exit 2018-04-27 09:07:17.502919464 UTC
其中migrate_irqs: 15775 callbacks suppressed这log在第二次sleep的时候没打印,也不清楚是为什么。
2016-08-26 15:04
最近发现suspend后,电流很大,发现有时钟没关,但是对时钟的log 不清楚。
Enabled clocks:
01-01 00:29:13.706 V/kernel ( 3449): <6>[ 1836.718347] xo_a_clk_src:2:2 [19200000]
01-01 00:29:13.706 V/kernel ( 3449): <6>[ 1836.718347] bimc_msmbus_a_clk:1:1 [532938752] -> bimc_a_clk:1:1 [532938752]
01-01 00:29:13.706 V/kernel ( 3449): <6>[ 1836.718347] pcnoc_keepalive_a_clk:1:1 [19200000] -> pcnoc_a_clk:1:1 [19200000
2015-09-25 15:12
2015-09-25 17:44
1. input_dev_release_keys中,模拟的按键up事件,会经过具体的driver吗?
2. input_dev_release_keys中,模拟的按键up事件,会试图上报wakeup event吗?
我觉得,对driver来说,它只会在检测到event和上报event之间,拿wakeup锁。上报之后,就会relex这个锁。所以,我还是建议,你确定一下最终阻止系统休眠的event到底是哪一个?例如,执行如下命令:
cat /sys/kernel/debug/wakeup*
2015-07-15 17:40
2015-03-13 22:20
enable
2.你提到的可能有同步问题是指?我还没理解。。
从你的信息中(复现了问题),说明这个问题不是必现的??如果不必现,那么正常逻辑应该没问题,会不会是enable时没有原子操作,导致结果异常?
2015-03-10 09:49
2015-03-10 11:39
2015-03-13 21:36
1.驱动中仅仅申请完irq,这个时候irq默认是enable还是disable?
2.你提到的可能有同步问题是指?我还没理解。。
2015-01-21 16:31
2015-07-15 14:46
=====================================================
wowo,我的理解是:
ltr559_schedwork
可以看到handler中schedule的thread能够被调度了。
report_ps_input_event_zte, ps far
并且调度中能上报中断,只是现在用户空间进程被冻结了,所以上层无法理睬这个input event而已。
2015-01-21 16:08
01-01 00:29:13.659 V/kernel ( 3449): <6>[ 1836.671959] PM: suspend entry 2014-12-31 16:54:39.872099731 UTC
01-01 00:29:13.659 V/kernel ( 3449): <6>[ 1836.671968] PM: Syncing filesystems ... done.
01-01 00:29:13.672 V/kernel ( 3449): <6>[ 1836.685205] Freezing user space processes ... (elapsed 0.002 seconds) done.
01-01 00:29:13.674 V/kernel ( 3449): <6>[ 1836.686529] [ALS/PS] ltr559_irq_handler, in
01-01 00:29:13.674 V/kernel ( 3449): <6>[ 1836.687035] [ALS/PS] ltr559_schedwork, status=0X33
01-01 00:29:13.674 V/kernel ( 3449): <6>[ 1836.687041] [ALS/PS] ltr559_schedwork, ps interrupt
01-01 00:29:13.675 V/kernel ( 3449): <6>[ 1836.687345] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
01-01 00:29:13.675 V/kernel ( 3449): <6>[ 1836.687616] [ALS/PS] read_ps_adc_value, ps_val=174
01-01 00:29:13.675 V/kernel ( 3449): <6>[ 1836.687636] [ALS/PS] report_ps_input_event_zte, ps far
01-01 00:29:13.676 V/kernel ( 3449): <6>[ 1836.688350] [ALS/PS] report_ps_input_event_zte, adc_value=174,default_ps_lowthresh=185,default_ps_highthresh=214
01-01 00:29:13.676 V/kernel ( 3449): <6>[ 1836.689101] Suspending console(s) (use no_console_suspend to debug)
01-01 00:29:13.680 V/kernel ( 3449): <6>[ 1836.693195] fb_notifier_callback.
01-01 00:29:13.680 V/kernel ( 3449): <6>[ 1836.693206] mdss_dsi_event_handler: event=7
01-01 00:29:13.681 V/kernel ( 3449): <6>[ 1836.693222] fb_notifier_callback.
01-01 00:29:13.682 V/kernel ( 3449): <6>[ 1836.694800] ltr559_suspend
01-01 00:29:13.699 V/kernel ( 3449): <6>[ 1836.711522] PM: suspend of devices complete after 21.136 msecs
01-01 00:29:13.700 V/kernel ( 3449): <6>[ 1836.713124] PM: late suspend of devices complete after 1.594 msecs
01-01 00:29:13.703 V/kernel ( 3449): <6>[ 1836.715527] PM: noirq suspend of devices complete after 2.396 msecs
01-01 00:29:13.703 V/kernel ( 3449): <6>[ 1836.715532] Disabling non-boot CPUs ...
01-01 00:29:13.705 V/kernel ( 3449): <4>[ 1836.717235] IRQ39 no longer affine to CPU2
01-01 00:29:13.706 V/kernel ( 3449): <6>[ 1836.718347] CPU0:msm_cpu_pm_enter_sleep mode:3 during suspend
01-01 00:29:13.706 V/kernel ( 3449): <6>[ 1836.718347] Enabled clocks:
01-01 00:29:13.706 V/kernel ( 3449): <6>[ 1836.718347] xo_a_clk_src:2:2 [19200000]
01-01 00:29:13.706 V/kernel ( 3449): <6>[ 1836.718347] bimc_msmbus_a_clk:1:1 [532938752] -> bimc_a_clk:1:1 [532938752]
01-01 00:29:13.706 V/kernel ( 3449): <6>[ 1836.718347] pcnoc_keepalive_a_clk:1:1 [19200000] -> pcnoc_a_clk:1:1 [19200000
wowo,我遇到一个问题,上述log,系统在suspend过程中ltr559驱动上报了一个消息,但这个消息未及时传递到上层,只能在下一次其他中断源唤醒系统后才处理ltr559的消息。
已经设定了irq_enable_wake(irq);但是没设IRQF_NO_SUSPEND标志。我加上IRQF_NO_SUSPEND标志会有改善吗?
谢谢
功能
最新评论
文章分类
随机文章
文章存档
- 2024年2月(1)
- 2023年5月(1)
- 2022年10月(1)
- 2022年8月(1)
- 2022年6月(1)
- 2022年5月(1)
- 2022年4月(2)
- 2022年2月(2)
- 2021年12月(1)
- 2021年11月(5)
- 2021年7月(1)
- 2021年6月(1)
- 2021年5月(3)
- 2020年3月(3)
- 2020年2月(2)
- 2020年1月(3)
- 2019年12月(3)
- 2019年5月(4)
- 2019年3月(1)
- 2019年1月(3)
- 2018年12月(2)
- 2018年11月(1)
- 2018年10月(2)
- 2018年8月(1)
- 2018年6月(1)
- 2018年5月(1)
- 2018年4月(7)
- 2018年2月(4)
- 2018年1月(5)
- 2017年12月(2)
- 2017年11月(2)
- 2017年10月(1)
- 2017年9月(5)
- 2017年8月(4)
- 2017年7月(4)
- 2017年6月(3)
- 2017年5月(3)
- 2017年4月(1)
- 2017年3月(8)
- 2017年2月(6)
- 2017年1月(5)
- 2016年12月(6)
- 2016年11月(11)
- 2016年10月(9)
- 2016年9月(6)
- 2016年8月(9)
- 2016年7月(5)
- 2016年6月(8)
- 2016年5月(8)
- 2016年4月(7)
- 2016年3月(5)
- 2016年2月(5)
- 2016年1月(6)
- 2015年12月(6)
- 2015年11月(9)
- 2015年10月(9)
- 2015年9月(4)
- 2015年8月(3)
- 2015年7月(7)
- 2015年6月(3)
- 2015年5月(6)
- 2015年4月(9)
- 2015年3月(9)
- 2015年2月(6)
- 2015年1月(6)
- 2014年12月(17)
- 2014年11月(8)
- 2014年10月(9)
- 2014年9月(7)
- 2014年8月(12)
- 2014年7月(6)
- 2014年6月(6)
- 2014年5月(9)
- 2014年4月(9)
- 2014年3月(7)
- 2014年2月(3)
- 2014年1月(4)
2019-08-28 11:18