Re: [RFC/RFT][PATCH v2 5/7] PM / runtime: Flag to indicate PM sleep transitions in progress

[Lukas Wunner <lukas@wunner.de>]

On Mon, Sep 12, 2016 at 11:25:36PM +0200, Rafael J. Wysocki wrote:
> On Monday, September 12, 2016 04:07:27 PM Lukas Wunner wrote:
> > On Thu, Sep 08, 2016 at 11:29:48PM +0200, Rafael J. Wysocki wrote:
> > > Introduce a new flag in struct dev_pm_info, pm_sleep_in_progress, to
> > > indicate that runtime PM has been disabled because of a PM sleep
> > > transition in progress.
> > [...]
> > > That will allow helpers like pm_runtime_get_sync() to be called
> > > during system sleep transitions without worrying about possible
> > > error codes they may return because runtime PM is disabled at
> > > that point.
> > 
> > I have a suspicion that this patch papers over the direct_complete bug
> > I reported Sep 10 and that the patch is unnecessary once that bug is
> > fixed.
> 
> It doesn't paper over anything, but it may not be necessary anyway.
> 
> > AFAICS, runtime PM is only disabled in two places during the system
> > sleep process: In __device_suspend() for devices using direct_complete,
> > and __device_suspend_late() for all devices.
> > 
> > In both of these phases (dpm_suspend() and dpm_suspend_late()), the
> > device tree is walked bottom-up. Since we've reordered consumers to
> > the back of dpm_list, they will be treated *before* their suppliers.
> > Thus, runtime PM is disabled on the consumers first, and only later
> > on the suppliers.
> > 
> > Then how can it be that runtime PM is already disabled on the supplier?
> 
> Actually, I think that this was a consequence of a bug in
> device_reorder_to_tail() that was present in the previous iteration
> of the patchset (it walked suppliers instead of consumers).
> 
> > The only scenario I can imagine is that the supplier chose to exercise
> > direct_complete, thus was pm_runtime_disabled() in the __device_suspend()
> > phase, and the consumer did *not* choose to exercise direct_complete and
> > later tried to runtime resume its suppliers and itself.
> > 
> > I assume this patch is a replacement for Marek's [v2 08/10].
> > @Marek, does this scenario match with what you witnessed?
> 
> It is not strictly a replacement for it.  The Marek's patch was the
> reason to post it, but I started to think about this earlier.
> 
> Some people have complained to me about having to deal with error codes
> returned by the runtime PM framework during system suspend, so I thought
> it might be useful to deal with that too.
> 
> That said it probably is not necessary right now.

Understood, thanks for providing this context which was unknown to me.

I'm wondering if it's necessary to introduce a new "pm_sleep_in_progress"
flag. We've already got "is_prepared", "is_suspended", "is_late_suspended",
"is_noirq_suspended", so we should have a pretty good idea of the fact
that the device is going to sleep and which stage it's in.

E.g. (dev->power.direct_complete || dev->power.is_suspended) covers a bit
more than the time frame when runtime PM is disabled for system sleep,
but might perhaps still suffice as a proxy.

Should a new flag be unavoidable, setting it directly in
__device_suspend_late(), device_resume_early(), __device_suspend()
and device_resume() would result in a smaller patch. (E.g. you
wouldn't have to modify the prototype of pm_runtime_enable().)

Thanks,

Lukas