Now that the bug is fixed in the minimal way for stable, go make the
code table-driven.
Signed-off-by: Eric Anholt
---
Previous version hadn't been rebased off of a bit of debug code I had,
so it wouldn't cleanly apply.
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 124 +-
We were using the same force-poweron bit in the two codepaths, so they
could race to have one of them lose GPU power early.
Signed-off-by: Eric Anholt
Cc: sta...@vger.kernel.org # v5.9
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 25 ++---
Now that the bug is fixed in the minimal way for stable, go make the
code table-driven.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 124 +-
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 55
2 files changed, 77 insertions(+), 102
Now that we're not racing with GPU setup, also fix races of timestamps
against other timestamps. In CI, we were seeing this path trigger
timeouts on setting the GMU bit, especially on the first set of tests
right after boot (it's probably easier to lose the race than one might
think, given that
Before the offending commit in msm_atomic_commit_tail wait_flush was
called once per frame, after the commit was submitted. After it
wait_flush is also called at the beginning to ensure previous
potentially async commits are done.
For cmd panels the source of wait_flush is a ping-pong irq