蜗窝科技

Linux电源管理(12)_Hibernate功能

作者：Physh 发布于：2014-12-22 11:51 分类：电源管理子系统

本文简要分析了Linux一种Hibernation实现机制——Swap Suspend的是实现方法。本文会尽量从机制出发，不会深入代码分析，如果您感兴趣，可以参照附件给出的流程图，阅读内核代码，相信您也可以找到其中乐趣。

A. Swap Suspend的原因

B. 如何实现STF

C. Swap Suspend的关键

阅读全文>>

标签: Kernel hibernation

评论(23) 浏览(22913)

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

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

在计算机系统中，CPU的功能是执行程序，总结起来就是我们在教科书上学到的：取指、译码、执行。那么问题来了，如果没有程序要执行，CPU要怎么办？也许您会说，停掉就是了啊。确实，是要停掉，但何时停、怎么停，却要仔细斟酌，因为实际的软硬件环境是非常复杂的。

我们回到Linux kernel上，Linux系统中，CPU被两类程序占用：一类是进程（或线程），也称进程上下文；另一类是各种中断、异常的处理程序，也称中断上下文。

进程的存在，是用来处理事务的，如读取用户输入并显示在屏幕上。而事务总有处理完的时候，如用户不再输入，也没有新的内容需要在屏幕上显示。此时这个进程就可以让出CPU，但会随时准备回来（如用户突然有按键动作）。同理，如果系统没有中断、异常事件，CPU就不会花时间在中断上下文。

在Linux kernel中，这种CPU的无所事事的状态，被称作idle状态，而cpuidle framework，就是为了管理这种状态。

注：cpuidle framework系列文章会以ARM64作为示例平台，由于ARM64刚刚发布不久，较早版本的kernel没有相关的代码，因此选用了最新的3.18-rc4版本的kernel。

阅读全文>>

标签: Linux framework cpuidle

评论(42) 浏览(62862)

关于spin_lock的问题

作者：Physh 发布于：2014-12-12 14:10 分类：Linux内核分析

spin_lock的分析文章Google一下有很多，这里只是分享一些关于spin_lock思考过的问题。

阅读全文>>

标签: spin_lock

评论(4) 浏览(20015)

Linux时间子系统之（十二）：periodic tick

作者：linuxer 发布于：2014-12-11 18:59 分类：时间子系统

tick device layer是clock event core模块的用户，tick device layer利用clock event core模块提供的接口实现了各种tick device功能：周期性tick、tickless mode、broadcast tick等。本文从最简单的周期性tick开始，描述tick device的基本概念以及周期性tick的工作原理。

阅读全文>>

标签: 周期性tick periodic tick

评论(7) 浏览(22776)

Linux时间子系统之（十六）：clockevent

作者：linuxer 发布于：2014-12-9 19:56 分类：时间子系统

clockevent模块的代码位于linux/kernel/time/clockevents.c，是用来管理系统中的能够触发中断的timer硬件资源的一个模块，该模块的功能分成四个部分：

1）向上层的其它driver（我们称之clock event user）提供操作clock event的通用API。

2） 实现clock event控制的通用逻辑，这部分和硬件无关，我们也称之clock event core（其实内核有各种core、input core，USB core，I2C core等等，概念是类似）。 有了它，clock event user（例如high resolution timer）再也不用担心底层的硬件细节了，特别是底层的timer硬件是arch相关的时候（不要怀疑，linux kernel有过这样的时代）。

3）将和硬件相关的clock event控制逻辑封装成操作函数集，并向底层clockevent chip driver提供注册接口。这样，clock event控制的通用逻辑就可以直接调用底层操作函数，进行具体的硬件操作。

4）实现sysfs用户空间接口。

本文将分成4个章节，分别描述这四个部分的代码逻辑。

阅读全文>>

标签: clockevent

评论(31) 浏览(26327)

Linux时间子系统之（十七）：ARM generic timer驱动代码分析

作者：linuxer 发布于：2014-12-2 10:47 分类：时间子系统

关注ARM平台上timer driver（clocksource chip driver和clockevent chip driver）的驱动工程师应该会注意到timer硬件的演化过程。在单核时代，各个SOC vendor厂商购买ARM core的IP，然后自己设计SOC上的peripherals，这里面就包括了timer的硬件。由于没有统一的标准，各个厂商的设计各不相同，这给驱 动工程师带来了工作量。然而，如果仅仅是工作量的话就还好，实际上，不仅仅如此。linux的时间子系统要求硬件timer提供下面两种能力：一是 free running的counter，此外需要能够在指定的counter值上产生中断的能力。有些硬件厂商会考虑到软件的需求（例如：PXA270的 timer硬件），但是有些硬件厂商做的就不够，例如：S3C2451的timer硬件。我们在写PXA270的timer硬件驱动的时候是毫无压力的， 而在写S3C2451的timer的驱动的时候，最大的愿望就是把三星的HW timer的设计人员拉出来打一顿。

