On Mon, 26 Mar 2018 12:36:05 +0200, Sagar Arun Kamble
<sagar.a.kamble@xxxxxxxxx> 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@xxxxxxxxx>
Cc: Sagar Arun Kamble <sagar.a.kamble@xxxxxxxxx>
Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
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);
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
