On 7/31/2022 9:25 PM, Rob Clark wrote:
On Sat, Jul 30, 2022 at 2:41 AM Akhil P Oommen <quic_akhilpo@xxxxxxxxxxx> wrote:
We already enable gpu power from msm_gpu_submit(), so avoid a duplicate
pm_runtime_get/put from msm_job_run().
Signed-off-by: Akhil P Oommen <quic_akhilpo@xxxxxxxxxxx>
---
(no changes since v1)
drivers/gpu/drm/msm/msm_ringbuffer.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c b/drivers/gpu/drm/msm/msm_ringbuffer.c
index 56eecb4..cad4c35 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -29,8 +29,6 @@ static struct dma_fence *msm_job_run(struct drm_sched_job *job)
msm_gem_unlock(obj);
}
- pm_runtime_get_sync(&gpu->pdev->dev);
-
This is removing a _get_sync() and simply relying on a _get() (async)
in msm_gpu_submit().. that seems pretty likely to go badly? I think
it should probably replace the _get() in msm_gpu_submit() with
_get_sync() (but also since this is changing position of
resume/suspend vs active_lock, please make sure you test with lockdep
enabled)
BR,
-R
As discussed in the other patch, this is correctly handled in
msm_gpu_submit(). And from active_lock perspective, there is no change
actually. GPU is ON by the time we touch active_lock in both cases.
-Akhil.
/* TODO move submit path over to using a per-ring lock.. */
mutex_lock(&gpu->lock);
@@ -38,8 +36,6 @@ static struct dma_fence *msm_job_run(struct drm_sched_job *job)
mutex_unlock(&gpu->lock);
- pm_runtime_put(&gpu->pdev->dev);
-
return dma_fence_get(submit->hw_fence);
}
--
2.7.4
