@bear20081015:不完全是这样,虽然pm domain接管了,但是还可以调用到driver的suspend:
pm_genpd_suspend->genpd_suspend_dev
《Linux PM domain framework(1)_概述和使用流程》 发表时间:2015-06-24 14:04
@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
@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
@bear20081015:据我所知,选频点的一般做法是:
1. 根据SOC的spec,确定soc支持的频率和电压范围。
2. 基于性能和功耗的考量,在允许范围内,选出一些潜在的组合。
3. 通过大规模的老化测试(一般一天测试一个频点,需要尽量多的设备参与),剔除那些不稳定的频点,同时选出可工作的最低和最高频点。
4. 根据实际的应用情况,在cpufreq中保留几个,用作日常调频。一般3~5个就够了。
《linux cpufreq framework(1)_概述》 发表时间:2015-06-24 09:45
@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
能否介绍下确定一款SOC的频点和电压的原则或方法?比如拿到一款新的SOC,我们应该给它选定哪些频点和电压呢。个人理解选好了这个,再加上cpufreq的软件框架,才能很好的达到power优化的目标吧?
《linux cpufreq framework(1)_概述》 发表时间:2015-06-24 02:46
@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
@bear20081015:涨姿势了,原来cache里面的内容已经pre-decode了,这样可以节省很多decode动作,进而节省power。多谢分享。
《计算机科学基础知识(一):The Memory Hierarchy》 发表时间:2015-06-23 09:13
@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