蜗窝科技

@fire：1. 什么时候会使用PM resume唤醒Kernel呢？
====================================
我不太确定您这里的“PM resume”指的是什么，是指System sleep过程中的resume动作（和Runtime PM对应）吗？如果是的话，resume是和suspend成对出现的，只有suspend了，才会resume。
2. 一般情况下，唤醒源是那些没有被disable的中断，电源芯片应该也是其中的一种，和具体系统的设计有关。
3. 我们系统上的pm resume代码如下， 我想问下，系统挂起后，是不是只要PM resume之后，才能接收到runtime resume？
======================================================
这个问题的本质是Runtime PM和System sleep（suspend&resume etc.）之间的交互， 我一直没有来得及写。您可以先参考“Documentation/power/runtime_pm.txt”中的相关的内容，这里我们先简单的讨论一下。
        a）就某个设备而言，suspend的过程中，RPM和System sleep之间的关系可以分为三种：一，先RPM suspend，后System sleep suspend；二，先System sleep suspend，后RPM suspend；三，RPM suspend和System sleep suspend之间互相交叉。
        b）显然，kernel power managerment的同步机制应该会保证第三种情况不会发生，就先忽略。
        c）第二种情况，由于先System sleep suspend，情况比较简单，PM core会在prepare阶段（suspend_devices_and_enter->dpm_suspend_start->dpm_prepare->device_prepare）,get一次RPM的引用计数（pm_runtime_get_noresume），以保证系统不会再RPM suspend，此后的过程，就是正常的suspend流程。因此这种情况也不会发生。
        d）第一种情况有些复杂，如果设备已经RPM suspend了，那么System sleep suspend要怎么做？要强调的是，这种情况下，RPM suspend、System sleep suspend以及后续的resume行为，完全是由设备驱动决定的，例如，RPM suspend执行“浅睡眠（可以唤醒系统）”，System sleep suspend执行“深睡眠（不可以唤醒系统）”，等等。
        e）因此，设备驱动对已经RPM suspend的设备，再执行System sleep suspend时，很有可能会先把设备从RPM suspend状态唤醒，然后再让它进入System sleep suspend状态，而这一切Runtime PM已经不知情了。
        f）回到resume的过程，来探讨一下您提出的两个问题（主要针对第一种情况）。
       g）首先，系统没有从suspend状态resume的时候，RPM机制肯定是没有激活的，因此，肯定是System sleep resume后，才可能有RPM resume。至于是否一定有RPM resume，这依赖于System sleep resume后，设备的实际状态。
        h）如果设备在System sleep suspend之前，已经RPM suspend了，它的RPM status就是SUSPEND状态。但在System sleep resume之后，设备有可能直接变成full power on状态了（这和设备驱动的策略有关），因此就和RPM的实际status不符，怎么办呢？手动修改RPM状态，使其变成ACTIVE的（pm_runtime_set_active(dev) ），这就是那三句话的意思。
        I）最后，如果设备已经是RPM ACTIVE了，在需要RPM resume的时候，就不会再真正执行resume操作；甚至，如果之后不需要再使用设备，有可能会执行RPM suspend。

有点长，希望能帮到您。

@linuxer：电源管理差不多收尾了，接下来写什么，还在犹豫中。想写显示相关的东西，又怕写不好。
PS：linuxer同学，你随便一写就要写到2020年啊？真吓人。哈哈。

@linuxer：linuxer是不是对网络非常精通？在一个群里有个对网络很精通，写过很多网络方面博客的linuxer，不知道此linuxer是不是彼linuxer？嘿嘿

@linuxer：linuxer 谢谢你的回复~！

@wowo：我也是用的emlog的主机，但没有用emlog，主机在美国，前几天他们的美国主机被黑了，所有的资料及备份全没了，幸好我自己有备份。。我觉得博主最好找个好点的主机或服务器，比如新浪云，阿里云等，不然这么好的一个博客没了，实在是太可惜了。

@linuxer：谢谢linuxer指点。用软件的确跳转不到，后来我自己找源码目录看的时候，也看到ipc目录下边了，有util.c和msg.c，内容大致看了下，的确是通过宏的方式了。不过我编译的内核模块，编译ok，但是在加载的时候会报错，unknown symbol in the module，查看log，就是上面说的三个函数：
unknown symbol sys_msgget
unknown symbol sys_msgsnd
unknown symbol sys_msgrcv
这可能是什么原因呢？

另外一个问题是，在内核中使用消息队列的方式是使用这些函数吗？还是有别的使用方法？

@linuxer：具体就是需要对收到的IP包进行私有协议的处理，传递私有协议处理的IP包给另一个线程，本来之前应用层处理用的是消息队列，现在移植到内核态，内核中应该使用什么机制去替换这种方式呢？实在是没查到相关的资料啊。

@wowo：不好意思额，这里不是分享么...在这里发就是希望大家都能看到，看有没有类似的

@shoujixiaodao：就是在preloader的时候，会进入到WFI这里，然后等待lk的唤醒...到WFI的时候是一个循环，没有跳出去

@linuxer：我之前接触的soc里面，GIC在system suspend的时候会掉电，suspend之后会用系统的一个独立的PMU来接管唤醒的中断源。假设RTC可以触发MPU，MPU再唤醒AP，然后AP经过了ROM code之后回到了resume的流程，那么在resume的早期中有一步是去重新初始化GIC的，RTC的中断理论上来说在这一步会被恢复，于是应该会在之后的某一个时间点被触发。
    不过我有另外一个问题，是对android的alarm system的： 假设RTC的irq没有连接到GIC，但是连接到了PMU，那么当RTC里面设置的闹钟时间到了之后，系统是可以从suspend状态被唤醒的，AP也可以走进resume的过程，只是RTC的irq在AP也就是kernel这边不存在，那么这种情况下android的闹钟应用是否还能正常判断出来自己设置的闹钟到期了？