Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Raag Jadav <raag.jadav@intel.com>
To: intel-xe@lists.freedesktop.org
Cc: matthew.brost@intel.com, michal.wajdeczko@intel.com,
	lukasz.laguna@intel.com, daniele.ceraolospurio@intel.com,
	sk.anirban@intel.com, Raag Jadav <raag.jadav@intel.com>
Subject: [PATCH v1] drm/xe/guc: Allow GuC CT for wedged device
Date: Fri, 21 Aug 2026 17:51:14 +0530	[thread overview]
Message-ID: <20260821122114.567725-1-raag.jadav@intel.com> (raw)

Commit 50fa9acac26f ("drm/xe/guc: distinguish wedged from recoverable
cancellation") introduced distinguishable error codes for g2h failure
cases, but also blocked GuC CT for wedged device. This is problematic
in cases where we want to prevent user from accessing the device but
also keep GuC CT functioning on temporarily wedged device. First user
of such requirement is PCIe FLR handling where we require uC firmware
loading while the device is temporarily wedged.

Fixes: 50fa9acac26f ("drm/xe/guc: distinguish wedged from recoverable cancellation")
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
---
 drivers/gpu/drm/xe/xe_guc_ct.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
index 5c4733da385c..97e38147effd 100644
--- a/drivers/gpu/drm/xe/xe_guc_ct.c
+++ b/drivers/gpu/drm/xe/xe_guc_ct.c
@@ -1062,11 +1062,6 @@ static int __guc_ct_send_locked(struct xe_guc_ct *ct, const u32 *action,
 	xe_gt_assert(gt, g2h_len || !num_g2h);
 	lockdep_assert_held(&ct->lock);
 
-	if (xe_device_wedged(ct_to_xe(ct))) {
-		ret = -ENOTRECOVERABLE;
-		goto out;
-	}
-
 	if (unlikely(ct->ctbs.h2g.info.broken)) {
 		ret = -EPIPE;
 		goto out;
@@ -1813,9 +1808,6 @@ static int g2h_read(struct xe_guc_ct *ct, u32 *msg, bool fast_path)
 	xe_gt_assert(gt, xe_guc_ct_initialized(ct));
 	lockdep_assert_held(&ct->fast_lock);
 
-	if (xe_device_wedged(xe))
-		return -ENOTRECOVERABLE;
-
 	if (ct->state == XE_GUC_CT_STATE_DISABLED)
 		return -ENODEV;
 
-- 
2.43.0


             reply	other threads:[~2026-08-21 12:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21 12:21 Raag Jadav [this message]
2026-08-21 12:28 ` ✓ CI.KUnit: success for drm/xe/guc: Allow GuC CT for wedged device Patchwork
2026-08-21 12:42 ` [PATCH v1] " sashiko-bot
2026-08-21 13:31 ` ✓ Xe.CI.BAT: success for " Patchwork
2026-08-21 17:27 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-08-25  9:39 ` [PATCH v1] " Laguna, Lukasz
2026-08-25 10:04   ` Raag Jadav
2026-08-25 10:53     ` Laguna, Lukasz
2026-08-25 12:49       ` Raag Jadav
2026-08-25 13:40         ` Laguna, Lukasz

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=20260821122114.567725-1-raag.jadav@intel.com \
    --to=raag.jadav@intel.com \
    --cc=daniele.ceraolospurio@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lukasz.laguna@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=michal.wajdeczko@intel.com \
    --cc=sk.anirban@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox