]> 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)
commit3dd7df18cbd2dfbab8d7bf391bacdec99e8981e0
tree484efcfa166f4ddeec19fd34bf655e783337e4c4
parent3653b49ebdd8c1316e21b4c835b65adb4f69a586
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 717863f7bfd1b7 ("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: 717863f7bfd1b7 ("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