Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks

[Johannes Stezenbach]

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@xxxxxxxxx> 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
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
3. optimization: tell pm core to skip ->suspend() via return value
   from ->prepare() which sets direct_complete

...and your patch only deals with 1 and 2.

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?

> 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().
Using ->prepare() for the purpose seems wrong since it traverses
the hierarchy in the "wrong" order.  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.)


Thanks,
Johannes