| Message ID | 20180323151414.62580-2-michal.wajdeczko@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 3/23/2018 8:44 PM, Michal Wajdeczko wrote: > We should not leave GuC submission enabled after sanitize, > as we are going to reset all GuC/HuC hardware. > > Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> > Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> > Cc: Chris Wilson <chris@chris-wilson.co.uk> Either we need now destroy the doorbells cleanly or remove the below comment from clients_doorbell_fini: /* * By the time we're here, GuC has already been reset. * Instead of trying (in vain) to communicate with it, let's just * cleanup the doorbell HW and our internal state. */ One additional thing I feel we should do now is remove uc_suspend|resume from gem_suspend|resume because we don't want to do any GuC actions once we suspend it. > --- > drivers/gpu/drm/i915/intel_uc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c > index 34f8a2c..2389828 100644 > --- a/drivers/gpu/drm/i915/intel_uc.c > +++ b/drivers/gpu/drm/i915/intel_uc.c > @@ -331,6 +331,9 @@ void intel_uc_sanitize(struct drm_i915_private *i915) > > GEM_BUG_ON(!HAS_GUC(i915)); > > + if (USES_GUC_SUBMISSION(dev_priv)) > + intel_guc_submission_disable(guc); > + > guc_disable_communication(guc); > > intel_huc_sanitize(huc);
On Mon, 26 Mar 2018 12:36:05 +0200, Sagar Arun Kamble <sagar.a.kamble@intel.com> wrote: > > > On 3/23/2018 8:44 PM, Michal Wajdeczko wrote: >> We should not leave GuC submission enabled after sanitize, >> as we are going to reset all GuC/HuC hardware. >> >> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> >> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> >> Cc: Chris Wilson <chris@chris-wilson.co.uk> > Either we need now destroy the doorbells cleanly or remove the below > comment from clients_doorbell_fini: > /* > * By the time we're here, GuC has already been reset. > * Instead of trying (in vain) to communicate with it, let's > just > * cleanup the doorbell HW and our internal state. > */ Good catch! I'll restore symmetric doorbell cleanup in separate patch right after this one. > > One additional thing I feel we should do now is remove uc_suspend|resume > from gem_suspend|resume > because we don't want to do any GuC actions once we suspend it. Hmm, I would keep it to maintain symmetry with gem, and in us_resume we already have guard for checking unloaded/sanitized GuC. /m >> --- >> drivers/gpu/drm/i915/intel_uc.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/intel_uc.c >> b/drivers/gpu/drm/i915/intel_uc.c >> index 34f8a2c..2389828 100644 >> --- a/drivers/gpu/drm/i915/intel_uc.c >> +++ b/drivers/gpu/drm/i915/intel_uc.c >> @@ -331,6 +331,9 @@ void intel_uc_sanitize(struct drm_i915_private >> *i915) >> GEM_BUG_ON(!HAS_GUC(i915)); >> + if (USES_GUC_SUBMISSION(dev_priv)) >> + intel_guc_submission_disable(guc); >> + >> guc_disable_communication(guc); >> intel_huc_sanitize(huc);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 34f8a2c..2389828 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -331,6 +331,9 @@ void intel_uc_sanitize(struct drm_i915_private *i915) GEM_BUG_ON(!HAS_GUC(i915)); + if (USES_GUC_SUBMISSION(dev_priv)) + intel_guc_submission_disable(guc); + guc_disable_communication(guc); intel_huc_sanitize(huc);
We should not leave GuC submission enabled after sanitize, as we are going to reset all GuC/HuC hardware. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/intel_uc.c | 3 +++ 1 file changed, 3 insertions(+)