中断唤醒系统流程

作者:smcdef 发布于:2018-1-1 17:03 分类:中断子系统

1) 设备唤醒cpu之后是立即跳转中断向量表指定的位置吗?如果不是,那么是什么时候才会跳转呢?

2) 已经跳转到中断服务函数开始执行代码,后续就会调用你注册的中断handle 代码吗?如果不是,那中断服务函数做什么准备呢?而你注册的中断handle又会在什么时候才开始执行呢?
3) 假如register_thread_irq方式注册的threaded irq中调用msleep(1000),睡眠1秒,请问系统此时会继续睡下去而没调度回来吗?因此导致msleep后续的操作没有执行。
4) 如果在注册的中断handle中把主要的操作都放在delayed work中,然后queue delayed work,work延时1秒执行,请问系统此时会继续睡下去而没调度delayed work 吗?因此导致delayed work 中的操作没有执行呢?
5) 如果4)成立的话,我们该如何编程避免这个问题呢?
好了,本片文章就为你解答所有的疑问。
注:文章代码分析基于linux-4.15.0-rc3。

阅读全文>>

标签: 电源管理 中断处理 中断子系统 中断唤醒

评论(0) 浏览(963)

Linux PM QoS framework(1)_概述和软件架构

作者:wowo 发布于:2015-2-4 23:06 分类:电源管理子系统

QOS为Quality Of Service(服务质量)的简称,对PM QoS而言,表示Linux kernel电源管理相关的服务质量。那到底什么是服务质量呢?

我们知道,Linux PM的主要功能,是节省功耗,但同时,会付出一定的性能代价,例如延迟(latency)增加、吞吐量(throughput)下降。可以把PM当作一种服务,把它对性能的影响,类比为服务的质量(QoS)。对性能的影响越大,QoS越低,反之越高。

不过,PM QoS framework的存在,并不是为了定义并测量系统的服务质量(Linux系统对实际的qos没有任何兴趣),而是为了定义一套框架,以满足系统各个实体(如进程、设备驱动等等)对QoS的期望为终极目标。根据实际的场景,这些期望可描述为:xxx不大于某个值;xxx不小于某个值;等等。

这个终极目标,是基于这样的事实:机器是极端的实用主义者。最理想的状况,是刚刚满足系统各个实体对QoS的期望,因而可以在满足需求的同时,最大化的省电。粗俗一点,就是“我能考60分,为什么要多花一点力气去考61分?”。这样的思路,值得我们深思。

本文将基于PM QoS framework整体的软件架构,介绍它的功能、应用场景、使用方式等。

阅读全文>>

标签: Linux PM 电源管理 pm_qos qos

评论(5) 浏览(8015)

Linux PM domain framework(1)_概述和使用流程

作者:wowo 发布于:2014-11-13 22:09 分类:电源管理子系统

在复杂的片上系统(SOC)中,设计者一般会将系统的供电分为多个独立的block,这称作电源域(Power Domain),这样做有很多好处,例如:

1)将不同功能模块的供电分开,减小相互之间的干扰(如模拟和数字分开)。

2)不同功能所需的电压大小不同:小电压能量损耗低,但对信号质量的要求较高;大电压能量损耗高,对信号质量的要求较低。因此可以根据实际情况,使用不同的电压供电,例如CPU core只需1.2v左右即可,而大部分的I/O则需要3.3v左右。

3)系统运行的大部分时间,并不需要所有模块都处于power on状态,因此可以通过关闭不工作模块的供电,将它们的耗电降为最低。

4)等等

虽然电源域的好处多多,却不是越多越好,因为划分电源域是需要成本的(需要在PMU中使用模拟电路完成,包括金钱成本和空间成本)。因此,大多数系统会根据功能,设置有限的几个电源域,例如:CPU core(1、2、3…);GPU;NAND;DDR;USB;Display;Codec;等等。

这种设计引出一个问题:存在多个模块共用一个电源域的情况。因而要求在对模块power on/off的时候,考虑power共用的情况:只要一个模块工作,就要power on;直到所有模块停止工作,才能power off。

Kernel的PM domain framework(位于drivers/base/power/domain.c中),提供了管理和使用系统power domain的统一方法,在解决上面提到的问题的同时,结合kernel的suspendruntime pmclock framework等机制,以非常巧妙、灵活的方式,管理系统供电,以达到高效、节能的目的。

同样,作为一个framework,我们可以从三个角度分析:使用者(consumer)的角度;提供者(provider)的角度;内部实现。具体如下。

