From: Matthew Brost <matthew.brost@intel.com>
To: <intel-gfx@lists.freedesktop.org>, <dri-devel@lists.freedesktop.org>
Subject: [Intel-gfx] [PATCH] drm/i915/guc: Don't check CT descriptor status before CT write / read
Date: Thu, 20 Jan 2022 10:24:13 -0800 [thread overview]
Message-ID: <20220120182413.8074-1-matthew.brost@intel.com> (raw)
Don't check CT descriptor status, unless CONFIG_DRM_I915_DEBUG_GUC is
set, before CT write / read as this could result in a read across the
PCIe bus thus adding latency to every CT write / read. On well behavied
systems this vaue should always read as zero. For some reason it doesn't
the CT channel is broken and will eventually recover from a GT reset,
albeit the GT reset will not be triggered immediately by seeing that
descriptor status is non-zero.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index de89d40abd38d..18af99a802f64 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -379,8 +379,10 @@ static int ct_write(struct intel_guc_ct *ct,
u32 *cmds = ctb->cmds;
unsigned int i;
+#ifdef CONFIG_DRM_I915_DEBUG_GUC
if (unlikely(desc->status))
goto corrupted;
+#endif
GEM_BUG_ON(tail > size);
@@ -815,8 +817,10 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
if (unlikely(ctb->broken))
return -EPIPE;
+#ifdef CONFIG_DRM_I915_DEBUG_GUC
if (unlikely(desc->status))
goto corrupted;
+#endif
GEM_BUG_ON(head > size);
--
2.34.1
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Brost <matthew.brost@intel.com>
To: <intel-gfx@lists.freedesktop.org>, <dri-devel@lists.freedesktop.org>
Cc: daniele.ceraolospurio@intel.com, john.c.harrison@intel.com,
michal.wajdeczko@intel.com
Subject: [PATCH] drm/i915/guc: Don't check CT descriptor status before CT write / read
Date: Thu, 20 Jan 2022 10:24:13 -0800 [thread overview]
Message-ID: <20220120182413.8074-1-matthew.brost@intel.com> (raw)
Don't check CT descriptor status, unless CONFIG_DRM_I915_DEBUG_GUC is
set, before CT write / read as this could result in a read across the
PCIe bus thus adding latency to every CT write / read. On well behavied
systems this vaue should always read as zero. For some reason it doesn't
the CT channel is broken and will eventually recover from a GT reset,
albeit the GT reset will not be triggered immediately by seeing that
descriptor status is non-zero.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index de89d40abd38d..18af99a802f64 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -379,8 +379,10 @@ static int ct_write(struct intel_guc_ct *ct,
u32 *cmds = ctb->cmds;
unsigned int i;
+#ifdef CONFIG_DRM_I915_DEBUG_GUC
if (unlikely(desc->status))
goto corrupted;
+#endif
GEM_BUG_ON(tail > size);
@@ -815,8 +817,10 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
if (unlikely(ctb->broken))
return -EPIPE;
+#ifdef CONFIG_DRM_I915_DEBUG_GUC
if (unlikely(desc->status))
goto corrupted;
+#endif
GEM_BUG_ON(head > size);
--
2.34.1
next reply other threads:[~2022-01-20 18:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-20 18:24 Matthew Brost [this message]
2022-01-20 18:24 ` [PATCH] drm/i915/guc: Don't check CT descriptor status before CT write / read Matthew Brost
2022-01-21 2:58 ` [Intel-gfx] " kernel test robot
2022-01-21 2:58 ` kernel test robot
2022-01-21 5:25 ` kernel test robot
2022-01-21 5:25 ` kernel test robot
2022-01-21 5:55 ` kernel test robot
2022-01-21 5:55 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220120182413.8074-1-matthew.brost@intel.com \
--to=matthew.brost@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.