进入多核时代后，ARM 公司提供了timer的硬件设计，集成在了自己的多核结构中。例如：在Cortex A15 MPcore的硬件体系结构中有一个HW block叫做Generic Timer（该硬件取代了A9中的global timer、private timer的功能），为系统提供了计时以及触发timer event的功能。

本文主要描述了Generic Timer的相关硬件知识以及在linux kernel中如何驱动该硬件。Generic Timer的代码位于linux-3.14/drivers/clocksource/目录下，该目录保存了所有clock source相关的driver，arm_arch_timer.c就是驱动Cortex A15 MPcore的Generic Timer的。

阅读全文>>

标签: armv7-timer arm_arch_timer

评论(72) 浏览(62508)

Linux时间子系统之（十五）：clocksource

作者：linuxer 发布于：2014-12-1 19:03 分类：时间子系统

和洋葱一样，软件也是有层次的，内核往往需要对形形色色的某类型的驱动进行抽象，屏蔽掉其具体的特质，获取该类驱动共同的逻辑，而又根据这些逻辑撰写该类 驱动的抽象层。嵌入式系统总是会提供timer的硬件block，软件需要对timer硬件提供的功能进行抽象：linux kernel将timer类型的硬件抽象成两个组件，一是free running的counter，另外一个是指定的counter值上产生中断的能力。本文主要描述第一个组件，在内核中被称作clock source。

阅读全文>>

标签: 时间子系统 clocksource

评论(15) 浏览(33327)

Linux common clock framework(3)_实现逻辑分析

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

前面两篇clock framework的分析文章，分别从clock consumer和clock provider的角度，介绍了Linux kernel怎么管理系统的clock资源，以及device driver怎么使用clock资源。本文将深入到clock framework的内部，分析相关的实现逻辑。

注：本文使用的kernel版本为linux-3.10.29。虽然最新版本的kernel增加了一些内容，但主要逻辑没有改变，就不紧跟kernel的步伐了。

 

阅读全文>>

标签: Linux framework clock 实现

评论(21) 浏览(30384)

Linux内核同步机制之（三）：memory barrier

作者：linuxer 发布于：2014-11-14 19:20 分类：内核同步机制

我记得以前上学的时候大家经常说的一个词汇叫做所见即所得，有些编程工具是所见即所得的，给程序员带来极大的方便。对于一个c程序员，我们的编写的 代码能所见即所得吗？我们看到的c程序的逻辑是否就是最后CPU运行的结果呢？很遗憾，不是，我们的“所见”和最后的执行结果隔着：

1、编译器

2、CPU取指执行

编 译器将符合人类思考的逻辑（c代码）翻译成了符合CPU运算规则的汇编指令，编译器了解底层CPU的思维模式，因此，它可以在将c翻译成汇编的时候进行优 化（例如内存访问指令的重新排序），让产出的汇编指令在CPU上运行的时候更快。然而，这种优化产出的结果未必符合程序员原始的逻辑，因此，作为程序员， 作为c程序员，必须有能力了解编译器的行为，并在通过内嵌在c代码中的memory barrier来指导编译器的优化行为（这种memory barrier又叫做优化屏障，Optimization barrier），让编译器产出即高效，又逻辑正确的代码。

CPU的核心思想就 是取指执行，对于in-order的单核CPU，并且没有cache（这种CPU在现实世界中还存在吗？），汇编指令的取指和执行是严格按照顺序进行的， 也就是说，汇编指令就是所见即所得的，汇编指令的逻辑被严格的被CPU执行。然而，随着计算机系统越来越复杂（多核、cache、 superscalar、out-of-order），使用汇编指令这样贴近处理器的语言也无法保证其被CPU执行的结果的一致性，从而需要程序员（看， 人还是最不可以替代的）告知CPU如何保证逻辑正确。

综上所述，memory barrier是一种保证内存访问顺序的一种方法，让系统中的HW block（各个cpu、DMA controler、device等）对内存有一致性的视角。

阅读全文>>

标签: Memory 内存屏障 barrier

评论(26) 浏览(66763)

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