From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
To: "Upadhyay, Tejas" <tejas.upadhyay@intel.com>,
"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Cc: "Brost, Matthew" <matthew.brost@intel.com>,
"Harrison, John C" <john.c.harrison@intel.com>
Subject: Re: [PATCH] drm/xe/guc: Escalate GuC load failure immediately
Date: Tue, 11 Feb 2025 09:07:39 -0800 [thread overview]
Message-ID: <988cf01d-fca8-4151-82a8-36f6ea1698c8@intel.com> (raw)
In-Reply-To: <SJ1PR11MB6204F3EF51FC309DADA9782B81FD2@SJ1PR11MB6204.namprd11.prod.outlook.com>
On 2/11/2025 1:53 AM, Upadhyay, Tejas wrote:
>
>> -----Original Message-----
>> From: Intel-xe <intel-xe-bounces@lists.freedesktop.org> On Behalf Of Daniele
>> Ceraolo Spurio
>> Sent: Tuesday, February 11, 2025 6:17 AM
>> To: intel-xe@lists.freedesktop.org
>> Cc: Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com>; Brost,
>> Matthew <matthew.brost@intel.com>; Harrison, John C
>> <john.c.harrison@intel.com>
>> Subject: [PATCH] drm/xe/guc: Escalate GuC load failure immediately
>>
>> When the Xe was first introduced, we intentionally avoided escalating GuC
>> load failures, to not abort mid-probe. Xe is now mature enough and we
>> gracefully handle probe failures, so we can start escalating immediately.
>>
>> Note that even without this patch the probe is still aborted because the
>> attempt to enable CTs after GuC load will fail and that failure is already
>> escalated.
>>
>> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>> Cc: Matthew Brost <matthew.brost@intel.com>
>> Cc: John Harrison <John.C.Harrison@Intel.com>
>> ---
>> drivers/gpu/drm/xe/xe_guc.c | 10 +++++++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_guc.c b/drivers/gpu/drm/xe/xe_guc.c index
>> 1619c0a52db9..13c3084c42c2 100644
>> --- a/drivers/gpu/drm/xe/xe_guc.c
>> +++ b/drivers/gpu/drm/xe/xe_guc.c
>> @@ -938,7 +938,7 @@ static s32 guc_pc_get_cur_freq(struct xe_guc_pc
>> *guc_pc) #endif
>> #define GUC_LOAD_TIME_WARN_MS 200
>>
>> -static void guc_wait_ucode(struct xe_guc *guc)
>> +static int guc_wait_ucode(struct xe_guc *guc)
>> {
>> struct xe_gt *gt = guc_to_gt(guc);
>> struct xe_mmio *mmio = >->mmio;
>> @@ -1045,6 +1045,8 @@ static void guc_wait_ucode(struct xe_guc *guc)
>> delta_ms, xe_guc_pc_get_act_freq(guc_pc),
>> guc_pc_get_cur_freq(guc_pc),
>> before_freq, status, count);
>> }
>> +
>> + return load_done ? 0 : -EIO;
> Do you see possibility of load_done to be -1 and you will return success here?
You're right, I'll change this to load_done == 1.
Daniele
>
> Tejas
>> }
>>
>> static int __xe_guc_upload(struct xe_guc *guc) @@ -1077,14 +1079,16 @@
>> static int __xe_guc_upload(struct xe_guc *guc)
>> goto out;
>>
>> /* Wait for authentication */
>> - guc_wait_ucode(guc);
>> + ret = guc_wait_ucode(guc);
>> + if (ret)
>> + goto out;
>>
>> xe_uc_fw_change_status(&guc->fw, XE_UC_FIRMWARE_RUNNING);
>> return 0;
>>
>> out:
>> xe_uc_fw_change_status(&guc->fw, XE_UC_FIRMWARE_LOAD_FAIL);
>> - return 0 /* FIXME: ret, don't want to stop load currently */;
>> + return ret;
>> }
>>
>> static int vf_guc_min_load_for_hwconfig(struct xe_guc *guc)
>> --
>> 2.43.0
next prev parent reply other threads:[~2025-02-11 17:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-11 0:47 [PATCH] drm/xe/guc: Escalate GuC load failure immediately Daniele Ceraolo Spurio
2025-02-11 1:40 ` ✓ CI.Patch_applied: success for " Patchwork
2025-02-11 1:40 ` ✓ CI.checkpatch: " Patchwork
2025-02-11 1:41 ` ✓ CI.KUnit: " Patchwork
2025-02-11 1:57 ` ✓ CI.Build: " Patchwork
2025-02-11 1:59 ` ✗ CI.Hooks: failure " Patchwork
2025-02-11 2:00 ` ✗ CI.checksparse: warning " Patchwork
2025-02-11 2:19 ` ✓ Xe.CI.BAT: success " Patchwork
2025-02-11 3:40 ` [PATCH] " Matthew Brost
2025-02-11 9:53 ` Upadhyay, Tejas
2025-02-11 17:07 ` Daniele Ceraolo Spurio [this message]
2025-02-12 19:11 ` Upadhyay, Tejas
2025-02-11 13:57 ` ✗ 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=988cf01d-fca8-4151-82a8-36f6ea1698c8@intel.com \
--to=daniele.ceraolospurio@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=john.c.harrison@intel.com \
--cc=matthew.brost@intel.com \
--cc=tejas.upadhyay@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