Thu 6 March, 12:10pm, Ulf Hansson

LCA14-407: Deploying runtime PM on ARM SOCs

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

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!

• 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

• Prerequisites stated by PM core for system suspenda. 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

• Scenarios for subsystems/drivers at system suspenda. 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

• 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

• A new solution to handle system PMTo 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

• 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

• 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

• 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

• 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

• 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

• 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

That’s it, thank you!

Deploying runtime PM on ARM SOCs

More about Linaro Connect: http://connect.linaro.orgMore about Linaro: http://www.linaro.org/about/

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