]> git.baikalelectronics.ru Git - kernel.git/commit
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>
Wed, 27 Apr 2022 21:18:53 +0000 (17:18 -0400)
commit658af518cfab711ab4794dfe6c3fc39eadbbb143
tree484efcfa166f4ddeec19fd34bf655e783337e4c4
parent81a464c419811ade43a51633d0f248fa59ae6b10
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 782c4c62d18183 ("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: 782c4c62d18183 ("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>
Cc: stable@vger.kernel.org
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c