蜗窝科技

对heziq网友问题的回答

作者：linuxer 发布于：2015-3-23 19:03

heziq网友在《linux kernel的中断子系统之（四）：High level irq event handler》文档中提出了若干个问题，由于在回复中无法图形表达，因此单独出一份文档来回答，希望可以有所帮助。当然，由于他提出的问题和硬件电路设计有关，这里我只是表达我自己的观点（毕竟出身是软件工程师），如果有误，请不吝指出。

阅读全文>>

标签: 上拉电阻下拉电阻

评论(9) 浏览(11553)

Linux Regulator Framework(1)_概述

作者：wowo 发布于：2015-3-20 21:42 分类：电源管理子系统

Regulator，中文名翻译为“稳定器”，在电子工程中，是voltage regulator（稳压器）或者current regulator（稳流器）的简称，指可以自动维持恒定电压（或电流）的装置。

voltage regulator最早应用于功放电路中，主要用于滤除电源纹波（100或者120Hz）和噪声，以及避免“输出电压随负载的变化而变化”的情况。后来，随着IC级别的regulator的出现（便宜了），voltage regulator几乎存在于任何的电子设备中。例如我们常见的嵌入式设备中，基本上每一种电压，都是经过regulator输出的。

相比较voltage regulator的广泛使用，很少见到current regulator的应用场景（相信大多数的嵌入式工程师都没有接触过）。它一般存在于电流源中，除此之外，它广泛存在于近年来新兴的LED照明设备中。current regulator在LED设备中的作用主要有两个：避免驱动电流超出最大额定值，影响其可靠性；获得预期的亮度要求，并保证各个LED亮度、色度的一致性。

虽然原理比较复杂，但从设备驱动的角度看，regulator的控制应该很简单，就是输出的enable/disable、输出电压或电流的大小的控制。那么，linux kernel的regulator framework到底要做什么呢？这就是本文的目的：弄清楚regulator framework背后思考，并总结出其软件架构（和common clock framework类似，consumer/provider/core）。

注1：有关regulator的描述，参考自“http://sound.westhost.com/articles/vi-regulators.html”。

注2：kernel中有关regulator framework的介绍写的相当好（Documentation\power\regulator\*），因此本文大部分内容会参考这些文件。

阅读全文>>

标签: Linux framework regulator 软件架构

评论(18) 浏览(41949)

Linux power supply class(1)_软件架构及API汇整

作者：wowo 发布于：2015-3-13 22:14 分类：电源管理子系统

power supply class为编写供电设备（power supply，后面简称PSY）的驱动提供了统一的框架，功能包括：

1）抽象PSY设备的共性，向用户空间提供统一的API。

2）为底层PSY驱动的编写，提供简单、统一的方式。同时封装并实现公共逻辑，驱动工程师只需把精力集中在和硬件相关的部分即可。

本文将从设计思路、软件架构、API说明以及怎么编写power supply driver四个角度，介绍power supply class。并会在下一篇文章中，分析power supply class的内部逻辑。如果有时间，会在第三篇文章中，以android系统为例，介绍应用软件怎样利用power supply class，监控系统的供电状态。

注：其实所有的class（如input subsystem），思路都是这样的----抽象共性、统一接口、屏蔽细节。我们在“Linux设备模型(7)_Class”中介绍过，本文在介绍power supply class同时，也以此为例，进一步理解设备模型中class的存在意义和使用方法。

阅读全文>>

标签: Linux class psy

评论(43) 浏览(43162)

计算机科学基础知识之（六）：理解栈帧

作者：linuxer 发布于：2015-3-12 13:00 分类：基础学科

本文以一个简单的例子来描述ARM linux下的stack frame。

本文也是对tigger网友问题的回复。

阅读全文>>

标签: stack frame 栈帧

评论(8) 浏览(21732)

计算机科学基础知识（五）: 动态链接

作者：linuxer 发布于：2015-3-10 18:15 分类：基础学科

本文以类似hello world这样的简单程序为例，描述了动态连接的概念。第二章描述了整个动态链接的大概过程，随后的两章解析了程序访问动态库中的数据和调用动态库中函数的过程。

注意：阅读本文之前需要先了解relocatable object file、静态链接以及动态库和PIC这些内容。

阅读全文>>

标签: dynamic link 动态链接

评论(2) 浏览(13193)

Linux时间子系统之（二）：软件架构

作者：linuxer 发布于：2015-3-7 18:37 分类：时间子系统

本文的主要内容是描述内核时间子系统的软件框架。首先介绍了从旧的时间子系统迁移到新的时间子系统的源由，介绍新的时间子系统的优势。第三章汇整了时间子系统的相关文件以及内核配置。最后描述各种内核配置下的时间子系统的数据流和控制流。

阅读全文>>

标签: 软件框架时间子系统

