drm/amdgpu: don't runtime suspend if there are displays attached (v3)
authorAlex Deucher <alexander.deucher@amd.com>
Tue, 28 Dec 2021 22:26:24 +0000 (17:26 -0500)
committerAlex Deucher <alexander.deucher@amd.com>
Thu, 21 Apr 2022 19:59:37 +0000 (15:59 -0400)
commit4020c2280233279ea682a7f2f24b54426416d91d
treefa79f91e7fe3673baa0751cb12396a940a04c918
parent515d7cebc2e2d2b4f0a276d26f3b790a83cdfe06
drm/amdgpu: don't runtime suspend if there are displays attached (v3)

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.")
Link: https://lore.kernel.org/r/20220403132322.51c90903@darkstar.example.org/
Tested-by: Michele Ballabio <ballabio.m@gmail.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c