summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/task-analyzer.py
diff options
context:
space:
mode:
authorDouglas Anderson <dianders@chromium.org>2023-02-02 21:48:43 +0300
committerRob Clark <robdclark@chromium.org>2023-02-22 22:22:03 +0300
commit4cd15a3e8b36a94c4afa6af064ebe09d387ae034 (patch)
tree96c12736eb239a6d3c098f178ea5db4c91066b6d /tools/perf/scripts/python/task-analyzer.py
parent796762f0506077c4f048b4eb05de2f587f488bce (diff)
downloadlinux-4cd15a3e8b36a94c4afa6af064ebe09d387ae034.tar.xz
drm/msm/a6xx: Make GPU destroy a bit safer
If, for whatever reason, we're trying process adreno_runtime_resume() at the same time that a6xx_destroy() is running then things can go boom. Specifically adreno_runtime_resume() will eventually call a6xx_pm_resume() and that may try to resume the gmu. Let's grab the GMU lock as we're destroying the GMU. That will solve the race because a6xx_pm_resume() grabs the same lock. That makes the access of `gmu->initialized` in a6xx_gmu_resume() safe. We'll also return an error code in a6xx_gmu_resume() if we see that `gmu->initialized` was false. If this happens we'll bail out of the rest of a6xx_pm_resume(), which is good because the rest of that function is also not good to do if we're racing with a6xx_destroy(). Signed-off-by: Douglas Anderson <dianders@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/521232/ Link: https://lore.kernel.org/r/20230202104822.1.I0e49003bf4dd1dead9be4a29dbee41f3b1236e48@changeid Signed-off-by: Rob Clark <robdclark@chromium.org>
Diffstat (limited to 'tools/perf/scripts/python/task-analyzer.py')
0 files changed, 0 insertions, 0 deletions