DroidPhone-CSDN博客

原创已知二叉树的前序遍历和中序遍历，如何得到它的后序遍历？

对一颗二叉树进行遍历，我们可以采取3中顺序进行遍历，分别是前序遍历、中序遍历合后序遍历。这三种方式是以访问父节点的顺序来进行命名的。假设父节点是N，左节点是L，右节点是R，那么对应的访问遍历顺序如下：

2014-07-23 17:28:26 10082 5

原创 Linux SPI总线和设备驱动架构之四：SPI数据传输的队列化

我们知道，SPI数据传输可以有两种方式：同步方式和异步方式。所谓同步方式是指数据传输的发起者必须等待本次传输的结束，期间不能做其它事情，用代码来解释就是，调用传输的函数后，直到数据传输完成，函数才会返回。而异步方式则正好相反，数据传输的发起者无需等待传输的结束，数据传输期间还可以做其它事情，用代码来解释就是，调用传输的函数后，函数会立刻返回而不用等待数据传输完成，我们只需设置一个回调函数，传输完成

2014-04-28 21:00:55 27658 9

原创 Linux SPI总线和设备驱动架构之三：SPI控制器驱动

通过第一篇文章，我们已经知道，整个SPI驱动架构可以分为协议驱动、通用接口层和控制器驱动三大部分。其中，控制器驱动负责最底层的数据收发工作，为了完成数据的收发工作，控制器驱动需要完成以下这些功能：1. 申请必要的硬件资源，例如中断，DMA通道，DMA内存缓冲区等等；2. 配置SPI控制器的工作模式和参数，使之可以和相应的设备进行正确的数据交换工作；3. 利用通用接口层

2014-04-23 23:03:48 21091 2

原创 Linux SPI总线和设备驱动架构之二：SPI通用接口层

通过上一篇文章的介绍，我们知道，SPI通用jie k

2014-04-18 17:02:38 24242 6

原创 Linux SPI总线和设备驱动架构之一：系统概述

/*****************************************************************************************************/声明：本博内容均由http://blog.csdn.net/droidphone原创，转载请注明出处，谢谢！/**************************************

2014-04-12 08:36:45 31540 5

原创 ALSA声卡驱动中的DAPM详解之七：dapm事件机制（dapm event）

前面的六篇文章，我们已经讨论了dapm关于动态电源管理的有关知识，包括widget的创建和初始化，widget之间的连接以及widget的上下电顺序等等。本章我们准备讨论dapm框架中的另一个机制：事件机制。通过dapm事件机制，widget可以对它所关心的dapm事件做出反应，这种机制对于扩充widget的能力非常有用，例如，对于那些位于codec之外的widget，好像喇叭功放、外部的前置放大

2013-11-09 01:05:58 26624 10

原创 ALSA声卡驱动中的DAPM详解之六：精髓所在，牵一发而动全身

设计dapm的主要目的之一，就是希望声卡上的各种部件的电源按需分配，需要的就上电，不需要的就下电，使得整个音频系统总是处于最小的耗电状态，最主要的就是，这一切对用户空间的应用程序是透明的，也就是说，用户空间的应用程序无需关心那个部件何时需要电源，它只要按需要设定好音频路径，播放音频数据，暂停或停止，dapm框架会根据音频路径，完美地对各种部件的电源进行控制，而且精确地按某种顺序进行，防止上下电过程

2013-11-04 23:20:41 27988 12

原创 ALSA声卡驱动中的DAPM详解之五：建立widget之间的连接关系

前面我们主要着重于codec、platform、machine驱动程序中如何使用和建立dapm所需要的widget，route，这些是音频驱动开发人员必须要了解的内容，经过前几章的介绍，我们应该知道如何在alsa音频驱动的3大部分（codec、platform、machine）中，按照所使用的音频硬件结构，定义出相应的widget，kcontrol，以及必要的音频路径，而在本章中，我们将会深入da

2013-11-04 21:25:32 32891 6

