LCA14: LCA14-407: Deploying Runtime PM on ARM SOCs
Upcoming SlideShare
Loading in...5
×
 

LCA14: LCA14-407: Deploying Runtime PM on ARM SOCs

on

  • 254 views

Resource: LCA14

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

Statistics

Views

Total Views
254
Views on SlideShare
254
Embed Views
0

Actions

Likes
1
Downloads
9
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    LCA14: LCA14-407: Deploying Runtime PM on ARM SOCs LCA14: LCA14-407: Deploying Runtime PM on ARM SOCs Presentation Transcript

    • 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 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
    • • 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
    • • 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 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
    • • 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.org More about Linaro: http://www.linaro.org/about/ More about Linaro engineering: http://www.linaro.org/engineering/ Linaro members: www.linaro.org/members