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

593
-1

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
593
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
31
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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

  1. 1. Thu 6 March, 12:10pm, Ulf Hansson LCA14-407: Deploying runtime PM on ARM SOCs
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. That’s it, thank you! Deploying runtime PM on ARM SOCs
  16. 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

×