原创 ALSA声卡驱动中的DAPM详解之四：在驱动程序中初始化并注册widget和route

前几篇文章我们从dapm的数据结构入手，了解了代表音频控件的widget，代表连接路径的route以及用于连接两个widget的path。之前都是一些概念的讲解以及对数据结构中各个字段的说明，从本章开始，我们要从代码入手，分析dapm的详细工作原理：如何注册widget如何连接两个widget一个widget的状态裱画如何传递到整个音频路径中/*******************

2013-11-01 22:41:41 28139 3

原创 ALSA声卡驱动中的DAPM详解之三：如何定义各种widget

/*****************************************************************************************************/声明：本博内容均由http://blog.csdn.net/droidphone原创，转载请注明出处，谢谢！/**************************************

2013-10-24 21:01:12 34165 14

原创 ALSA声卡驱动中的DAPM详解之二：widget-具备路径和电源管理信息的kcontrol

上一篇文章中，我们介绍了音频驱动中对基本控制单元的封装：kcontrol。利用kcontrol，我们可以完成对音频系统中的mixer，mux，音量控制，音效控制，以及各种开关量的控制，通过对各种kcontrol的控制，使得音频硬件能够按照我们预想的结果进行工作。同时我们可以看到，kcontrol还是有以下几点不足：只能描述自身，无法描述各个kcontrol之间的连接关系；没有相应的电源管理

2013-10-23 20:31:07 33844 10

原创 ALSA声卡驱动中的DAPM详解之一：kcontrol

DAPM是Dynamic Audio Power Management的缩写，直译过来就是动态音频电源管理的意思，DAPM是为了使基于linux的移动设备上的音频子系统，在任何时候都工作在最小功耗状态下。DAPM对用户空间的应用程序来说是透明的，所有与电源相关的开关都在ASoc core中完成。用户空间的应用程序无需对代码做出修改，也无需重新编译，DAPM根据当前激活的音频流（playback/c

2013-10-18 15:19:50 60305 19

原创 Linux动态频率调节系统CPUFreq之三：governor