评论(33) 浏览(50612)

计算机科学基础知识（四）: 动态库和位置无关代码

作者：linuxer 发布于：2015-3-6 9:39 分类：基础学科

本文主要描述了动态库以及和动态库有紧密联系的位置无关代码的相关资讯。首先介绍了动态库和位置无关代码的源由，了解这些背景知识有助于理解和学习动态库。随后，我们通过加-fPIC和不加这个编译选项分别编译出两个relocatable object file，看看编译器是如何生成位置无关代码的。最后，我们自己动手编写一个简单的动态库，并解析了一些symbol Visibility、动态符号表等一些相关基本概念。

本文中的描述是基于ARM MCU，GNU/linux平台而言的，本文是个人对动态库的理解，如果有错误，请及时指出。

阅读全文>>

标签: 动态库 PIC 位置无关代码

评论(4) 浏览(29901)

Linux电源管理(14)_从设备驱动的角度看电源管理

作者：wowo 发布于：2015-3-2 22:53 分类：电源管理子系统

相信工作稍微久一点的linux驱动工程师都深有体会：

在旧时光里，实现某一个设备的电源管理功能，是非常简单的一件事情。大多数设备都被抽象为platform设备，driver只需要提供suspend/resume/shutdown等回调函数，并注册到kernel即可。kernel会在系统电源状态切换的过程中，调用driver提供的回调函数，切换设备的电源状态。

但是在新时代中，设备电源管理有关的操作，被统一封装在struct dev_pm_ops结构中了。该结构包含20多个回调函数，再加上复杂的电源管理机制（常规的suspend/resume、runtime PM等等），使设备驱动的电源管理工作不再那么单纯，工程师（如蜗蜗自己）的思路也不再特别清晰。

因此本文希望能以单一设备的电源管理为出发点，结合kernel的电源管理机制，介绍怎样在设备驱动中添加电源管理功能，并分析设备电源状态切换和系统电源状态切换的关系。

另外，我们在电源管理系列文章中，介绍了很多的电源管理机制，如generic PM、wakeup event framework、wakelock、autosleep、runtime PM、PM domain、等等，本文也算是对它们的梳理和总结。

阅读全文>>

标签: Device driver PM

评论(19) 浏览(28037)

Linux PM QoS framework(3)_per-device PM QoS

作者：wowo 发布于：2015-2-26 22:44 分类：电源管理子系统

per-device PM QoS是针对指定设备的QoS framework，背后的思考如下：

1）resume_latency

在Runtime PM的框架下，当device的引用计数减为0的时候，RPM会suspend该device。不过，device进入suspend状态以及从suspend状态resume是需要消耗时间的（相关信息保存在pm domain中），而系统其它实体（如用户空间程序）可能对该设备的响应时间有要求，这就是一种形式的QoS request，称作resume_latency。

per-device PM QoS framework会提供相应的接口，收集指定设备的resume_latency request，并提供给Runtime PM，它在suspend设备时，会考虑这种需求，并决定是否suspend设备。

2）latency_tolerance

一些复杂的设备，在运行状态（active）时，为了节省功耗，也有可能自行进入某些省电状态，相应的，设备的响应速度可能降低。如果该设备足够智能，可能会提供一个回调函数（.set_latency_tolerance，位于dev_pm_info结构中），以便设置最大的延迟容忍时间。这称作latency_tolerance。

对per-device PM QoS来说，需要提供一种机制，收集所有的、针对某个设备的latency_tolerance需求，并汇整出可以满足所有需求的latency_tolerance，通过设备的回调函数告知设备。

3）no power off/remote wakeup

在Runtime PM的框架下，设备suspend之后，还可以进一步通过pm domain关闭该设备的供电，以节省功耗。但关闭供电时，除了要考虑对设备resume_latency的需求之外，还要考虑该设备是否允许关闭供电，以及该设备是否需要作为一个唤醒源（remote wakeup）。

这是另一种形式的QoS request，称作per-device PM QoS flag，表示系统其它实体对该设备的一些特定行为的需求。当前的flag有两种：

PM_QOS_FLAG_NO_POWER_OFF，表示不允许设备断电
PM_QOS_FLAG_REMOTE_WAKEUP，表示设备应具备唤醒功能

这两个flag可以通过或操作，同时生效。

因此，per-device PM QoS framework的功能，就是抽象上面两类需求，包括：向requestor提供QoS request的add、update、remove等API，包括内核空间API和用户空间API；汇整、整理这些request；向电源管理有关的service（主要是pm domain framework）提供汇整后的request信息，以便这些service可以做出正确的决定。

下面将会结合source code(位于drivers/base/power/qos.c中），介绍上面的实现逻辑。

阅读全文>>

标签: Linux Kernel pm_qos per-device

评论(9) 浏览(14317)