蜗窝科技

@wowo：wowo,我最近在梳理pm runtime和suspend之间的关系。碰到有一种case有点不太理解，请帮我看看： 1.一个设备在系统suspend之前处于RPM_SUSPENDED状态；此时dev->power.usage_count=0，dev->power.runtime_state = RPM_SUSPENDED； 2.在dev->prepare函数， system suspend框架会调用pm_runtime_get_noresume，此时dev->power.usage_count=1， runtime_state仍然是RPM_SUSPENEDED； 3.接着，system suspend会调用device_suspend_late，这个函数中调用了__pm_runtime_disable()。如果恰好在此之前，有人希望通过pm_runtime_get来resume这个设备，那么就会把一个pending的resume request放到pm runtime work queue上；此时usage_count=2， runtime_state = RPM_SUSPENDED； 4. 在__pm_runtime_disable中，函数会调用__pm_runtime_barrier，这会取消step3中的pending resume请求。 但不会将usage_count减1。此时usage_count=2， runtime_state = RPM_SUSPENDED。 5. 当系统resume回来的时候，它会调用pm_runtime_put来将usage_count减1。 此时usage_count=1， runtime_state = RPM_SUSPENDED。 可以看到，经过这几个步骤后，device的runtime_state和usage_count出现了不匹配的情况，runtime_state=RPM_SUSPENDED的时候usage_count应该是0，但现在变成了1。我做的实验也是这样。不知道这算不算runtime的bug呢？还是我上面哪一步有问题？请指教，谢谢！

@artake：谢谢夸奖，不过膜拜、love就不需要了，哈哈~~

@bear20081015：至于runtime PM，确实只是开了一个头。因为RPM的使用比较简单，但内部实现涉及到的知识点就多了，因此还没有时间去写。可以直接评论交流，非常欢迎~~~~

@bear20081015：我来插一句： ARM架构提供了non-blocking的同步机制（也称作synchronization primitives），确实比较高效、实用。但该机制需要一些额外机制的支撑，也就是您所提到的local monitor和global monitor。monitor特别是global monitor的实现， 和cache、MMU等没有直接关系。但是，对那些特殊位置的memory，如non-cacheable、cache-disable等，需要在PE之外实现monitor功能，而并不是所有厂商都会做这些事情。 对arm trusted firmware来说，它无法假设厂商的具体行为，因此为了确保同步的有效，就不得不使用软件的互斥机制（bakery lock）。 而对Linux kernel而言，kernel是在单核、preemptive disable的情况下启动的，等到真正使用spin lock的时候，一切都准备就绪了，因此也就没什么问题了。 具体可参考DDI0487A_d_armv8_arm.pdf： For Shareable memory locations, in some implementations and for some memory types, the properties of the global monitor require functionality outside the PE. Some system implementations might not implement this functionality for all locations of memory. In particular, this can apply to: • Any type of memory in the system implementation that does not support hardware cache coherency. • Non-cacheable memory, or memory treated as Non-cacheable, in an implementation that does support hardware cache coherency. In such a system, it is defined by the system: • Whether the global monitor is implemented. • If the global monitor is implemented, which address ranges or memory types it monitors ... Therefore, architecturally-compliant software that requires mutual exclusion must not rely on using the Load-Exclusive/Store-Exclusive mechanism, and must instead use a software algorithm such as Lamport’s Bakery algorithm to achieve mutual exclusion.

群主写得实在是太好了，膜拜，I love you

@linuxer：我个人还是感觉是有点关系的，否则不可能arm trustfirm要多此一举去实现一个软件的spinlock锁，而且这个锁就是在cache没有enable的情况下使用的。但还是感谢你耐心的回答！另外多问一句，我看到你们的pm runtime的系列文章似乎只开了个头，我最近在这一块有点疑问，不知道你们后续文章有时间表么？或者就在评论区里面大家讨论一下？

@bear20081015：local和global monitor是实现在L1和L2 cache中的 --------------------------------------------------- 我看原文上是说local和global monitor是实现在L1和L2 memory system中，我是觉得local timer以及global timer应该是和L1和L2 cache是否enable或者disable无关，即便是L1和L2 cache disable了，local monitor和global monitor也应该是可以工作的 当然，这也是我的猜测而已，仅供参考

@linuxer：linux,我摘录的那一段都是在描述arm中如何支持exclusive access的。我的理解是：spinlock从本质上来说确实就是内存中的一个u32数据，但如何支持ldx和stx这两条指令的原子性呢？硬件上肯定要有东西来支撑它，我理解就是local monitor和global monitor。正如这句话“Each processor that supports exclusive accesses has a local monitor.”。进一步从arm的文档中看，local和global monitor是实现在L1和L2 cache中的。所以我才怀疑当L1，L2 cache被disable掉的时候，ldx和stx指令都无效了，也就不能使用spinlock了。我这两天看了下ARM的trust firmware里的bakery lock，我不确定自己理解的对不对，但是看起来就是一个软件上的锁似乎就是为了代替在cpu刚上电时cache关掉时各个CPU的race condition，如果能够直接用spinlock的话似乎就没这个必要了吧。

@bear20081015：你摘录的英文都是在描述Shareability，但是你的问题却在说cache，你是不是把Shareability和Cacheability搞混了？

@zzq57683968：多谢关注，我会尽力做的:-)