蜗窝科技

@wowo：wowo, 我能不能这样理解： 1. 具有pm domain的设备，它根本就无法实现suspend/resume等函数，因为这些都被它的PM domain接管了。所以原本在suspend/resume中实现的内容，都要放在设备的runtime PM中实现了。 2. 没有pm domain的设备，其suspend/resume函数和PM runtime是没有关系的。比如设备在系统suspend之前已经调用了PM runtime，其suspend函数还是会被调到。

@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，会更彻底。

@bear20081015：据我所知，选频点的一般做法是： 1. 根据SOC的spec，确定soc支持的频率和电压范围。 2. 基于性能和功耗的考量，在允许范围内，选出一些潜在的组合。 3. 通过大规模的老化测试（一般一天测试一个频点，需要尽量多的设备参与），剔除那些不稳定的频点，同时选出可工作的最低和最高频点。 4. 根据实际的应用情况，在cpufreq中保留几个，用作日常调频。一般3~5个就够了。

@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来控制么? 谢谢！

能否介绍下确定一款SOC的频点和电压的原则或方法？比如拿到一款新的SOC，我们应该给它选定哪些频点和电压呢。个人理解选好了这个，再加上cpufreq的软件框架，才能很好的达到power优化的目标吧？

@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，应该可以读的更快吧

@bear20081015：涨姿势了，原来cache里面的内容已经pre-decode了，这样可以节省很多decode动作，进而节省power。多谢分享。

@Jackson：是啊，没办法，这是guoqing。 我用的是公司邮箱，是可以用的。

@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 snippets of code which show how to turn the 40-bit encoding in the I-cache into the 32-bit memory view (or at least as close as possible, the translation isn’t entirely two-way). For the code below "icb_encoding_for_reconstruction" is the 40-bit value from the I-cache, and "pfb_to_raw_encoding" is the 32-bit memory view of that value. ARM A64: if (icb_encoding_for_reconstruction[18:13] == 6'b000000) begin // We need first to check if the original encoding was undef or unpred pfb_to_raw_encoding[31:28] = icb_encoding_for_reconstruction[39:36]; pfb_to_raw_encoding[27:0] = {icb_encoding_for_reconstruction[11:0],icb_encoding_for_reconstruction[35:20]}; end else begin // normal case pfb_to_raw_encoding[31:0] = t32_to_a64(icb_encoding_for_reconstruction); end

@wowo：Gmail登录不上了