[PATCH] drm/amdgpu: don't runtime suspend if there are displays attached (v2)

[Alex Deucher]

On Thu, Apr 21, 2022 at 9:06 AM Thorsten Leemhuis
<regressions at leemhuis.info> wrote:
>
> On 21.04.22 05:16, Alex Deucher wrote:
> > We normally runtime suspend when there are displays attached if they
> > are in the DPMS off state, however, if something wakes the GPU
> > we send a hotplug event on resume (in case any displays were connected
> > while the GPU was in suspend) which can cause userspace to light
> > up the displays again soon after they were turned off.
> >
> > Prior to
> > commit 087451f372bf76 ("drm/amdgpu: use generic fb helpers instead of setting up AMD own's."),
> > the driver took a runtime pm reference when the fbdev emulation was
> > enabled because we didn't implement proper shadowing support for
> > vram access when the device was off so the device never runtime
> > suspended when there was a console bound.  Once that commit landed,
> > we now utilize the core fb helper implementation which properly
> > handles the emulation, so runtime pm now suspends in cases where it did
> > not before.  Ultimately, we need to sort out why runtime suspend in not
> > working in this case for some users, but this should restore similar
> > behavior to before.
> >
> > v2: move check into runtime_suspend
> > v3: wake ups -> wakeups in comment, retain pm_runtime behavior in
> >     runtime_idle callback
> >
> > Fixes: 087451f372bf76 ("drm/amdgpu: use generic fb helpers instead of setting up AMD own's.")
> > Tested-by: Michele Ballabio <ballabio.m at gmail.com>
> > Signed-off-by: Alex Deucher <alexander.deucher at amd.com>
> > [...]
>
> Hi Alex, how can I bribe you to start placing "Link:" tags in
> submissions that fix regressions (like this one), as explained in the
> Linux kernels documentation (see
> 'Documentation/process/submitting-patches.rst' and
> 'Documentation/process/5.Posting.rst'). E.g. in this case like this:
>
> "Link:
> https://lore.kernel.org/r/20220403132322.51c90903@darkstar.example.org/"
>

Done.  Thanks.

Alex

> This concept is not new (Linus and quite a few other developers use them
> like this for a long time), I just recently improved those documents to
> clarify things, as my regression tracking efforts rely on them -- that's
> why it's making my work a lot harder if they are missing most of the
> time. :-/
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>
> P.S.: As the Linux kernel's regression tracker I'm getting a lot of
> reports on my table. I can only look briefly into most of them and lack
> knowledge about most of the areas they concern. I thus unfortunately
> will sometimes get things wrong or miss something important. I hope
> that's not the case here; if you think it is, don't hesitate to tell me
> in a public reply, it's in everyone's interest to set the public record
> straight.
>
> #regzbot ^backmonitor:
> https://lore.kernel.org/lkml/20220403132322.51c90903@darkstar.example.org/