蜗窝科技

irq wakeup in linux

作者：schspa 发布于：2021-11-15 18:41 分类：电源管理子系统

在本篇文章中基于AARCH64平台，GIC作为中断控制器来进行讨论
下面是GIC-600的系统框架图：

阅读全文>>

标签: suspend sleep 电源管理 中断子系统 aarch64

评论(2) 浏览(15661)

中断唤醒系统流程

作者：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。

阅读全文>>

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

评论(22) 浏览(43736)

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) 浏览(25774)

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的suspend、runtime pm、clock framework等机制，以非常巧妙、灵活的方式，管理系统供电，以达到高效、节能的目的。

同样，作为一个framework，我们可以从三个角度分析：使用者（consumer）的角度；提供者（provider）的角度；内部实现。具体如下。

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

阅读全文>>

标签: Linux PM 电源管理 framework domain

评论(32) 浏览(33150)

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

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

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

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

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

阅读全文>>

标签: Linux PM 电源管理 runtime rpm

评论(56) 浏览(85902)

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) 浏览(53940)

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) 浏览(61654)

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) 浏览(52511)

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) 浏览(86748)

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) 浏览(138157)