diff options
author | Douglas Anderson <dianders@chromium.org> | 2023-02-02 21:48:43 +0300 |
---|---|---|
committer | Rob Clark <robdclark@chromium.org> | 2023-02-22 22:22:03 +0300 |
commit | 4cd15a3e8b36a94c4afa6af064ebe09d387ae034 (patch) | |
tree | 96c12736eb239a6d3c098f178ea5db4c91066b6d /tools/perf/scripts/python/task-analyzer.py | |
parent | 796762f0506077c4f048b4eb05de2f587f488bce (diff) | |
download | linux-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