[Freedreno] [PATCH v3 3/3] drm/msm: Clean up GMU OOB set/clear handling.

Now that the bug is fixed in the minimal way for stable, go make the code table-driven. Signed-off-by: Eric Anholt Reviewed-by: Jordan Crouse --- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 124 +- drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 55 2 files changed, 77

[Freedreno] [PATCH v3 1/3] drm/msm: Fix race of GPU init vs timestamp power management.

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. freedreno CI was seeing intermittent errors like: [drm:_a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set GPU_SET: 0x0 and this issue could have contributed to it. S

[Freedreno] [PATCH v3 0/3] drm/msm: fix for "Timeout waiting for GMU OOB set GPU_SET: 0x0"

Updated commit messages over v2, no code changes. Eric Anholt (3): drm/msm: Fix race of GPU init vs timestamp power management. drm/msm: Fix races managing the OOB state for timestamp vs timestamps. drm/msm: Clean up GMU OOB set/clear handling. drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 105 +

[Freedreno] [PATCH v3 2/3] drm/msm: Fix races managing the OOB state for timestamp vs timestamps.

Now that we're not racing with GPU setup, also fix races of timestamps against other timestamps. In freedreno CI, we were seeing this path trigger timeouts on setting the GMU bit, producing: [drm:_a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set GPU_SET: 0x0 and this triggered especiall

Re: [Freedreno] [PATCH 2/3] drm/msm: Fix races managing the OOB state for timestamp vs timestamps.

On Wed, Jan 27, 2021 at 3:39 PM Eric Anholt wrote: > > 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 probab

Re: [Freedreno] [PATCH 1/3] drm/msm: Fix race of GPU init vs timestamp power management.

On Thu, Jan 28, 2021 at 10:52 AM Jordan Crouse wrote: > > On Wed, Jan 27, 2021 at 03:39:44PM -0800, Eric Anholt wrote: > > 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

Re: [Freedreno] [PATCH 3/3] drm/msm: Clean up GMU OOB set/clear handling.

On Wed, Jan 27, 2021 at 03:39:46PM -0800, Eric Anholt wrote: > Now that the bug is fixed in the minimal way for stable, go make the > code table-driven. > > Signed-off-by: Eric Anholt There shouldn't be too many more OOB bits, but this is a good cleanup regardless. Reviewed-by: Jordan Crouse

Re: [Freedreno] [PATCH 2/3] drm/msm: Fix races managing the OOB state for timestamp vs timestamps.

On Wed, Jan 27, 2021 at 03:39:45PM -0800, Eric Anholt wrote: > 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

Re: [Freedreno] [PATCH 1/3] drm/msm: Fix race of GPU init vs timestamp power management.

On Wed, Jan 27, 2021 at 03:39:44PM -0800, Eric Anholt wrote: > 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 You can add: Fixes: 4b565ca5a2cb ("drm/m

[Freedreno] [PATCHv2] drm/msm/kms: Make a lock_class_key for each crtc mutex

Lockdep complains about an AA deadlock when rebooting the device. WARNING: possible recursive locking detected 5.4.91 #1 Not tainted reboot/5213 is trying to acquire lock: ff80d13391b0 (&kms->commit_lock[

Re: [Freedreno] [PATCH] drm/msm/kms: Make a lock_class_key for each crtc mutex

On Mon, Jan 25, 2021 at 3:49 PM Stephen Boyd wrote: > > Lockdep complains about an AA deadlock when rebooting the device. > > > WARNING: possible recursive locking detected > 5.4.91 #1 Not tainted > > reboot/