On 2/4/2021 10:14 AM, Felix Kuehling wrote:
Am 2021-02-04 um 9:37 a.m. schrieb Alex Deucher:
On Wed, Feb 3, 2021 at 2:56 AM Lazar, Lijo <[email protected]> wrote:
[AMD Public Use]
-----Original Message-----
From: amd-gfx <[email protected]> On Behalf Of Alex Deucher
Sent: Tuesday, February 2, 2021 10:48 PM
To: [email protected]
Cc: Deucher, Alexander <[email protected]>
Subject: [PATCH 2/2] drm/amdgpu: enable DPM_FLAG_MAY_SKIP_RESUME and
DPM_FLAG_SMART_SUSPEND flags
Once the device has runtime suspended, we don't need to power it back up again
for system suspend. Likewise for resume, we don't to power up the device again
on resume only to power it back off again via runtime pm because it's still
idle.
Signed-off-by: Alex Deucher <[email protected]>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index b4780182f990..b78847fa769b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -206,6 +206,12 @@ int amdgpu_driver_load_kms(struct amdgpu_device *adev,
unsigned long flags)
if (amdgpu_device_supports_atpx(dev) &&
!amdgpu_is_atpx_hybrid())
dev_pm_set_driver_flags(dev->dev,
DPM_FLAG_NO_DIRECT_COMPLETE);
+ /* we want direct complete for BOCO */
+ if ((amdgpu_device_supports_atpx(dev) &&
+ amdgpu_is_atpx_hybrid()) ||
+ amdgpu_device_supports_boco(dev))
+ dev_pm_set_driver_flags(dev->dev,
DPM_FLAG_SMART_SUSPEND |
+ DPM_FLAG_MAY_SKIP_RESUME);
Device runtime suspend callback does -
amdgpu_device_suspend(drm_dev, false)
System suspend callback does -
amdgpu_device_suspend(drm_dev, true)
One of the effects of this flag is for KFD to decide whether to evict all
processes. It is done during system suspend but not during runtime device
suspend. Will that have an impact if the system suspend routine is skipped in
this way?
+ Rajneesh
Can you comment on this? Idea of this patch is to not wake the device
for system suspend and resume if it's already in runtime suspend.
KFD doesn't allow amdgpu driver to runtime suspend the device as long as
the per process device data is valid. This patch only enables direct
complete path for already runtime suspended amdgpu device so its
implicit that kfd had no active process. While we may be OK to not
explicitly cancel scheduled work or suspend all kfd processes (since gpu
is already runtime suspended) we still leave KFD unlocked for a system
wide suspend via direct complete path. I think we should still be ok
with this since locking is only used for making sure that kfd is not
open during a gpu reset.
Also i suggest using DPM_FLAG_SMART_PREPARE as well, since we are
relying on prepare for skipping late/noirq phase during system suspend.
Acked-by: Rajneesh Bhardwaj <[email protected]>
KFD only allows runtime suspend when there are no processes using the
GPU. Therefore it should be safe (in theory) to skip process eviction if
you're already in runtime suspend. Just make sure all the suspend/resume
calls into KFD are paired up correctly. If you skip suspend but then
later call resume anyway, it will likely cause problems.
For testing this, I'd suggest running some KFD application (e.g. kfdtest
or an OpenCL app with ROCm-based OpenCL) before suspend, then suspend,
then run the app again after resume to make sure KFD is still good.
Regards,
Felix
Alex
Thanks,
Lijo
pm_runtime_use_autosuspend(dev->dev);
pm_runtime_set_autosuspend_delay(dev->dev, 5000);
pm_runtime_allow(dev->dev);
--
2.29.2
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
