On Thu, 30 Apr 2015, Ulf Hansson wrote: > I hesitated to send this reply, since it might add confusion. If > that's the case, please ignore it. > > I have a long term vision to fully enable support for a runtime PM > centric configuration for drivers/subsystems. The idea is, that such > driver/subsystem should get system PM for "free". > > The main goal is to simplify PM implementation for these drivers/subsystems. > > They should need to implement the runtime PM callbacks only and not > the system PM ones. During system PM suspend, the requirement is that > the corresponding devices should be guaranteed to be "runtime PM > suspended". Somehow that then needs to be managed by the PM core. > > I am not sure it's doable, but I wanted to bring it up within the > context of $subject patch, since it proposes yet another optimization > path for runtime PM during system PM.
I suspect it is _not_ doable. Consider a reasonable scenario: a driver that does pm_runtime_get_sync() in its open routine and pm_runtime_put() in its release routine. If a user process holds the device file open during a system suspend, it will be impossible for the PM core to do a runtime suspend. On the other hand, there's nothing to prevent drivers from setting their ->suspend and ->runtime_suspend structure members to point at the same routine. The routine would need to handle the case where it was called for a system suspend while the device was already runtime suspended, but that doesn't seem too hard. With the "direct-suspend" option, even this wouldn't be necessary. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
