On 12/7/2025 4:05 PM, Antheas Kapenekakis wrote:
On Sun, 7 Dec 2025 at 20:49, Mario Limonciello (AMD) <[email protected]> wrote:
Set up APUs to follow similar policies as dGPUs in that they can
potentially runtime suspend. If an APU is runtime suspended then
prepare it for the matching system state (s0ix or s3) so that steps
can be skipped when runtime suspended.
The thought with this series is that if the compositor has turned
off displays and no other work is running an APU's GPU can enter
runtime PM. If the system later enters system suspend the GPU steps
can be skipped because the GPU is already in the runtime PM state
to match the intended system state.
The compositor or a game probably has assets on the GPU. If they are
frozen, would the amdgpu driver be able to suspend?
I'd expect so at least for some workloads. This is why we're able to
enter GFXOFF at runtime, the various rings are idle.
And if they're working like I'd expect any sort of GFX work, display
work, or reading a sensor will wake it back up.
But by all means try the patch and see what happens.
It's important to note that default runtime PM policy will prevent
entering runtime PM when displays are connected. This can be changed
by setting amdgpu.runpm=-2.
This series isn't yet tested, I just share it for feedback on
the approach. If anyone wants to test it as well, please feel free.
Cc: Antheas Kapenekakis <[email protected]>
Mario Limonciello (AMD) (1):
drm/amd: Expand runtime suspend to APUs
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 ++++++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 17 +++++++++++++++--
drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h | 1 +
3 files changed, 22 insertions(+), 2 deletions(-)
--
2.43.0
