Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Raag Jadav <raag.jadav@intel.com>
To: "Tauro, Riana" <riana.tauro@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>,
	"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"Vivekanandan,
	Balasubramani" <balasubramani.vivekanandan@intel.com>
Subject: Re: [PATCH] drm/xe/cri: Implement workaround Wa_15020021844
Date: Tue, 13 Oct 2026 07:22:35 +0200	[thread overview]
Message-ID: <as3AGwcjolGc0hcf@black.igk.intel.com> (raw)
In-Reply-To: <ad1c34ce-7481-4ba9-9cb7-662caed35528@intel.com>

On Tue, Oct 13, 2026 at 10:19:29AM +0530, Tauro, Riana wrote:
> On 13-10-2026 05:00, Matt Roper wrote:
> > On Crescent Island platforms, the pcode is signaling "ready" to the
> > driver prematurely since one last sysctrl firmware initialization step
> > is still underway and not fully complete.  Since the driver's
> > initialization is racing with the end of the firmware's init, this can
> > lead to error messages like:
> > 
> >     xe 0000:be:00.0: [drm] *ERROR* sysctrl: Firmware error: 0x06
> >     xe 0000:be:00.0: [drm] *ERROR* sysctrl: Mailbox command failed: -EIO
> 
> i see boot survivability having failure codes for sysctrl. Shouldn't pcode
> ready be indicated
> only after the firmware is ready?

+1. This loosk like we have no indication of firmware being ready and we'll
still end up with same failure in case sysctrl decides to have a bad day.

Raag

> > The current recommenedation to work around this is for the driver to
> > wait an additional 0.5 seconds after getting the "ready" response,
> > before moving on with other initialization tasks.
> > 
> > Note that the official definition of this workaround is still being
> > finalized, so "Wa_15020021844" is a bit of a placeholder/guess.  It's
> > possible that the actual number could still change, although the request
> > to wait the additional half second is pretty well set at this point.
> > 
> > Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
> > Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> > ---
> >   drivers/gpu/drm/xe/xe_device_wa_oob.rules | 1 +
> >   drivers/gpu/drm/xe/xe_pcode.c             | 5 +++++
> >   2 files changed, 6 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/xe/xe_device_wa_oob.rules b/drivers/gpu/drm/xe/xe_device_wa_oob.rules
> > index d8dc41851425c..0488a20461d81 100644
> > --- a/drivers/gpu/drm/xe/xe_device_wa_oob.rules
> > +++ b/drivers/gpu/drm/xe/xe_device_wa_oob.rules
> > @@ -7,3 +7,4 @@
> >   14026633728	PLATFORM(CRESCENTISLAND)
> >   14026746987	PLATFORM(CRESCENTISLAND)
> >   14026779378	PLATFORM(CRESCENTISLAND)
> > +15020021844	PLATFORM(CRESCENTISLAND)
> > diff --git a/drivers/gpu/drm/xe/xe_pcode.c b/drivers/gpu/drm/xe/xe_pcode.c
> > index 266deecbb100a..897d44ecae42b 100644
> > --- a/drivers/gpu/drm/xe/xe_pcode.c
> > +++ b/drivers/gpu/drm/xe/xe_pcode.c
> > @@ -11,6 +11,7 @@
> >   #include <drm/drm_managed.h>
> > +#include "generated/xe_device_wa_oob.h"
> >   #include "regs/xe_pmt.h"
> >   #include "xe_assert.h"
> >   #include "xe_device.h"
> > @@ -20,6 +21,7 @@
> >   #include "xe_pm.h"
> >   #include "xe_printk.h"
> >   #include "xe_vsec.h"
> > +#include "xe_wa.h"
> >   /**
> >    * DOC: PCODE
> > @@ -320,6 +322,9 @@ int xe_pcode_ready(struct xe_device *xe, bool locked)
> >   		xe_log_err(tile, PCODE, ret, "initialization timedout after %ld seconds\n",
> >   			   timeout_us / USEC_PER_SEC);
> > +	if (!ret && XE_DEVICE_WA(xe, 15020021844))
> > +		msleep(500);
> > +
> >   	return ret;
> >   }

  reply	other threads:[~2026-10-13  5:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-12 23:30 [PATCH] drm/xe/cri: Implement workaround Wa_15020021844 Matt Roper
2026-10-13  0:30 ` ✓ CI.KUnit: success for " Patchwork
2026-10-13  4:03 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-13  4:49 ` [PATCH] " Tauro, Riana
2026-10-13  5:22   ` Raag Jadav [this message]
2026-10-13 15:13     ` Matt Roper
2026-10-13 13:39 ` ✗ Xe.CI.FULL: failure for " Patchwork

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=as3AGwcjolGc0hcf@black.igk.intel.com \
    --to=raag.jadav@intel.com \
    --cc=balasubramani.vivekanandan@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.d.roper@intel.com \
    --cc=riana.tauro@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