Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: [PATCH] PM: sleep: core: Fix the handling of pending runtime resume requests | Date | Mon, 24 Aug 2020 15:38:39 +0200 |
| |
On Monday, August 24, 2020 10:34:52 AM CEST Mika Westerberg wrote: > Hi, > > On Fri, Aug 21, 2020 at 03:34:42PM -0400, Alan Stern wrote: > > This means that the code could be simplified to just: > > > > pm_runtime_barrier(dev); > > > > Will this fix the reported bug? It seems likely to me that the actual > > problem with the failure scenario in the patch description was that > > turning on an ACPI power resource causes runtime-resume requests to be > > queued for all devices sharing that resource. Wouldn't it make more > > sense to resume only the device that requested it and leave the others > > in runtime suspend? > > The problem with at least PCIe devices that share ACPI power resources > is that once you turn on the power resource all the devices that shared > it will go into D0uninitialized power state and that means they lose all > wake configuration etc. so they need to be re-initialized by their > driver before they can go back to D3(cold) in order for their wakes to > still work.
Plus devices in D0uninitialized may prevent the SoC from allowing package C-states to be used for the processor AFAICS.
BTW, does the patch make the issue at hand go away?
| |