Android Linu DVFS分析和总结分析和总结.docxVIP

Android Linux DVFS Android Linux DVFS--动态电压频率调整 (2013-01-07 13:44:50.0) 标签： 分类：android 开发 Linux 低功耗研究也有一段时间了，基本把低功耗的实现方式想清楚了（主要分成机制和策略），这段时间的工作主要在机制上。暂时想实现的主要的机制有：cpu 级，设备驱动级，系统平台级。管理颗粒度不断递增，形成三驾马 车齐驱的形势。 cpu 级：主要实现比较容易的在系统处于目标在于频繁发生、更高粒度的电源状态改变，主要的实现方式为 idle， 包括今天的主要想讲的动态主频。 设备驱动级：主要实现对单个设备驱动的管理 （suspend，resume 等），通过系统监测将闲置的设备，通 过从用户态对 sys 文件目录动态进行单个驱动设备的管理， 置于省电模式。 系统平台级：目标在于管理较大的、非常见的重大电源状态改变，用于减少产品设备在长时间的空闲之后，减 少电源消耗 。主要实现方式是依托 linux 内核所支持的 apm 技术，实现整个系统的睡眠/恢复（sleep） 这几个层次其实并不是相互独立的，都是相互交叉的，比如系统平台级的睡眠不可避免会涉及到 cpu 的sleep 模式和设备驱动的挂起，而动态主频的实现除了 cpu 本身的支持也需要外围驱动随着主频变化做出相应的适应活动。因 此这里的分级只是一种粗范围的，逻辑上的分层。 前段时间还调研了一下 IBM 和 Monta Vista 搞得那套DPM（Dynamic Power Management）机制，看了不少论文和观点，总的感觉就是太过复杂而且也不是很实用，感觉噱头大过实际功效，（因此这套机制始终还不能进入内核的 mainline），言归正传，还是重点讲述下 cpufreq 技术。 为什么要 cpufreq？ 关于要不要实现 cpufreq 技术，我也纠结过，一个原因是：当时对内核如何提供这么一套动态变频的机制还不 了解，只觉得应该非常麻烦，因为涉及到外围驱动的参数更 新，另外一个原因是：在 SEP4020 这种体量的处理器上跑linux，即使运行在最高频率时的处理能力可能也不是很富余， 我再给它降频还有没有意义？挣扎之后还是觉得要实现它， 我也给自己列了这么几条原因： 虽然 cpu 在板级中已不是主要的耗电源，但是仍然占着举足轻重的位置，功耗机制到最后就是几毫安几毫 安的扣了，降频肯定能在一定程序上节约功耗那我为什么不 采用？ 细化功耗管理的颗粒度，为应用程序提供更多的 功耗节省机制 对普通的应用，系统可以运行在维持平台运作的 最低频率，在有处理任务时，变频机制会自动切换到合适的 高主频，并且在任务结束时重回省电的低主频，这样就解决 了我之前的第二个疑惑。 SEP4020 在运行在 88M 时板级功耗为:222mA SEP4020 在运行在 56M 时板级功耗为:190mA， 降低 14% SEP4020 在运行在 32M 时板级功耗为:160mA， 降低 28% 实现的一些工作是我们一直需要去做但是一直没有动力做的 变频会涉及到大量模块的参数的重新配置，作为cpu 原厂，我们需要把这些参数彻底掌握 对这些参数的充分理解，能对现有系统进行优化， 提升整体系统的效率，比如使用发现一些参数还是太过保守(sdram,nand),我们的通用配置在系统降为 32M 时仍能正常工作。 可行性论证没有问题：偶然看到 armkiller 同志提供的 nand 驱动代码中有变频的实现（这里非常感谢armkiller），网上这方面的文章很少，于是翻阅了 linux 内核源码中自带的/documentation/cpufreq 后，对这种机制大概有一定的了解（linux 中的 documentation 是个好东东），也看到了一些处理器厂商为自己的 cpu 已经实现了的代码，如sa1100，pxa 系列。 内核所提供的这种 cpufreq 技术的机制 1) 目的： 变频技术是指 CPU 硬件本身支持在不同的频率下运行，系统在运行过程中可以根据随时可能发生变化的系统负载情况动态在这些不同的运行频率之间进行切换，从而达到对性 能和功耗做到二者兼顾的目的。 虽然多个处理器生产厂家都提供了对变频技术的支持，但是 其硬件实现和使用方法必然存在着细微甚至巨大的差别。这 就使得每个处理器生产厂家都需要按照其特殊的硬件实现和使用方法向内核中添加代码，从而让自己产品中的变频技 术在 Linux 中得到支持和使用。然而，这种内核开发模式所导致的后果是各个厂家的实现代码散落在 Linux 内核代码树的各个角落里，各种不同的实现之间没有任何代码是共享的，这给内核的维护以及将来添加对新的产品的支持都带来了巨大的开销，并直接导致了 cpufreq