Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Enabling the runtime PM centric path for ACPI - SFO17-202

125 views

Published on

Session ID: SFO17-202
Session Name: Enabling the runtime PM centric path for ACPI - SFO17-202
Speaker: Ulf Hansson

Track: Power Management


★ Session Summary ★
The ACPI PM domain supports the so called direct_complete path during system sleep in a way to avoid wasting power, but also to decrease the system suspend/resume time.

However, the direct_complete path has limitations and doesn’t perform well in all scenarios. The so called, runtime PM centric path, often offers a better option.

This session compares the two concepts and gives an update on the related work for ACPI PM domain.
---------------------------------------------------
★ Resources ★
Event Page: http://connect.linaro.org/resource/sfo17/sfo17-202/
Presentation:
Video:
---------------------------------------------------

★ Event Details ★
Linaro Connect San Francisco 2017 (SFO17)
25-29 September 2017
Hyatt Regency San Francisco Airport

---------------------------------------------------
Keyword:
http://www.linaro.org
http://connect.linaro.org
---------------------------------------------------
Follow us on Social Media
https://www.facebook.com/LinaroOrg
https://twitter.com/linaroorg
https://www.youtube.com/user/linaroorg?sub_confirmation=1
https://www.linkedin.com/company/1026961

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Enabling the runtime PM centric path for ACPI - SFO17-202

  1. 1. Enabling the runtime PM centric path for ACPI Ulf Hansson, Linaro
  2. 2. ENGINEERS AND DEVICES WORKING TOGETHER Agenda ● Recap: The RPM centric path. ● The ACPI PM domain. ● The direct_complete path. ● Adapting the ACPI PM domain. ● The series got posted. ● Conclusion and next steps.
  3. 3. ENGINEERS AND DEVICES WORKING TOGETHER Goals of RPM centric path ● Decrease system resume time of devices. ● Avoid wasting power at system resume of devices. ● Make it easy to deploy system sleep support in drivers. ● Avoid open coding in drivers. ● Simplify upstreaming of ARM SoC PM code.
  4. 4. ENGINEERS AND DEVICES WORKING TOGETHER RPM centric path - how? ● Observation: Operations in runtime suspend and system suspend are often very similar and vice versa for resume. ● Allows the runtime PM callbacks to be re-used during system suspend/resume. ● Don’t power on the device during system resume, unless really needed. Instead it postpones that to runtime PM! Deploy runtime PM support, get system sleep for “free”!
  5. 5. ENGINEERS AND DEVICES WORKING TOGETHER Let’s deploy the RPM centric path! mydrv.c: static const struct dev_pm_ops mydrv_dev_pm_ops = { SET_RUNTIME_PM_OPS(mydrv_ runtime_suspend, mydrv_runtime_resume, NULL) SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume) }; Yeah, we did it!
  6. 6. ENGINEERS AND DEVICES WORKING TOGETHER Need flexibility? ● Use it from any sleep phase? ○ ->suspend(), ->suspend_late(), ->suspend_noirq(). ○ ->resume(), ->resume_early(), ->resume_noirq(). ● Additional operations required during system sleep? ○ Invoke pm_runtime_force_suspend|resume() from system sleep callbacks. ● Drivers deploying the RPM centric path. ○ 3.15: 1 ○ 4.5: 16 ○ next: ~60 consolidation/optimization. ● Find examples: “git grep pm_runtime_force_suspend”.
  7. 7. ENGINEERS AND DEVICES WORKING TOGETHER Constraints for middle layers ● Buses and PM domains, which devices are being managed by a driver using the RPM centric path, needs to play along. ● Simple buses like, platform, spi, i2c, amba, are completely transparent. No changes needed. ● The generic PM domain easily adopted long time ago. ● Let’s adopt this for other subsystems!
  8. 8. ENGINEERS AND DEVICES WORKING TOGETHER Why the ACPI PM domain? ● Used by ARM. ○ Do we have HW that supports ACPI PM? ● Cross SoC drivers! ○ The device attached to the ACPI PM domain. ○ The device attached to the generic PM domain. ○ The device have no PM domain. ● Keep system sleep deployment simple in drivers. ● No matter of PM domain - benefit from the optimizations.
  9. 9. ENGINEERS AND DEVICES WORKING TOGETHER The ACPI PM domain ● Uses runtime/system PM to manage the power state of a device, through the ACPI FW. ● Relies on ACPI FW, to internally manage the power state of shared resources for a group of devices. ● Supports the direct_complete path for system sleep. ● The direct_complete path?
  10. 10. ENGINEERS AND DEVICES WORKING TOGETHER Adopting the ACPI PM domain ● Make the ACPI PM domain’s runtime PM callback aware of they can be called when runtime PM is disabled. ● Adopt the ACPI PM domain’s system sleep callback to trust the driver to deal with system sleep. ○ The driver needs to inform the ACPI PM domain in some way. ● Prove the behaviour in a cross SoC driver.
  11. 11. ENGINEERS AND DEVICES WORKING TOGETHER Suggested approach - rejected! ● Converting i2c-designware-platdrv. ○ 1 file changed, 5 insertions(+), 29 deletions(-) ● Series [1] submitted and re-spinned. ○ 7 files changed, 204 insertions(+), 101 deletions(-) [1] https://www.spinics.net/lists/arm-kernel/msg603856.html
  12. 12. ENGINEERS AND DEVICES WORKING TOGETHER Conclusion and next steps ● The direct_complete path isn’t good enough. ● It will get worse when more cross SoC drivers hits the same problems. ● We and the PM core maintainer are working on a new method to enable the ACPI PM domain. ● Until then: ○ Non-optimized system sleep support for drivers dealing with devices attached to the ACPI PM domain.
  13. 13. Thank You #SFO17 SFO17 keynotes and videos on: connect.linaro.org For further information: www.linaro.org

×