注:本文的linux kernel版本为3.18-rc4。一般情况下,对于那些相对稳定的framework,蜗蜗不会说明文章所使用的kernel版本,但本文是个例外,因为PM domain很多方便、易用的patch,只能在最新版本(当前为3.18-rc4)kernel上才能看到。

阅读全文>>

标签: Linux PM 电源管理 framework domain

评论(31) 浏览(10347)

Linux电源管理(11)_Runtime PM之功能描述

作者:wowo 发布于:2014-10-8 23:32 分类:电源管理子系统

终于可以写Runtime PM了,说实话,蜗蜗有点小激动。因为从个人的角度讲,我很推崇使用Runtime PM进行日常的动态电源管理,而不是suspend机制。

软件工程的基本思想就是模块化:高内聚和低耦合。通俗地讲呢,就是“各人自扫门前雪”,尽量扫好自己的(高内聚),尽量不和别人交互(低耦合)。而Runtime PM正体现了这一思想:每个设备(包括CPU)都处理好自身的电源管理工作,尽量以最低的能耗完成交代的任务,尽量在不需要工作的时候进入低功耗状态,尽量不和其它模块有过多耦合。每个设备都是最节省的话,整个系统一定是最节省的,最终达到无所谓睡、无所谓醒的天人合一状态。

讲到这里想到自己的一则趣事:大学时,蜗蜗是寝室长,但不爱打扫卫生,于是就提出一个口号,“不污染,不治理;谁污染,谁治理”。结果呢,大家猜就是了,呵呵。言归正传,开始吧。

阅读全文>>

标签: Linux PM 电源管理 runtime rpm

评论(51) 浏览(27690)

Linux电源管理(10)_autosleep

作者:wowo 发布于:2014-9-18 23:42 分类:电源管理子系统

Autosleep也是从Android wakelocks补丁集中演化而来的(Linux电源管理(9)_wakelocks),用于取代Android wakelocks中的自动休眠功能。它基于wakeup source实现,从代码逻辑上讲,autosleep是一个简单的功能,但背后却埋藏着一个值得深思的话题:

计算机的休眠(通常是STR、Standby、Hibernate等suspend操作),应当在什么时候由谁触发?

蜗蜗在“Linux电源管理(2)_Generic PM之基本概念和软件架构”中有提过,在传统的操作场景下,如PC、笔记本电脑,这个问题很好回答:由用户、在其不想或不再使用时

但在移动互联时代,用户随时随地都可能使用设备,上面的回答就不再成立,怎么办?这时,Android提出了“Opportunistic suspend(这个词汇太传神了,很难用简洁的中文去翻译,就不翻译了)”的理论,通俗的讲,就是“逮到机会就睡”。而autosleep功能,无论是基于Android wakelocks的autosleep,还是基于wakeup source的autosleep,都是为了实现“Opportunistic suspend”。

相比较“对多样的系统组件单独控制”的电源管理方案(如Linux kernel的Dynamic PM),“Opportunistic suspend”是非常简单的,只要检测到系统没有事情在做(逮到机会),就suspend整个系统。这对系统的开发人员(特别是driver开发者)来说,很容易实现,几乎不需要特别处理。

但困难的是,“系统没有事情在做”的判断依据是什么?能判断准确吗?会不会浪费过多的资源在"susend->resume-supsend…”的无聊动作上?如果只有一个设备在做事情,其它设备岂不是也得陪着耗电?等等…

所以,实现“Opportunistic suspend”机制的autosleep功能,是充满争议的。说实话,也是不优雅的。但它可以解燃眉之急,因而虽然受非议,却在Android设备中广泛使用。

其实Android中很多机制都是这样的(如wakelocks,如binder,等等),可以这样比方:Android是设计中的现实主义,Linux kernel是设计中的理想主义,当理想和现实冲突时,怎么调和?不只是Linux kernel,其它的诸如设计、工作和生活,都会遇到类似的冲突,怎么对待?没有答案,但有一个原则:不要偏执,不要试图追求非黑即白的真理!

我们应该庆幸有Android这样的开源软件,让我们可以对比,可以思考。偏题有点远,言归正传吧,去看看autosleep的实现。

阅读全文>>

标签: Linux PM 电源管理 autosleep

评论(43) 浏览(17877)

Linux电源管理(9)_wakelocks

作者:wowo 发布于:2014-9-14 23:17 分类:电源管理子系统

wakelocks是一个有故事的功能。

