wowo

@qkhhyga：这取决于runtime_resume和“读取外设数据的执行程序”需要做哪些事情。首先有一点是要保证的，设备必须正确resume后，才能读取数据。那么执行流就应该这样：pm_runtime_get-->runtime_resume-->读取数据。因此我们的设计应该保证，在runtime_resume之后，才能读取数据。或者，读取数据的程序，就是runtime_resume触发执行的。因此，不会存在runtime_resume执行较晚的可能（要在设计上杜绝）。至于所担心的影响中断响应，则完全不必，pm_runtime_get是异步的，因此会在中断结束后，起一个线程执行runtime_resume，不会影响中断。

《Linux电源管理(11)_Runtime PM之功能描述》发表时间：2015-03-04 15:43

schedule

wowo & linuxer 是帝都的吗？

《Linux电源管理(14)_从设备驱动的角度看电源管理》发表时间：2015-03-04 15:07

qkhhyga

＠wowo：我有一个问题想请教一下：在runtime　pm中，在设计driver时，如果在外设处于suspend状态，突然外设有事件上报，即产生中断，在中断处理函数中去异步地get引用计数，那么此时runtime_resume有可能会比读取外设数据的执行程序要晚，这样的问题如何解决？即使resume在此之前，也会带来一定的延时，影响中断的响应时间

《Linux电源管理(11)_Runtime PM之功能描述》发表时间：2015-03-04 14:53

linuxer_j

非常感谢！看了你的号几篇文章，收货不小，而且都是比较新的内容。

《Device Tree（一）：背景介绍》发表时间：2015-03-04 14:48

schedule

@wowo：牛！期待你们关于网络系统的分析！

《Linux电源管理(14)_从设备驱动的角度看电源管理》发表时间：2015-03-04 14:43

tigger

最近处理一个共享中断的case，共享中断确实如楼主所说，来了中断要调用一遍所有的挂在这个中断号下面的，irq handler。也就是下面的描述（发生中断的时候要逐个询问是不是你的中断，软件上就是遍历action list啦），因此外设的irq handler中最好是一开始就启动判断，看看是否是自己的中断，如果不是，返回IRQ_NONE,表示这个中断不归我管。容易出问题的地方就是，最好在irq handler中最好是一开始就启动判断，如果这个判断设计有误，比如不是自己的中断，还会跑自己的后面的handler，那么就有可能引入诡异的问题。

《linux kernel的中断子系统之（三）：IRQ number和中断描述符》发表时间：2015-03-04 14:26

蜗蜗

@tigger：应该可以，可以借助百度搜索。等晚上我试试。

《留言板》发表时间：2015-03-04 13:07

tigger

我们的评论列表里面的内容，好像没法被搜索。这个有方法解决吗？比如很多在评论里面讨论的东西，只能返回去一篇篇的找，不能关键字检索

《留言板》发表时间：2015-03-04 12:59

wowo

@haichunzhao：是的，抛开具体的设备去讲suspend时要做什么，是没有意义的，因为设备是多样的。

《Linux电源管理(14)_从设备驱动的角度看电源管理》发表时间：2015-03-04 12:28

wowo

@haichunzhao：确实如此。kernel提供了很多机制，暂时还没有用处。说实话，我一直很反感Android，复杂的有些臃肿。现在我也有点怀疑linux kernel了。它需要尽可能的支持所有的可能需求，这没错。但相应的，是要付出代价的。