Combining
Runtime PM
and
suspend/resume
Kevin Hilman
khilman@linaro.org
For an Introduction to runtime PM
http://people.li...
What ? !!!
Now I have to add
Runtime PM to
my driver?
I thought
suspend/resume
was enough !!
System PM Runtime PM
Today: Separate worlds
Tomorrow
Happy
together
Runtime PM
· suspend on inactivity
· resume when needed
System PM
· suspend when requested
· resume with system
Hey! what if I could
implement runtime PM,
and get suspend
for free?
So... how to combine them?
First, make runtime PM work.
Use PM domains to manage common resources
(clocks, mux, power domains, IP common...)
Then, ad...
Suspend triggers runtime PM
· Force inactivity in suspend
· device is now idle/inactive
· runtime PM takes over
Don't implement suspend
Necessary if device
is used by other
devices during
suspend
Example: OMAP I2C driver
Needed during suspend by other drivers
· I2C-connected RTC
· regulators on I2C-connected PMIC
Sol...
Great, so...
runtime PM, plus a little "enforcement"
in ->suspend() gets me both… right?
Yes...
Well...
Almost...
Except... there are several
ways for devices to be kept awake.
Tricky: async callbacks
PM workqueue frozen during suspend
· Asynchronous callbacks happen via
PM core workqueue (pm_wq)
·...
Tricky: Autosuspend timeouts
Driver does some work during ->suspend()
· _get_sync()
· _put_sync_autosuspend()
· autosuspen...
Tricky: PM core "protections"
PM core: device_prepare()
· increments usecount, decrements in _complete()
· effectively disa...
Tricky: userspace disable
runtime PM can be disabled from userspace
# echo on > /sys/devices/.../power/control
Oops, drive...
PM domain magic
Use "late" callbacks
Ensure all devices are suspended
struct dev_pm_ops {
[...]
int (*suspend_late)(struct device *dev);
i...
The magic trick
Runtime suspend "enforced" for stuck devices
static int my_domain_suspend_late(struct device *dev)>
{
if (...
Summary
· Runtime PM first
· use PM domains
· Keep drivers generic
What next?
· better understand PM core
protections in device_prepare()
· Help PM domains proliferate
· What else?
¿ Questions ?
結束
Upcoming SlideShare
Loading in...5
×

LCA13: Combining Runtime PM and suspend/resume

1,023

Published on

Resource: LCA13
Name: Combining Runtime PM and suspend/resume
Date: 06-03-2013
Speaker: Kevin Hilman

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

No Downloads
Views
Total Views
1,023
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
28
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

LCA13: Combining Runtime PM and suspend/resume

  1. 1. Combining Runtime PM and suspend/resume Kevin Hilman khilman@linaro.org For an Introduction to runtime PM http://people.linaro.org/~khilman/runtime_PM.html
  2. 2. What ? !!! Now I have to add Runtime PM to my driver? I thought suspend/resume was enough !!
  3. 3. System PM Runtime PM Today: Separate worlds
  4. 4. Tomorrow Happy together
  5. 5. Runtime PM · suspend on inactivity · resume when needed
  6. 6. System PM · suspend when requested · resume with system
  7. 7. Hey! what if I could implement runtime PM, and get suspend for free?
  8. 8. So... how to combine them?
  9. 9. First, make runtime PM work. Use PM domains to manage common resources (clocks, mux, power domains, IP common...) Then, add suspend/resume... if needed.
  10. 10. Suspend triggers runtime PM · Force inactivity in suspend · device is now idle/inactive · runtime PM takes over
  11. 11. Don't implement suspend Necessary if device is used by other devices during suspend
  12. 12. Example: OMAP I2C driver Needed during suspend by other drivers · I2C-connected RTC · regulators on I2C-connected PMIC Solution: · runtime PM only (no suspend/resume hooks) · full (re)init per xfer; stateless Quiz 1: What if I2C driver implemented suspend and was suspended before RTC? Quiz 2: Who decides suspend ordering?
  13. 13. Great, so... runtime PM, plus a little "enforcement" in ->suspend() gets me both… right? Yes... Well... Almost...
  14. 14. Except... there are several ways for devices to be kept awake.
  15. 15. Tricky: async callbacks PM workqueue frozen during suspend · Asynchronous callbacks happen via PM core workqueue (pm_wq) · workqueue frozen during suspend · Result: no async callbacks Solution: use _sync() methods
  16. 16. Tricky: Autosuspend timeouts Driver does some work during ->suspend() · _get_sync() · _put_sync_autosuspend() · autosuspend callbacks are asynchronous · Result: device left runtime enabled Solution: PM domain magic
  17. 17. Tricky: PM core "protections" PM core: device_prepare() · increments usecount, decrements in _complete() · effectively disables runtime suspend (but not resume) Example: device runtime suspended: usecount = 0 · PM core prepare: _get_noresume(): usecount = 1 · driver ->suspend(): _get_sync(): usecount = 2 · driver uses HW · driver ->suspend(): _put_sync(): usecount = 1 Result: stuck with usecount > 0, runtime enabled Solution: PM domain magic
  18. 18. Tricky: userspace disable runtime PM can be disabled from userspace # echo on > /sys/devices/.../power/control Oops, drivers using only runtime PM will be left runtime enabled during suspend. Solution: PM domain magic
  19. 19. PM domain magic
  20. 20. Use "late" callbacks Ensure all devices are suspended struct dev_pm_ops { [...] int (*suspend_late)(struct device *dev); int (*resume_early)(struct device *dev); }; struct dev_pm_domain { struct dev_pm_ops ops; };
  21. 21. The magic trick Runtime suspend "enforced" for stuck devices static int my_domain_suspend_late(struct device *dev)> { if (!pm_runtime_status_suspended(dev)) { if (pm_generic_runtime_suspend(dev) == 0) { /* platform-specific PM */ } } return 0; }
  22. 22. Summary · Runtime PM first · use PM domains · Keep drivers generic
  23. 23. What next? · better understand PM core protections in device_prepare() · Help PM domains proliferate · What else?
  24. 24. ¿ Questions ?
  25. 25. 結束
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×