wakelocks最初出现在Android为linux kernel打的一个补丁集上,该补丁集实现了一个名称为“wakelocks”的系统调用,该系统调用允许调用者阻止系统进入低功耗模式(如idle、suspend等)。同时,该补丁集更改了Linux kernel原生的电源管理执行过程(kernel/power/main.c中的state_show和state_store),转而执行自定义的state_show、state_store。

这种做法是相当不规范的,它是典型的只求实现功能,不择手段。就像国内很多的Linux开发团队,要实现某个功能,都不去弄清楚kernel现有的机制、框架,牛逼哄哄的猛干一番。最后功能是实现了,可都不知道重复造了多少轮子,浪费了多少资源。到此打住,Android的开发者不会这么草率,他们推出wakelocks机制一定有一些苦衷,我们就不评论了。

但是,虽然有苦衷,kernel的开发者可是有原则的,死活不让这种机制合并到kernel分支(换谁也不让啊),直到kernel自身的wakeup events framework成熟后,这种僵局才被打破。因为Android开发者想到了一个坏点子:不让合并就不让合并呗,我用你的机制(wakeup source),再实现一个就是了。至此,全新的wakelocks出现了。

所以wakelocks有两个,早期Android版本的wakelocks几乎已经销声匿迹了,不仔细找还真找不到它的source code(这里有一个链接,但愿读者看到时还有效,drivers/android/power.c)。本文不打算翻那本旧黄历,所以就focus在新的wakelocks上(drivers/power/wakelock.c,较新的kernel都支持)。

阅读全文>>

标签: Linux 电源管理 wakelock Android

评论(28) 浏览(19394)

Linux电源管理(8)_Wakeup count功能

作者:wowo 发布于:2014-9-12 23:35 分类:电源管理子系统

Wakeup count是Wakeup events framework的组成部分,用于解决“system suspend和system wakeup events之间的同步问题”。本文将结合“Linux电源管理(6)_Generic PM之Suspend功能”和“Linux电源管理(7)_Wakeup events framework”两篇文章,分析wakeup count的功能、实现逻辑、背后的思考,同时也是对这两篇文章的复习和总结。

阅读全文>>

标签: Linux 电源管理 wakeup count

评论(42) 浏览(17852)

Linux电源管理(7)_Wakeup events framework

作者:wowo 发布于:2014-9-9 22:43 分类:电源管理子系统

本文继续“Linux电源管理(6)_Generic PM之Suspend功能”中有关suspend同步以及PM wakeup的话题。这个话题,是近几年Linux kernel最具争议的话题之一,在国外Linux开发论坛,经常可以看到围绕该话题的辩论。辩论的时间跨度和空间跨度可以持续很长,且无法达成一致。

wakeup events framework是这个话题的一个临时性的解决方案,包括wake lock、wakeup count、autosleep等机制。它们就是本文的话题。

阅读全文>>

标签: Linux 电源管理 wakeup events framework

评论(80) 浏览(31537)

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

作者:wowo 发布于:2014-8-22 21:40 分类:电源管理子系统

Linux内核提供了三种Suspend: Freeze、Standby和STR(Suspend to RAM),在用户空间向”/sys/power/state”文件分别写入”freeze”、”standby”和”mem”,即可触发它们。

内核中,Suspend及Resume过程涉及到PM Core、Device PM、各个设备的驱动、Platform dependent PM、CPU control等多个模块,涉及了console switch、process freeze、CPU hotplug、wakeup处理等过个知识点。就让我们跟着内核代码,一一见识它们吧。

阅读全文>>

标签: Linux 内核 suspend 电源管理 resume

评论(101) 浏览(41709)

Linux电源管理(4)_Power Management Interface

作者:wowo 发布于:2014-5-29 15:55 分类:电源管理子系统

Linux电源管理中,相当多的部分是在处理Hibernate、Suspend、Runtime PM等功能。而这些功能都基于一套相似的逻辑,即“Power management interface”。该Interface的代码实现于“include/linux/pm.h”、“drivers/base/power/main.c”等文件中。主要功能是:对下,定义Device PM相关的回调函数,让各个Driver实现;对上,实现统一的PM操作函数,供PM核心逻辑调用。

因此在对Hibernate、Suspend、Runtime PM等功能解析之前,有必要先熟悉一下PM Interface,这就是本文的主要目的。

阅读全文>>

标签: Linux PM 电源管理 dev_pm_ops dpm

评论(16) 浏览(19052)

Copyright @ 2013-2015 蜗窝科技 All rights reserved. Powered by emlog