Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks | Date | Thu, 21 Sep 2017 16:30:08 +0200 |
| |
On Thursday, September 21, 2017 11:27:13 AM CEST Johannes Stezenbach wrote: > On Thu, Sep 21, 2017 at 02:39:30AM +0200, Rafael J. Wysocki wrote: > > On Wed, Sep 20, 2017 at 6:27 PM, Johannes Stezenbach <js@sig21.net> wrote: > > > > > > E.g. an audio codec could keep running > > > while the i2c bus used to program its registers can be runtime suspended. > > > If this is correct I think it would be useful to spell it out explicitly > > > in the documentation. > > > > That's because the i2c bus uses the ignore_children flag that allows > > it to override the general rules. :-) > > Ah! I was looking at Documentation/driver-api/pm only (which is > changed by your patch), but this is documented in Documentation/power > (and obviously I hadn't checked the code, shame on me). > > > direct_complete has nothing to do with this. > > Oh? Reading again, do I get this right: > > 1. simple method: always call pm_runtime_resume() in ->suspend(), > then suspend the driver again
Right.
> 2. optimization: if pm_runtime_suspended(), the driver's ->suspend() > can possibly do nothing if conditions permit, otherwise it calls > pm_runtime_resume() and then suspends
Well, that may work in some cases. :-)
> 3. optimization: tell pm core to skip ->suspend() via return value > from ->prepare() which sets direct_complete
Yup.
> ...and your patch only deals with 1 and 2.
Yes, basically.
> Sorry to hijack your thread for side discussion, it was > inadvertant due to my lack of understanding. > > > > First off, the PM core does check the direct_complete flag in > > __device_suspend() and does more-or-less what you are saying. > > > > However, that flag is initialized in device_prepare() with the help of > > the ->suspend() return value, because whether or not it makes sense to > > you mean ->prepare(), right?
Right (sorry).
> > set that flag depends on some conditions that may change between > > consecutive system suspend-resume cycles in general and need to be > > checked in advance before setting it. > > > > HTH > > It does, however the question remains *why* it needs to check > it in ->prepare() and not right before calling ->suspend().
Becuase the core needs input from middle layers in some cases before it decides to call ->suspend().
> Using ->prepare() for the purpose seems wrong since it traverses > the hierarchy in the "wrong" order.
That doesn't matter. What matters is whether or not the device's state is "compatible" with system sleep at the ->prepare() time (which is checked by some middle layers in ->prepare()).
BTW, did you notice the pm_runtime_status_suspended() checks in __device_suspend()? They are in there in case the device has been resumed from runtime suspend after ->prepare().
> Only right before calling ->suspend() the driver knows if its current > state allows it to skip any further actions for suspend, because > suspending children or other users may cause pm_runtime_resume() > for it. (In the back of my head I have the scenario of > bug #196861, some completely different driver uses > i2c via ACPI OpRegion during its suspend.)
Yes, that's a special case (again, because of the way i2c handles runtime PM overall).
Thanks, Rafael
| |