intel-xe.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Chang, Yu bruce" <yu.bruce.chang@intel.com>
To: "De Marchi, Lucas" <lucas.demarchi@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [Intel-xe] [PATCH] drm/xe: don't auto fall back to execlist mode if guc failed to init
Date: Fri, 24 Mar 2023 15:57:32 +0000	[thread overview]
Message-ID: <CY8PR11MB69401805DBB626806F6D818BC3849@CY8PR11MB6940.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20230324071424.ctpkvjhsuxbp3ghx@ldmartin-desk2.lan>



> -----Original Message-----
> From: De Marchi, Lucas <lucas.demarchi@intel.com>
> Sent: Friday, March 24, 2023 12:14 AM
> To: Chang, Yu bruce <yu.bruce.chang@intel.com>
> Cc: intel-xe@lists.freedesktop.org
> Subject: Re: [Intel-xe] [PATCH] drm/xe: don't auto fall back to execlist mode
> if guc failed to init
> 
> On Thu, Mar 23, 2023 at 08:23:13PM +0000, Chang, Bruce wrote:
> >In general, this is due to FW load failure, should just report error
> >and fail the probe so that user can easily retry again.
> >
> >Cc: Matt Roper <matthew.d.roper@intel.com>
> >Signed-off-by: Bruce Chang <yu.bruce.chang@intel.com>
> >---
> > drivers/gpu/drm/xe/xe_gt.c | 4 ++--
> > drivers/gpu/drm/xe/xe_uc.c | 3 ---
> > 2 files changed, 2 insertions(+), 5 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
> >index daa433d0f2f5..8a436c95591e 100644
> >--- a/drivers/gpu/drm/xe/xe_gt.c
> >+++ b/drivers/gpu/drm/xe/xe_gt.c
> >@@ -455,9 +455,9 @@ static int gt_fw_domain_init(struct xe_gt *gt)
> > 			goto err_force_wake;
> > 	}
> >
> >-	/* Allow driver to load if uC init fails (likely missing firmware) */
> > 	err = xe_uc_init(&gt->uc);
> >-	XE_WARN_ON(err);
> >+	if (err)
> >+		goto err_force_wake;
> >
> > 	err = xe_uc_init_hwconfig(&gt->uc);
> > 	if (err)
> >diff --git a/drivers/gpu/drm/xe/xe_uc.c b/drivers/gpu/drm/xe/xe_uc.c
> >index 4ccf2b3435e1..70eabf567156 100644
> >--- a/drivers/gpu/drm/xe/xe_uc.c
> >+++ b/drivers/gpu/drm/xe/xe_uc.c
> >@@ -54,9 +54,6 @@ int xe_uc_init(struct xe_uc *uc)
> > 	return 0;
> >
> > err:
> >-	/* If any uC firmwares not found, fall back to execlists */
> >-	xe_device_guc_submission_disable(uc_to_xe(uc));
> >-
> 
> now that we are not disabling submission, isn't there anything to undo from
> the steps above? if so, then the goto's can be simply removed?
> 
The guc_init failure is not supposed to disable guc submission since it
is supposed to be only enabled later in xe_guc_submit_init.

The xe_device_guc_submission_disable is just to indicate not to continue enable
Guc submission if we want the driver to continue the init process. But since this patch
will fail probe as a whole, so this flag is really no much usage.

> one thing that seems very wrong in the previous state of the code is disabling
> guc submission if huc failed.
> 
Right, actually this should have different steps to revert each previous init step here.
But I think that is a more than this patch is intended to do.

-Bruce

> 
> Lucas De Marchi
> 
> > 	return ret;
> > }
> >
> >--
> >2.25.1
> >

      reply	other threads:[~2023-03-24 15:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-23 20:23 [Intel-xe] [PATCH] drm/xe: don't auto fall back to execlist mode if guc failed to init Chang, Bruce
2023-03-23 20:25 ` [Intel-xe] ✓ CI.Patch_applied: success for " Patchwork
2023-03-23 20:26 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-03-23 20:30 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-03-23 20:52 ` [Intel-xe] ○ CI.BAT: info " Patchwork
2023-03-23 22:52 ` [Intel-xe] [PATCH] " Matthew Brost
2023-03-23 23:08   ` Chang, Yu bruce
2023-03-24  7:37     ` Mauro Carvalho Chehab
2023-03-24 15:15       ` Lucas De Marchi
2023-03-24 16:15     ` Rodrigo Vivi
2023-03-29 19:13       ` Rodrigo Vivi
2023-03-29 20:00         ` Chang, Yu bruce
2023-03-29 20:11           ` Rodrigo Vivi
2023-03-29 20:16             ` Chang, Yu bruce
2023-03-24  7:14 ` Lucas De Marchi
2023-03-24 15:57   ` Chang, Yu bruce [this message]

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=CY8PR11MB69401805DBB626806F6D818BC3849@CY8PR11MB6940.namprd11.prod.outlook.com \
    --to=yu.bruce.chang@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@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;
as well as URLs for NNTP newsgroup(s).