wowo@bear20081015：不完全是这样，虽然pm domain接管了，但是还可以调用到driver的suspend：
pm_genpd_suspend->genpd_suspend_dev
《Linux PM domain framework(1)_概述和使用流程》 发表时间：2015-06-24 14:04
bear20081015@wowo：wowo, 我能不能这样理解：
1. 具有pm domain的设备，它根本就无法实现suspend/resume等函数，因为这些都被它的PM domain接管了。所以原本在suspend/resume中实现的内容，都要放在设备的runtime PM中实现了。
2. 没有pm domain的设备，其suspend/resume函数和PM runtime是没有关系的。比如设备在系统suspend之前已经调用了PM runtime，其suspend函数还是会被调到。
《Linux PM domain framework(1)_概述和使用流程》 发表时间：2015-06-24 13:25
wowo@bear20081015：问题1：
如果设备从属于某个pm domain，那么设备的runtime pm就会被pm domain接管，在设备的引用计数为0（调用pm_runtime_put系列函数）时，其pm domain的pm_genpd_runtime_suspend函数会被调用。
pm domain在其下面所有的设备的引用计数为0时，power off 该PM domain（有些例外，例如PM_QOS_FLAG_NO_POWER_OFF等等），使domain的状态为GPD_STATE_POWER_OFF。
因此，如果device所在的pm domain都已经OFF了，device driver的suspend就没有意义了（因为设备已经power off了）。这就是pm domain的初衷：
具有pm domain的设备，如果它允许在runtime suspend的时候被power off，是不需要实现suspend/resume等常规机制的，因为pm domain配合runtime pm，会更彻底。
《Linux PM domain framework(1)_概述和使用流程》 发表时间：2015-06-24 12:19
wowo@bear20081015：据我所知，选频点的一般做法是：
1. 根据SOC的spec，确定soc支持的频率和电压范围。
2. 基于性能和功耗的考量，在允许范围内，选出一些潜在的组合。
3. 通过大规模的老化测试（一般一天测试一个频点，需要尽量多的设备参与），剔除那些不稳定的频点，同时选出可工作的最低和最高频点。
4. 根据实际的应用情况，在cpufreq中保留几个，用作日常调频。一般3~5个就够了。
《linux cpufreq framework(1)_概述》 发表时间：2015-06-24 09:45
bear20081015@wowo, 请教下PM runtime, PM domain, system suspend搅在一起的问题：
1.PM domain和设备在system suspend中的callback之间的关系究竟是什么样的？我看到在power domain的相关函数pm_genpd_XXX中（比如pm_genpd_prepare），都会先判断power domain是否处于off的状态，如果是的话就直接返回。那这是不是意味着在系统suspend过程中，属于这个power domain的设备所有的.prepare/.suspend/.suspend_noirq等函数都不会被调到了？如果是的话，这样做合理么？如果保证power domain off时其设备所处的状态就和比如.suspend中设置的状态一样呢？
2.前面和你讨论过，系统suspend的时候为了不让设备的PM runtime和.suspend等函数一起使用，在系统suspend的不同阶段增加了pm_runtime_get_noresume，__pm_runtime_disable等。但是我发现对于使用PM domain的设备来说，在pm_genpd_prepare中如果发现domain是on的状态，就会直接调__pm_runtime_disable来禁止该dev的pm runtime，这是什么原因呢？是系统suspend一开始就让该设备完全由PM domain来控制么? 谢谢！
《Linux PM domain framework(1)_概述和使用流程》 发表时间：2015-06-24 03:01
bear20081015能否介绍下确定一款SOC的频点和电压的原则或方法？比如拿到一款新的SOC，我们应该给它选定哪些频点和电压呢。个人理解选好了这个，再加上cpufreq的软件框架，才能很好的达到power优化的目标吧？
《linux cpufreq framework(1)_概述》 发表时间：2015-06-24 02:46
von81@printk:可以给个你优化的例子吗？具体哪些点，耗时多少，做了哪些优化，优化后耗时多少。
还有个疑问：把kernel读出来 vs 解压kernel， 更大的kernel读出来的时间肯定更长，优化这个时间 vs 优化解压的时间，哪个更好，要对比一下吧？
就uboot来说，我感觉主要有两个功能，一个是把kernel拷贝到内存，另一个是调试。 在发布的时候，其实调试功能是不需要的，仅需要第一个功能。
firstboot也是可以把kernel拷贝到内存的，这样发布的时候就可以不要uboot了。
ps:
1、firstboot是指把uboot拷贝到内存的这个boot，imx6中可能不是这个名字。
2、建议楼主说明你优化的kernel和uboot版本。 kernel 3.0以上版本，大多用了设备树，uboot具有调试设备树的功能，所以uboot有可能悄悄改了设备树，如果不要uboot，需要确定uboot是如何改了设备树。
3、uboot一般是读取固定大小的kernel和文件系统进内存。例如kernel是2.9M，uboot可能固定读4M，不会去管真正的kernel是多大，建议楼主确认下你的uboot是否是这样。
还有两个记不清楚的地方，说出来供楼主参考。
我以前粗略看过kernel的汇编部分，记得在汇编里好像会把真正的kernel搬运到新的内存地址，这个地方应该也可以优化。
读内核时，开启dma，应该可以读的更快吧
《kernel启动优化》 发表时间：2015-06-23 16:53
wowo@bear20081015：涨姿势了，原来cache里面的内容已经pre-decode了，这样可以节省很多decode动作，进而节省power。多谢分享。
《计算机科学基础知识（一）:The Memory Hierarchy》 发表时间：2015-06-23 09:13
bear20081015@linuxer：@linuxer,
linuxer。
我问了下ARM的人，他们的意思是说icache里面确实存储的是40个bit，是memory中的32bit指令经过predecoder得到的。还给了一个转换公式，不过我尝试了一下，似乎不是很对，还在等他们的进一步回复。供你参考。
[From Jim Sykes - ARM Technical Support]
Cortex-A5/A7/A53 store a special extended format in the I$ which is:
For Cortex-A5/A7: 18 bits Thumb / 36 bits ARM
For Cortex-A53: 20 bits Thumb / 40 bits ARM aarch32 or aarch64
This is related to changes to the instruction decode logic – a predecoder is added before the I$ - the main decoder is simplified and this leads to power and area savings.
We do not have a script or documentation for this I$ format, however the tarmac logger contains functions to decode the instructions – when used with code below.
The below SystemVerilog code can reverse the translations done in the predecode process for Cortex-A53.
This includes snip