请教WOWO和其它高手一个电源管理的问题.
本文是原「蜗窝讨论区」的历史存档（2016-10-31），来自版块「Linux kernel技术问答」，共 7 帖。讨论区已停止服务，此处仅供查阅。
我们的产品期望在系统待机时, 系统仍能处理ethernet 和USB的通信 (至少能把系统唤醒), 甚至wifi traffic.
我们的产品在一天98%以上的时间里是没有作业需要处理的,但系统要保证有响应作业请求的能力(响应时间大约为人的反映时间即可), 因此系统在大部分时间里必须处于低功耗状态.但系统又必须有处理用户新请求的能力,因此网络和USB不能关掉.
我们的系统采用A53 多处理器 (SMP) + R4低功耗小处理器 结构, linux只运行在A53 SMP 多处理器上, R4 侧跑其它RTOS.
我的理解是,我们LINUX不能采用传统的hibernate或suspend to ram 模式, 因为在这种模式下,所有的DEVICE是停止工作的. 我不清楚ethernt or USB port event能不能作为一个wake up source. 即使能作为wake up source, 系统enter/exit hibernate or suspend to ram的时间也比较长, 如果系统上ethernet traffic (尤其是广播/组播包较多), 系统需要频繁enter/exit STD or STR.
我们目前想采用的solution是: 当系统没有作业处理时, 把non-boot SMP cores 关掉, 同时把其它相关模块关掉 (比如其它协处理器, GPU) , 让boot core A53 core 0来应付网络和USB traffic, 我想一个core来应付网络协议和USB Port应该已经足够了. 同时, 我们扩展了更多的cpudile states, 在boot core 最深层 CPUIDLE state时, linux把自己suspend (waiting r4 to turn off A53 boot core), 同时让r4检测ethernet mac+phy 和 USB port中断, 在r4检测到这些中断时, 它把linux唤醒 (re-power on it, A53 boot core will begin to run from the specific reset vector address which we set before suspend boot core). When A53 inform r4 that it can power off A53 core 0, it also indicate system can now enter low power mode, so r4 can turn off, or by pass some PLLs, power down some unused PIN pads, internal other blocks or SRAM, and set DDR memory into self refresh mode.
该方案目前能工作,但我不确定是不是最佳方案, 或能不能大规模的应用的产品中. 它的缺点可能是: 1, The timing required to enter/exist low power status, which including A53 core 0 suspend itself, R4 set system enter/exit low power status, and A53 exist suspend status. I have not measure these timing, also currently don’t sure the detailed allowed delay for all our TCP/IP application. 2, Seems when CPU enter CPUIDLE state, we still can not assure all devices are idle, maybe Ethernent MAC or USB port DMA still working (I need to understand CPUidle governor well), if r4 set DDR enter self –refresh mode, but some DMA or other bus master still try to access it, maybe system will crash. But maybe I can exploit some other feature that DDR memory controller can dynamically decide when to enter self-refresh mode, and exit this mode when it find some master still try to access DDR. Our datasheet said it support this feature.
不知道wowo对上述方案有何看法? 市场上其它平台是如何在顶功耗下保持ethernet和USB通信的?
我们以前其它平台上是在低功耗时, 在R4小处理器运行简化的ethernet 和 USB 驱动, 如果检测到是新的用户数据和请求(没有运行整个TCP/IP 协议栈), 在唤醒主处理器是把受到的数据放置在主处理器相关的驱动buffer里(主处理器的驱动程序都是我们自己的, 其结构也了解的很清楚,所以能够这样做), 但在LINUX平台上, R4把数据直接放置在A53 linux 侧的驱动buffer里可能需要较大的工作量, 所以目前没考虑这种做法.
谢谢.
马六甲2017 写道： 我们的产品期望在系统待机时, 系统仍能处理ethernet 和USB的通信 (至少能把系统唤醒), 甚至wifi traffic.
我们的产品在一天98%以上的时间里是没有作业需要处理的,但系统要保证有响应作业请求的能力(响应时间大约为人的反映时间即可), 因此系统在大部分时间里必须处于低功耗状态.但系统又必须有处理用户新请求的能力,因此网络和USB不能关掉.
要求的唤醒时间是人的反应时间的话，我觉得应该不难做（假设人的反应时间是100ms）。 至于USB、Ethernet、WIFI等是否可以唤醒，应该不是瓶颈，肯定是没有问题的。 但涉及到网络，有一点比较麻烦，举个例子：假设你的应用场景是client-server的场景，而你的设备是client的话，server应该没有义务主动给你推送数据，也就是说设备要定时查询？这里把应用场景层面的事情想清楚比较重要，不要有逻辑问题。 至于用哪种电源管理方法，设备层面上，我觉得你应该用RPM（runtime PM）。 cpu层面，动态开关核+cpuidle满足性能需求应该没有问题，至于是否满足功耗需求，就不得而知了。 最后，str并不是不能用，如果结合着RPM，100ms内肯定是毫无压力的，具体你可以尝试一下。
谢谢回复.
我们的设备既做server, 有些应用又做client.在以前使用其它OS时, 网络模块的owner要求enter/exit 低功耗的时间不能多于200ms, 否则有些应用会出问题.
>>>要求的唤醒时间是人的反应时间的话，我觉得应该不难做（假设人的反应时间是100ms）。 >>>最后，str并不是不能用，如果结合着RPM，100ms内肯定是毫无压力的，具体你可以尝试一下。 如果所有process/thread freeze/unfreeze, device (core devices) suspend/resume, other platform related code ...能在100ms完成, 我们就可以尝试STR. RPM的概念还不太清楚, 接下来花些时间熟悉一下.
>>>server应该没有义务主动给你推送数据，也就是说设备要定时查询？ 不需要查询,在我们平台上, R4一侧可以检测到ethernet, usb部分的中断状态, 并以此来唤醒A53.
想到一个问题,如果采用STR, 整个enter/exit过程需要50-100ms的话,唤醒延迟不是问题, 但系统的低功耗特性可能还是不佳, 因为公司内部网络上广播包,ICMP等各种包的频率可能还是比较高的, 这样系统会反复处于enter/exit 低功耗状态的切换中, 实际停留在低功耗状态的时间百分比不大.
马六甲2017 写道： 谢谢回复.
我们的设备既做server, 有些应用又做client.在以前使用其它OS时, 网络模块的owner要求enter/exit 低功耗的时间不能多于200ms, 否则有些应用会出问题.
>>>要求的唤醒时间是人的反应时间的话，我觉得应该不难做（假设人的反应时间是100ms）。 >>>最后，str并不是不能用，如果结合着RPM，100ms内肯定是毫无压力的，具体你可以尝试一下。 如果所有process/thread freeze/unfreeze, device (core devices) suspend/resume, other platform related code ...能在100ms完成, 我们就可以尝试STR. RPM的概念还不太清楚, 接下来花些时间熟悉一下.
>>>server应该没有义务主动给你推送数据，也就是说设备要定时查询？ 不需要查询,在我们平台上, R4一侧可以检测到ethernet, usb部分的中断状态, 并以此来唤醒A53.
device (core devices) suspend/resume的事情在RPM中已经做过，所以这一块可以省下来。
马六甲2017 写道： 想到一个问题,如果采用STR, 整个enter/exit过程需要50-100ms的话,唤醒延迟不是问题, 但系统的低功耗特性可能还是不佳, 因为公司内部网络上广播包,ICMP等各种包的频率可能还是比较高的, 这样系统会反复处于enter/exit 低功耗状态的切换中, 实际停留在低功耗状态的时间百分比不大.
这个要估算一下各种包的频率。 实在不能用str，就像你所说的方案一样，一个core专门处理网络包，加上RPM让设备省电，然后动态调整CPU频率，功耗也是可控的。
谢谢. 我再弄弄清楚RPM.
wowo 写道：
马六甲2017 写道： 想到一个问题,如果采用STR, 整个enter/exit过程需要50-100ms的话,唤醒延迟不是问题, 但系统的低功耗特性可能还是不佳, 因为公司内部网络上广播包,ICMP等各种包的频率可能还是比较高的, 这样系统会反复处于enter/exit 低功耗状态的切换中, 实际停留在低功耗状态的时间百分比不大.
这个要估算一下各种包的频率。 实在不能用str，就像你所说的方案一样，一个core专门处理网络包，加上RPM让设备省电，然后动态调整CPU频率，功耗也是可控的。