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, 0 insertions, 82 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 deleted file mode 100644 index ac95a26c..00000000 --- a/common/recipes-kernel/linux/files/0394-drm-amdgpu-cleanup-amdgpu_fence_activity.patch +++ /dev/null @@ -1,82 +0,0 @@ -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 - |