Thread (1 message) 1 message, 1 author, 2014-12-19

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help