aboutsummaryrefslogtreecommitdiffstats
path: root/common/recipes-kernel/linux/files/0394-drm-amdgpu-cleanup-amdgpu_fence_activity.patch
diff options
context:
space:
mode:
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.patch82
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
-