蜗窝科技

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

评论(54) 浏览(53943)

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

评论(45) 浏览(61658)

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

评论(45) 浏览(52514)

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

评论(93) 浏览(86754)

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

评论(121) 浏览(138167)

Linux电源管理(5)_Hibernate和Sleep功能介绍

作者：wowo 发布于：2014-6-10 16:11 分类：电源管理子系统

Hibernate和Sleep两个功能是Linux Generic PM的核心功能，它们的目的是类似的：暂停使用——>保存上下文——>关闭系统以节电········>恢复系统——>恢复上下文——>继续使用。

本文以内核向用户空间提供的接口为突破口，从整体上对这两个功能进行介绍，并会在后续的文章中，分析它们的实现逻辑和执行动作。

顺便感概一下，虽然这些机制在Linux系统中存在很久了（类似的概念也存在于Windows系统中），但以蜗蜗的观察，它们被使用的频率并不是很高，特别是在PC上，大多数人在大多数时候选择直接关闭系统。阴错阳差的是，在很多嵌入式设备中，设计者会利用Sleep机制实现热关机功能，以此减少开机的时间。

阅读全文>>

标签: Linux PM STD STR wakeup_count

评论(43) 浏览(64478)

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

评论(18) 浏览(60721)

Linux电源管理(3)_Generic PM之Reboot过程

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

在使用计算机的过程中，关机和重启是最先学会的两个操作。同样，这两个操作在Linux中也存在，称作shutdown和restart。这就是本文要描述的对象。

在Linux Kernel中，主流的shutdown和restart都是通过“reboot”系统调用（具体可参考kernel/sys.c）来实现的，这也是本文使用“Generic PM之Reboot过程”作为标题的原因。另外，除了我们常用的shutdown和restart两类操作之外，该系统调用也提供了其它的reboot方式，也会在这里一一说明。

阅读全文>>

标签: Linux PM 电源管理 reboot power_off

评论(37) 浏览(77605)

Linux电源管理(2)_Generic PM之基本概念和软件架构

作者：wowo 发布于：2014-5-13 19:24 分类：电源管理子系统

这里的Generic PM，是蜗蜗自己起的名字，指Linux系统中那些常规的电源管理手段，包括关机（Power off）、待机（Standby or Hibernate）、重启（Reboot）等。这些手段是在嵌入式Linux普及之前的PC或者服务器时代使用的。在那个计算机科学的蛮荒时代，人类在摩尔定律的刺激下，孜孜追求的是计算机的计算能力、处理性能，因此并不特别关心Power消耗。

在这种背景下发展出来的Linux电源管理机制，都是粗放的、静态的、被动的，具体请参考下面的介绍。

阅读全文>>

标签: Linux PM suspend hibernate sleep

评论(19) 浏览(53017)

Linux设备模型(8)_platform设备

作者：wowo 发布于：2014-4-28 10:24 分类：统一设备模型

在Linux设备模型的抽象中，存在着一类称作“Platform Device”的设备，内核是这样描述它们的（Documentation/driver-model/platform.txt）：

Platform devices are devices that typically appear as autonomous entities in the system. This includes legacy port-based devices and host bridges to peripheral buses, and most controllers integrated into system-on-chip platforms.  What they usually have in common is direct addressing from a CPU bus.  Rarely, a platform_device will be connected through a segment of some other kind of bus; but its registers will still be directly addressable.

概括来说，Platform设备包括：基于端口的设备（已不推荐使用，保留下来只为兼容旧设备，legacy）；连接物理总线的桥设备；集成在SOC平台上面的控制器；连接在其它bus上的设备（很少见）。等等。

这些设备有一个基本的特征：可以通过CPU bus直接寻址（例如在嵌入式系统常见的“寄存器”）。因此，由于这个共性，内核在设备模型的基础上（device和device_driver），对这些设备进行了更进一步的封装，抽象出paltform bus、platform device和platform driver，以便驱动开发人员可以方便的开发这类设备的驱动。

可以说，paltform设备对Linux驱动工程师是非常重要的，因为我们编写的大多数设备驱动，都是为了驱动plaftom设备。本文我们就来看看Platform设备在内核中的实现。

阅读全文>>

标签: Linux Kernel 设备模型 platform设备

评论(34) 浏览(79214)