Enable runtime PM automatically?
From: khilman@kernel.org (Kevin Hilman)
Date: 2014-12-19 21:52:57
Also in:
linux-pm, linux-samsung-soc, lkml
Geert Uytterhoeven [off-list ref] writes: [...]
On Thu, Dec 18, 2014 at 10:29 PM, Kevin Hilman [off-list ref] wrote:quoted
quoted
However, if PM domains are active, drivers must be runtime PM-aware for the gpd_dev_ops.start() method to be called in the first place (perhaps this is just one bug that's easy to fix --- the device is "assumed suspended", but can be used). They must 1. call pm_runtime_enable() to enable runtime PM for the device, 2. call pm_runtime_get_sync() to prevent the device from being put in a low-power state at any time. This second call has the "side-effect" of calling gpd_dev_ops.start(). Hence, if PM domains are enabled, wouldn't it make sense to 1. enable runtime PM by default, for all devices (bound and unbound), 2. call pm_runtime_get_sync(), for all devices bound to a driver. Of course we have to keep track if drivers call any of the pm_runtime_*() methods theirselves, as that would have to move them from automatic to manual mode. Would this be feasible?We have to be careful about where the PM core's _get_sync() call goes. Because you're talking about "bound" devices, I guess you mean after the driver probes? Otherwise, it gets tricky if the _get_sync() is before the driver probes, because the device driver may have work it wants to do in its runtime PM callbacks, which are not initialized/available before the driver probes. Doing this before probe also makes it rather difficult to know for sure the actual physical state of the device, and make sure it matches the runtime PM state of the device. Rafael mentioned this also, and I'm not sure how we can be sure of the physical state.Yes, it's complicated by the fact that there are multiple sets of callbacks (PM domain, device type, class type, bus type, driver). However, the PM domain one has the highest priority, and is always (also for devices not bound to a driver) available.
Yes, but if a _get_sync() is called on a device which has not yet setup its callbacks (e.g. before it has been probed), then the device may not be properly initialized, and we may not be able to know its physical state.
quoted
Some thoughts: devices without drivers would be runtime resumed by the core, but will never be suspended, so the PM domain will never shut down. I guess the core will have to keep track of the devices it automatically runtime resumed and decide to runtime suspend them too? Hmm, where would that go?No, devices without a driver just need to become runtime PM enabled. They will only be resumed when a dependent device (e.g. a child) is resumed, and are suspended again after all dependents are suspended. That's how simple-pm-bus behaves.
Ah, OK. I thought you were proposing to _enable() and _get_sync() those devices. Thanks for the clarification, Kevin