Messages in this thread | | | Date | Wed, 9 Oct 2019 12:55:06 -0700 | From | Tony Lindgren <> | Subject | Re: [PATCH] PM / runtime: Add support for wake-up reason for wakeirqs |
| |
* Alan Stern <stern@rowland.harvard.edu> [191009 18:51]: > On Wed, 9 Oct 2019, Tony Lindgren wrote: > > > With generic wakeirqs we can wake a device, but do not know if the > > device woke to a wakeirq. Let's add pm_runtime_wakeup_is_wakeirq() so > > a device can check the wake-up reason. > > People have tried many times over the years to do something like this. > It's never right. > > The problem is simple: It's impossible to know for certain why the > system woke up from suspend. In fact, there may be many wakeup sources > all active at the same time, and any of them could be the one > responsible for actually waking the system.
Hmm yeah good point. Even with dedicated wakeirq it could race against a timer for the wake-up event.
> All you can do is check to see whether a particular wakeup source is > active at the present moment. You can't tell whether it was active in > the past (while the system was suspended) or whether it caused the > system to resume.
We can actually do more than that now though :)
With handle_threaded_wake_irq() we could optionally call a handler before we call pm_runtime_resume() and let the consumer device driver figure out what the state is.
Regards,
Tony
| |