Resource: LCA14 Name: LCA14-407: Deploying Runtime PM on ARM SOCs Date: 06-03-2014 Speaker: Ulf Hansson

1. Thu 6 March, 12:10pm, Ulf Hansson
LCA14-407: Deploying runtime PM on
ARM SOCs

2. Deploying runtime PM on ARM SOCs
• This is yet another episode in the series of runtime PM
sessions hosted at Linaro Connects.
• You may want to recapture from Kevin Hilman’s great
presentation at LCA13. “Combining Runtime PM and
suspend/resume.”
http://www.linaro.org/documents/download/2bc49c2798620f7528f3b2be50e22d3651399dd80ba7b

3. Deploying runtime PM on ARM SOCs
• A condensed summary of runtime PM
• Scenarios for system PM when deploying runtime PM
• A new solution to the tricky scenarios for system PM
• Power domains and the generic power domain
Questions and comments - please!

4. • Why deploy runtime PM?
• To enable fine grained power management.
• Suitable for I/O devices, which are able to enter low power state when
there are no requests to serve.
• Successfully probed devices may be left unused and in full power
state. Use runtime PM to put them into low power state.
• Required to be able to maintain a centralized management of domain
regulators/clocks.
• Some history
• Runtime PM were introduced in Linux Kernel 2.6.32, Dec 2009.
• Runtime PM is today widely deployed by subsystems and drivers.
Deploying runtime PM on ARM SOCs

5. • Prerequisites stated by PM core for system suspend
a. At device_prepare(), the PM core temporarily prevents -
>runtime_suspend callbacks from being invoked during system
suspend. Additionally, at device_suspend_late(), it disables
runtime PM.
b. The above actions are reversed by the PM core at
device_resume_early() and at device_complete(),
respectively.
c. The sysfs interface for runtime PM, provides an option for userspace
to trigger a runtime PM resume of a device and then prevent the -
>runtime_suspend callbacks from being invoked.
d. CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME selects CONFIG_PM,
but are separate kernel configs.
Deploying runtime PM on ARM SOCs

6. • Scenarios for subsystems/drivers at system suspend
a. A pure runtime PM centric driver uses the asynchronous runtime PM
APIs while decrementing the usage count.
b. A pure runtime PM centric driver’s device may be used by another
subsystem during system suspend.
c. A driver’s runtime PM suspend operations are a subset of the system
suspend operations. At system suspend, the driver maintain a certain
order for these operations.
d. A subsystem handles runtime PM resources, which needs to be
managed at system suspend to put the device into low power state.
e. A cross SOC driver’s device may reside in a power domain.
Deploying runtime PM on ARM SOCs

7. • Changes in 3.14 rc1 for PM core
• The pm_generic_runtime_suspend|resume(), used by the
platform bus, are moved to CONFIG_PM.
• SET_PM_RUNTIME_PM_OPS macro. Defines the runtime PM
callbacks for CONFIG_PM.
• SET_LATE_SYSTEM_SLEEP_PM_OPS macro.
Deploying runtime PM on ARM SOCs

8. • A new solution to handle system PM
To address the tricky scenarios for system PM while deploying runtime PM, don’t use
a power domain! It’s unreasonable, especially for SOCs that don’t supports domain
regulators/clocks in HW. Moreover it won’t address all the scenarios.
• Convert from the SET_RUNTIME_PM_OPS macro to the new
SET_PM_RUNTIME_PM_OPS macro.
• Let the driver invoke the ->runtime_suspend callback from some
of it’s system suspend callbacks. Respect the hierarchy of the
callbacks, to neither ignore power domains nor subsystems.
• Perform the operations with runtime PM disabled. It might be
convenient from the ->suspend_late callback, since at that point
runtime PM has been disabled by the PM core.
• Reverse the suspend actions from the driver’s respective system
resume callback.
Deploying runtime PM on ARM SOCs

9. • An example - a driver’s system suspend callback
my_driver_suspend()
{
pm_runtime_disable();
if (pm_runtime_status_suspended())
return 0;
if (power domain)
ret = invoke power domain’s runtime_suspend;
else
ret = invoke the subsystem’s runtime_suspend;
if (ret)
goto err;
pm_runtime_set_suspended();
return 0;
err:
pm_runtime_enable();
return ret;
}
Deploying runtime PM on ARM SOCs

10. • An example - a driver’s system resume callback
my_driver_resume()
{
if (power domain)
ret = invoke power domain’s runtime_resume callback;
else
ret = invoke the subsystem’s runtime_resume callback;
if (ret)
goto err;
pm_runtime_set_active();
pm_runtime_mark_last_busy();
err:
pm_runtime_enable()
return ret;
}
Deploying runtime PM on ARM SOCs

11. • Prevent open coding - use runtime PM helper functions
• pm_runtime_force_suspend()
• pm_runtime_force_resume()
• Optimizations
• Don’t bring back the device into full power at system resume, unless
it’s explicitly needed.
• Other issues?
Deploying runtime PM on ARM SOCs

12. • What about power domains?
• A group of devices shares the same regulator for powering their
silicons. Subsystem/driver maintainers requires a centralized
management of these domain regulators.
• Some SOCs have domain clocks.
• A power domain’s runtime PM callbacks are used to maintain the
usage count of the domain regulator.
• The state of the power domain could have an impact on which idle
state a CPU Idle driver could enter.
• Requires the driver that handles a device, which resides in a power
domain, to implement save and restore of register context from it’s
runtime PM callbacks.
Deploying runtime PM on ARM SOCs

13. • What SOCs implements power domains?
• Omap1, Keystone, Davinci - simple implementations managing
domain clocks.
• Omap2, the only current example of a full implementation. It does it’s
best, trying to handle the tricky scenarios for system PM, for a
runtime PM deployed SOC.
• SH-Mobile, Exynos, s3c64xx (soon ux500) - use the generic power
domain.
Deploying runtime PM on ARM SOCs

14. • The generic power domain - what’s missing!?
Consolidates the common parts for a power domain.
• We need full DT support.
• Solve probe/remove as a part of genpd.
• Make it optional to queue invokes of ->runtime_suspend
callbacks.
• Make system suspend callbacks of genpd, respect subsystems.
• Adopt to the new solution for how to handle the tricky scenarios for
system PM while deploying runtime PM.
• Some drivers need context save/restore in immediate relation to
when the power domain power goes on/off. Is this a common
problem?
• Anything else?
Deploying runtime PM on ARM SOCs

15. That’s it, thank you!
Deploying runtime PM on ARM SOCs

16. More about Linaro Connect: http://connect.linaro.org
More about Linaro: http://www.linaro.org/about/
More about Linaro engineering: http://www.linaro.org/engineering/
Linaro members: www.linaro.org/members