[PATCH] PM / QoS: Fix default runtime_pm device resume latency

[Geert Uytterhoeven]

Hi Rafael,

On Tue, Oct 31, 2017 at 6:22 PM, Rafael J. Wysocki <rafael at kernel.org> wrote:
> On Tue, Oct 31, 2017 at 2:55 PM, Geert Uytterhoeven
> <geert at linux-m68k.org> wrote:
>> Hi Rafael, Tero,
>>
>> CC pinchartl, dri-devel
>>
>> On Tue, Oct 31, 2017 at 2:10 PM, Geert Uytterhoeven
>> <geert at linux-m68k.org> wrote:
>>> CC linux-renesas-soc
>>>
>>> On Tue, Oct 31, 2017 at 2:09 PM, Geert Uytterhoeven
>>> <geert at linux-m68k.org> wrote:
>>>> On Tue, Oct 31, 2017 at 12:27 AM, Rafael J. Wysocki <rjw at rjwysocki.net> wrote:
>>>>> On Monday, October 30, 2017 11:19:08 AM CET Rafael J. Wysocki wrote:
>>>>>> On Mon, Oct 30, 2017 at 8:10 AM, Tero Kristo <t-kristo at ti.com> wrote:
>>>>>> > The recent change to the PM QoS framework to introduce a proper
>>>>>> > no constraint value overlooked to handle the devices which don't
>>>>>> > implement PM QoS OPS. Runtime PM is one of the more severely
>>>>>> > impacted subsystems, failing every attempt to runtime suspend
>>>>>> > a device. This leads into some nasty second level issues like
>>>>>> > probe failures and increased power consumption among other things.
>>>>>>
>>>>>> Oh, that's bad.
>>>>>>
>>>>>> Sorry about breaking it and thanks for the fix!
>>>>>>
>>>>>> > Fix this by adding a proper return value for devices that don't
>>>>>> > implement PM QoS implicitly.
>>>>>> >
>>>>>> > Fixes: 0cc2b4e5a020 ("PM / QoS: Fix device resume latency PM QoS")
>>>>>> > Signed-off-by: Tero Kristo <t-kristo at ti.com>
>>>>>> > Cc: Rafael J. Wysocki <rafael.j.wysocki at intel.com>
>>>>>>
>>>>>> Applied.
>>>>>
>>>>> And pushed to Linus.
>>>>
>>>> I'm afraid it is not sufficient.
>>>>
>>>> Commit 0cc2b4e5a020fc7f ("PM / QoS: Fix device resume latency PM QoS")
>>>> introduced two issues on Renesas platforms:
>>>>  1. After boot up, many devices have changed their state from "suspended"
>>>>     to "active", according to /sys/kernel/debug/pm_genpd/pm_genpd_summary
>>>>     (comparing that file across boots is one of my standard tests).
>>>>     Interestingly, doing a system suspend/resume cycle restores their state
>>>>     to "suspended".
>>>>
>>>>  2. During system suspend, the following warning is printed on
>>>>     r8a7791/koelsch:
>>>>
>>>>         i2c-rcar e6530000.i2c: runtime PM trying to suspend device but
>>>> active child
>>
>>  3. I've just bisected a seemingly unrelated issue to the same commit.
>>     On Salvator-XS with R-Car H3, initialization of the rcar-du driver now
>>     takes more than 1 minute due to flip_done time outs, while it took 0.12s
>>     before:
>>
>>     [    3.015035] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>     [    3.021721] [drm] No driver support for vblank timestamp query.
>>     [   13.280738] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR*
>> [CRTC:58:crtc-3] flip_done timed out
>>     [   23.520707] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
>> [CRTC:58:crtc-3] flip_done timed out
>>     [   33.760708] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR*
>> [CRTC:58:crtc-3] flip_done timed out
>>     [   44.000755] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
>> [CRTC:58:crtc-3] flip_done timed out
>>     [   44.003597] Console: switching to colour frame buffer device 128x48
>>     [   54.240707] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR*
>> [CRTC:58:crtc-3] flip_done timed out
>>     [   64.480706] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
>> [CRTC:58:crtc-3] flip_done timed out
>>     [   64.544876] rcar-du feb00000.display: fb0:  frame buffer device
>>     [   64.552013] [drm] Initialized rcar-du 1.0.0 20130110 for
>> feb00000.display on minor 0
>>     [   64.559873] [drm] Device feb00000.display probed
>>
>>>> Commit 2a9a86d5c81389cd ("PM / QoS: Fix default runtime_pm device resume
>>>> latency") fixes the second issue, but not the first.
>>
>> ... nor the third.
>>
>>>> Reverting commits 2a9a86d5c81389cd ("PM / QoS: Fix default runtime_pm
>>>> device resume latency") and 0cc2b4e5a020fc7f ("PM / QoS: Fix device resume
>>>> latency PM QoS") fixes both.
>>
>> ... all three.
>
> Sorry for the breakage.
>
> OK, I'll just push the reverts to Linus later today.
>
>>>> Do you have a clue?
>
> Well, kind of.
>
> There is a change in behavior in domain_governor.c that should not
> have made any difference to my eyes, but maybe that's it.
>
> Can you please check if the attached patch makes any difference?

Thanks, but it doesn't seem to fix the issues.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds