diff options
Diffstat (limited to 'common/recipes-kernel/linux/files/0394-drm-amdgpu-cleanup-amdgpu_fence_activity.patch')
| -rw-r--r-- | common/recipes-kernel/linux/files/0394-drm-amdgpu-cleanup-amdgpu_fence_activity.patch | 82 |
1 files changed, 82 insertions, 0 deletions
diff --git a/common/recipes-kernel/linux/files/0394-drm-amdgpu-cleanup-amdgpu_fence_activity.patch b/common/recipes-kernel/linux/files/0394-drm-amdgpu-cleanup-amdgpu_fence_activity.patch new file mode 100644 index 00000000..ac95a26c --- /dev/null +++ b/common/recipes-kernel/linux/files/0394-drm-amdgpu-cleanup-amdgpu_fence_activity.patch @@ -0,0 +1,82 @@ +From 149a30121e2a4169b331e317d8061f8e523f7afa Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig@amd.com> +Date: Fri, 11 Mar 2016 17:49:58 +0100 +Subject: [PATCH 0394/1110] drm/amdgpu: cleanup amdgpu_fence_activity +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +The comment about the loop counter was never valid, even when you have +multiple threads this loop only runs as long as the sequence increases. + +Signed-off-by: Christian König <christian.koenig@amd.com> +Reviewed-by: Chunming Zhou <david1.zhou@amd.com> +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 35 +++---------------------------- + 1 file changed, 3 insertions(+), 32 deletions(-) + +diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c +index 3db18f4..35fbc88 100644 +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c +@@ -166,30 +166,8 @@ static void amdgpu_fence_schedule_fallback(struct amdgpu_ring *ring) + static bool amdgpu_fence_activity(struct amdgpu_ring *ring) + { + uint64_t seq, last_seq, last_emitted; +- unsigned count_loop = 0; + bool wake = false; + +- /* Note there is a scenario here for an infinite loop but it's +- * very unlikely to happen. For it to happen, the current polling +- * process need to be interrupted by another process and another +- * process needs to update the last_seq btw the atomic read and +- * xchg of the current process. +- * +- * More over for this to go in infinite loop there need to be +- * continuously new fence signaled ie amdgpu_fence_read needs +- * to return a different value each time for both the currently +- * polling process and the other process that xchg the last_seq +- * btw atomic read and xchg of the current process. And the +- * value the other process set as last seq must be higher than +- * the seq value we just read. Which means that current process +- * need to be interrupted after amdgpu_fence_read and before +- * atomic xchg. +- * +- * To be even more safe we count the number of time we loop and +- * we bail after 10 loop just accepting the fact that we might +- * have temporarly set the last_seq not to the true real last +- * seq but to an older one. +- */ + last_seq = atomic64_read(&ring->fence_drv.last_seq); + do { + last_emitted = ring->fence_drv.sync_seq; +@@ -200,23 +178,16 @@ static bool amdgpu_fence_activity(struct amdgpu_ring *ring) + seq |= last_emitted & 0xffffffff00000000LL; + } + +- if (seq <= last_seq || seq > last_emitted) { ++ if (seq <= last_seq || seq > last_emitted) + break; +- } ++ + /* If we loop over we don't want to return without + * checking if a fence is signaled as it means that the + * seq we just read is different from the previous on. + */ + wake = true; + last_seq = seq; +- if ((count_loop++) > 10) { +- /* We looped over too many time leave with the +- * fact that we might have set an older fence +- * seq then the current real last seq as signaled +- * by the hw. +- */ +- break; +- } ++ + } while (atomic64_xchg(&ring->fence_drv.last_seq, seq) > seq); + + if (seq < last_emitted) +-- +2.7.4 + |