在上一篇文章中，介绍了cpufreq的core层，core提供了cpufreq系统的初始化，公共数据结构的建立以及对cpufreq中其它子部件提供注册功能。core的最核心功能是对policy的管理，一个policy通过cpufreq_policy结构中的governor字段，和某个governor像关联，本章的内容正是要对governor进行讨论。/*********************

2013-07-30 12:48:02 22515 7

原创 Linux动态频率调节系统CPUFreq之二：核心（core）架构与API

上一节中，我们大致地讲解了一下CPUFreq在用户空间的sysfs接口和它的几个重要的数据结构，同时也提到，CPUFreq子系统把一些公共的代码逻辑组织在一起，构成了CPUFreq的核心部分，这些公共逻辑向CPUFreq和其它内核模块提供了必要的API，像cpufreq_governor、cpufreq_driver等模块通过这些API来完成一个完整的CPUFreq体系。这一节我们就来讨论一下核心

2013-07-20 19:00:59 23578 6

原创 Linux动态频率调节系统CPUFreq之一：概述

随着技术的发展，我们对CPU的处理能力提出了越来越高的需求，芯片厂家也对制造工艺不断地提升。现在的主流PC处理器的主频已经在3GHz左右，就算是智能手机的处理器也已经可以工作在1.5GHz以上，可是我们并不是时时刻刻都需要让CPU工作在最高的主频上，尤其是移动设备和笔记本电脑，大部分时间里，CPU其实工作在轻负载状态下，我们知道：主频越高，功耗也越高。为了节省CPU的功耗和减少发热，我们有必要根据

2013-07-17 21:43:50 41068 7

翻译 Linux输入子系统：多点触控协议 -- multi-touch-protocol.txt

2012-12-25 19:30:04 29506 6

翻译 Linux输入子系统：输入设备编程指南 -- input-programming.txt

输入设备编程指南（Programming input drivers）~~~~~~~~~~~~~~~~~~~~~~~~~1. 新建一个输入设备驱动程序~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~1.0 一个最简单的例子~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2012-12-25 10:14:13 9955 2

翻译 Linux输入子系统：事件的编码 -- event-codes.txt

输入系统协议用类型types和编码codecs来表示输入设备的值并用此来通知用户空间的应用程序。这篇文档对这些类型和编码进行了说明并且指出什么时候和如何使用这些类型和编码。一个单一的硬件事件可以产生多个输入事件，每个输入事件包含一个单一数据项的新的数据值。EV_SYN是一个特别的事件类型，它用来把同一时刻产生的多个输入数据分割为多个数据包。在下面的描述中，术语事件（event）是指一个涵盖类

2012-12-25 09:57:39 30221 2

翻译 Linux输入子系统：input.txt

2012-12-25 09:37:12 11290 1

原创 Linux时间子系统之八：动态时钟框架（CONFIG_NO_HZ、tickless）

在前面章节的讨论中，我们一直基于一个假设：Linux中的时钟事件都是由一个周期时钟提供，不管系统中的clock_event_device是工作于周期触发模式，还是工作于单触发模式，也不管定时器系统是工作于低分辨率模式，还是高精度模式，内核都竭尽所能，用不同的方式提供周期时钟，以产生定期的tick事件，tick事件或者用于全局的时间管理（jiffies和时间的更新），或者用于本地cpu的进程统计、时

2012-10-27 16:01:44 28904 10

原创 Linux时间子系统之七：定时器的应用--msleep()，hrtimer_nanosleep()

我们已经在前面几章介绍了低分辨率定时器和高精度定时器的实现原理，内核为了方便其它子系统，在时间子系统中提供了一些用于延时或调度的API，例如msleep，hrtimer_nanosleep等等，这些API基于低分辨率定时器或高精度定时器来实现，本章的内容就是讨论这些方便、好用的API是如何利用定时器系统来完成所需的功能的。/***********************************

2012-10-23 22:04:54 27431 1

原创 Linux时间子系统之六：高精度定时器（HRTIMER）的原理和实现

上一篇文章，我介绍了传统的低分辨率定时器的实现原理。而随着内核的不断演进，大牛们已经对这种低分辨率定时器的精度不再满足，而且，硬件也在不断地发展，系统中的定时器硬件的精度也越来越高，这也给高分辨率定时器的出现创造了条件。内核从2.6.16开始加入了高精度定时器架构。在实现方式上，内核的高分辨率定时器的实现代码几乎没有借用低分辨率定时器的数据结构和代码，内核文档给出的解释主要有以下几点：

2012-10-19 23:05:01 94481 15

原创 Linux时间子系统之五：低分辨率定时器的原理和实现

利用定时器，我们可以设定在未来的某一时刻，触发一个特定的事件。所谓低分辨率定时器，是指这种定时器的计时单位基于jiffies值的计数，也就是说，它的精度只有1/HZ，假如你的内核配置的HZ是1000，那意味着系统中的低分辨率定时器的精度就是1ms。早期的内核版本中，内核并不支持高精度定时器，理所当然只能使用这种低分辨率定时器，我们有时候把这种基于HZ的定时器机制成为时间轮：time wheel。虽

2012-10-13 00:21:13 25410 3

原创 Linux时间子系统之四：定时器的引擎：clock_event_device

早期的内核版本中，进程的调度基于一个称之为tick的时钟滴答，通常使用时钟中断来定时地产生tick信号，每次tick定时中断都会进行进程的统计和调度，并对tick进行计数，记录在一个jiffies变量中，定时器的设计也是基于jiffies。这时候的内核代码中，几乎所有关于时钟的操作都是在machine级的代码中实现，很多公共的代码要在每个平台上重复实现。随后，随着通用时钟框架的引入，内核需要支持高

2012-09-28 16:02:26 31250 7

原创 Linux时间子系统之三：时间的维护者：timekeeper

本系列文章的前两节讨论了用于计时的时钟源：clocksource，以及内核内部时间的一些表示方法，但是对于真实的用户来说，我们感知的是真实世界的真实时间，也就是所谓的墙上时间，clocksource只能提供一个按给定频率不停递增的周期计数，如何把它和真实的墙上时间相关联？本节的内容正是要讨论这一点。1. 时间的种类内核管理着多种时间，它们分别是：RTC时间wall time：

2012-09-19 12:37:58 40581 6

原创 Linux时间子系统之二：表示时间的单位和结构

人们习惯用于表示时间的方法是：年、月、日、时、分、秒、毫秒、星期等等，但是在内核中，为了软件逻辑和代码的方便性，它使用了一些不同的时间表示方法，并为这些表示方法定义了相应的变量和数据结构，本节的内容就是阐述这些表示方法的意义和区别。/*****************************************************************************

2012-09-14 17:18:58 31236 3

原创 Linux时间子系统之一：clock source（时钟源）

clock source用于为linux内核提供一个时间基线，如果你用linux的date命令获取当前时间，内核会读取当前的clock source，转换并返回合适的时间单位给用户空间。在硬件层，它通常实现为一个由固定时钟频率驱动的计数器，计数器只能单调地增加，直到溢出为止。时钟源是内核计时的基础，系统启动时，内核通过硬件RTC获得当前时间，在这以后，在大多数情况下，内核通过选定的时钟源更新实时时

2012-09-13 22:25:12 38446 7

原创 Linux中断（interrupt）子系统之五：软件中断（softIRQ）

软件中断（softIRQ）是内核提供的一种延迟执行机制，它完全由软件触发，虽然说是延迟机制，实际上，在大多数情况下，它与普通进程相比，能得到更快的响应时间。软中断也是其他一些内核机制的基础，比如tasklet，高分辨率timer等。/*********************************************************************************

2012-05-01 23:24:53 51296 16

原创 Linux中断（interrupt）子系统之四：驱动程序接口层 & 中断通用逻辑层

在本系列文章的第一篇：Linux中断（interrupt）子系统之一：中断系统基本原理，我把通用中断子系统分为了4个层次，其中的驱动程序接口层和中断通用逻辑层的界限实际上不是很明确，因为中断通用逻辑层的很多接口，既可以被驱动程序使用，也可以被硬件封装层使用，所以我把这两部分的内容放在一起进行讨论。本章我将会讨论这两层对外提供的标准接口和内部实现机制，几乎所有的接口都是围绕着irq_desc和i

2012-04-27 00:20:16 23148 7

原创 Linux中断（interrupt）子系统之三：中断流控处理层

1. 中断流控层简介早期的内核版本中，几乎所有的中断都是由__do_IRQ函数进行处理，但是，因为各种中断请求的电气特性会有所不同，又或者中断控制器的特性也不同，这会导致以下这些处理也会有所不同：何时对中断控制器发出ack回应；mask_irq和unmask_irq的处理；中断控制器是否需要eoi回应？何时打开cpu的本地irq中断？以便允许irq的嵌套；中断数据结构的同步和保护

2012-04-24 17:20:15 25507 15

原创 Android Audio System线性音量和对数音量的转换

Android的音频系统的代码中，应用程序对每个音频流的音量做出调整后，最终会转换为一个系数K，所有的音频数据在输出到硬件之前，都要乘以系数K，只要应用程序发出调整音量的调用，中间层的Audio System就会重新计算系数K的值。对应用程序来说，音量控制通常都是按照线性进行调整的，比如对于具有15级音量的音频流来说，我们预期每级的音量变化都是相当的，也就是说：从第5级调到第6级，和从第7级调到第

2012-04-19 20:18:45 19207 2

原创 Linux中断（interrupt）子系统之二：arch相关的硬件封装层

Linux的通用中断子系统的一个设计原则就是把底层的硬件实现尽可能地隐藏起来，使得驱动程序的开发人员不用关注底层的实现，要实现这个目标，内核的开发者们必须把硬件相关的内容剥离出来，然后定义一些列标准的接口供上层访问，上层的开发人员只要知道这些接口即可完成对中断的进一步处理和控制。对底层的封装主要包括两部分：实现不同体系结构中断入口，这部分代码通常用asm实现；中断控制器进行封装和实现；

2012-04-18 23:16:07 24816 8

原创 Linux中断（interrupt）子系统之一：中断系统基本原理

这个中断系列文章主要针对移动设备中的Linux进行讨论，文中的例子基本都是基于ARM这一体系架构，其他架构的原理其实也差不多，区别只是其中的硬件抽象层。内核版本基于3.3。虽然内核的版本不断地提升，不过自从上一次变更到当前的通用中断子系统后，大的框架性的东西并没有太大的改变。 /********************************************************

2012-04-12 21:52:48 65093 23

原创自旋锁spin_lock和raw_spin_lock

本文不打算详细探究spin_lock的详细实现机制，只是最近对raw_spin_lock的出现比较困扰，搞不清楚什么时候用spin_lock，什么时候用raw_spin_lock，因此有了这篇文章。/**********************************************************************************************

2012-03-26 20:53:23 24067 8

原创 Linux ALSA声卡驱动之八：ASoC架构中的Platform

1. Platform驱动在ASoC中的作用前面几章内容已经说过，ASoC被分为Machine，Platform和Codec三大部件，Platform驱动的主要作用是完成音频数据的管理，最终通过CPU的数字音频接口（DAI）把音频数据传送给Codec进行处理，最终由Codec输出驱动耳机或者是喇叭的音信信号。在具体实现上，ASoC有把Platform驱动分为两个部分：snd_soc_plat

2012-03-13 14:56:49 67340 38

原创 Linux ALSA声卡驱动之七：ASoC架构中的Codec

1. Codec简介在移动设备中，Codec的作用可以归结为4种，分别是：对PCM等信号进行D/A转换，把数字的音频信号转换为模拟信号对Mic、Linein或者其他输入源的模拟信号进行A/D转换，把模拟的声音信号转变CPU能够处理的数字信号对音频通路进行控制，比如播放音乐，收听调频收音机，又或者接听电话时，音频信号在codec内的流通路线是不一样的对音频信号做出相应的处理，例如音

2012-02-23 14:12:29 71457 25

原创 Linux ALSA声卡驱动之六：ASoC架构中的Machine

前面一节的内容我们提到，ASoC被分为Machine、Platform和Codec三大部分，其中的Machine驱动负责Platform和Codec之间的耦合以及部分和设备或板子特定的代码，再次引用上一节的内容：Machine驱动负责处理机器特有的一些控件和音频事件（例如，当播放音频时，需要先行打开一个放大器）；单独的Platform和Codec驱动是不能工作的，它必须由Machine驱动把它们结

2012-02-03 19:09:12 77000 23

原创 Linux ALSA声卡驱动之五：移动设备中的ALSA（ASoC）

1. ASoC的由来ASoC--ALSA System on Chip ，是建立在标准ALSA驱动层上，为了更好地支持嵌入式处理器和移动设备中的音频Codec的一套软件体系。在ASoc出现之前，内核对于SoC中的音频已经有部分的支持，不过会有一些局限性： Codec驱动与SoC CPU的底层耦合过于紧密，这种不理想会导致代码的重复，例如，仅是wm8731的驱动，当时Lin

2012-01-17 14:16:09 55951 13

原创翻译：Linux的电源管理架构

2011-08-05 19:16:57 21355 5

原创基于Android的Linux内核的电源管理：Early Suspend

1. 用户空间的接口在kernel/power/main.c中，定义了一组sysfs的属性文件，其中一个定义是：power_attr(state);把这个宏展开后:staticstruct kobj_attribute state_attr = { \ .attr ={ \

2011-07-28 20:40:29 21939 5

空空如也

空空如也