amd-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Thorsten Leemhuis <regressions@leemhuis.info>
To: Alex Deucher <alexander.deucher@amd.com>, amd-gfx@lists.freedesktop.org
Cc: Michele Ballabio <ballabio.m@gmail.com>
Subject: Re: [PATCH] drm/amdgpu: don't runtime suspend if there are displays attached (v2)
Date: Thu, 21 Apr 2022 13:11:31 +0200	[thread overview]
Message-ID: <550cf7fc-47fa-777d-892d-8ec0b9d15445@leemhuis.info> (raw)
In-Reply-To: <20220421031607.1745623-1-alexander.deucher@amd.com>

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@gmail.com>
> Signed-off-by: Alex Deucher <alexander.deucher@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/"

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/

  parent reply	other threads:[~2022-04-21 13:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-21  3:16 [PATCH] drm/amdgpu: don't runtime suspend if there are displays attached (v2) Alex Deucher
2022-04-21  4:40 ` Alex Deucher
2022-04-21  5:23 ` Quan, Evan
2022-04-21 11:11 ` Thorsten Leemhuis [this message]
2022-04-21 14:19   ` Alex Deucher
  -- strict thread matches above, loose matches on Subject: below --
2022-04-13 20:15 Alex Deucher
2022-04-19 13:47 ` Alex Deucher
2022-04-20 13:57   ` Alex Deucher
2022-04-20 14:05     ` Christian König
2022-04-19 14:04 ` Paul Menzel
2022-04-19 14:44   ` Alex Deucher
2022-04-21  2:53 ` Quan, Evan
2022-04-21  3:00   ` Alex Deucher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=550cf7fc-47fa-777d-892d-8ec0b9d15445@leemhuis.info \
    --to=regressions@leemhuis.info \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=ballabio.m@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).