[PATCH 17/21] drm/i915/uc: Update GEM runtime resume with need for reload of GuC/HuC

Sagar Arun Kamble sagar.a.kamble at intel.com
Thu Oct 12 04:30:10 UTC 2017


On resume from drm sleep/suspend, we have gem_init_hw path to reload
the GuC/HuC firmware. However, on resume from runtime suspend we needed
to add support to reload the GuC/HuC firmware and resume.
We can leverage intel_uc_init_hw for this during runtime resume.

Signed-off-by: Sagar Arun Kamble <sagar.a.kamble at intel.com>
Cc: Chris Wilson <chris at chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko at intel.com>
Cc: MichaƂ Winiarski <michal.winiarski at intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
---
 drivers/gpu/drm/i915/intel_uc.c | 67 ++++++++++++++++++++++++++++-------------
 1 file changed, 46 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 2b546be..db063fa 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -458,6 +458,8 @@ int intel_uc_runtime_suspend(struct drm_i915_private *dev_priv)
 	gen9_disable_guc_interrupts(dev_priv);
 	guc_disable_communication(guc);
 
+	guc->suspended = true;
+
 	goto out;
 
 out:
@@ -478,34 +480,57 @@ int intel_uc_runtime_suspend(struct drm_i915_private *dev_priv)
 void intel_uc_runtime_resume(struct drm_i915_private *dev_priv)
 {
 	struct intel_guc *guc = &dev_priv->guc;
+	struct intel_huc *huc = &dev_priv->huc;
 	int ret;
 
-	if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
+	if (!guc->suspended)
 		return;
 
-	ret = guc_enable_communication(guc);
-	if (ret) {
-		DRM_DEBUG_DRIVER("GuC communication enable failed (%d)\n", ret);
-		return;
-	}
+	/*
+	 * If WOPCM is locked then GuC and HuC are still loaded. We just
+	 * need to enable communication with GuC, enable interrupts,
+	 * invoke GuC action to resume from sleep and enable submission.
+	 * If WOPCM is not locked it is similar to fresh boot and we need
+	 * reload the GuC/HuC firmwares and enable other GuC related
+	 * mechanisms. Post reloading GuC we need to send action to resume
+	 * from sleep for GuC to restore its state prior to suspend.
+	 */
+	if (guc_is_loaded(guc)) {
+		huc->fw.load_status = INTEL_UC_FIRMWARE_SUCCESS;
+		guc->fw.load_status = INTEL_UC_FIRMWARE_SUCCESS;
 
-	if (i915_modparams.guc_log_level >= 0)
-		gen9_enable_guc_interrupts(dev_priv);
+		ret = guc_enable_communication(guc);
+		if (ret) {
+			DRM_DEBUG_DRIVER("GuC communication enable "
+					 "failed (%d)\n", ret);
+			return;
+		}
 
-	ret = intel_guc_resume(guc);
-	if (ret)
-		DRM_ERROR("GuC resume failed (%d)."
-			  "GuC functions may not work\n", ret);
+		if (i915_modparams.guc_log_level >= 0)
+			gen9_enable_guc_interrupts(dev_priv);
 
-	/*
-	 * TODO: Note that currently GuC submission is not being disabled
-	 * prior to GuC suspend. Hence we skip enabling here. It is
-	 * recommended to release all doorbells during suspend and acquire
-	 * here. Once we update guc_submission_disable to only destroy
-	 * doorbell and not free/unmap client vmas, we will acquire
-	 * doorbell here without alloc/free of client vmas. Post that we
-	 * can possibly unify uc_suspend/resume and uc_runtime_suspend/resume.
-	 */
+		ret = intel_guc_resume(guc);
+		if (ret)
+			DRM_ERROR("GuC resume failed (%d)."
+				  "GuC functions may not work\n", ret);
+
+		/*
+		 * TODO: Note that currently GuC submission is not being
+		 * disabled prior to GuC suspend. Hence we skip enabling here.
+		 * It is recommended to release all doorbells during suspend
+		 * and acquire here. Once we update guc_submission_disable to
+		 * only destroy doorbell and not free/unmap client vmas, we will
+		 * acquire doorbell here without alloc/free of client vmas. Post
+		 * that we can possibly unify uc_suspend/resume and
+		 * uc_runtime_suspend/resume.
+		 */
+		guc->suspended = false;
+	}  else {
+		DRM_DEBUG_DRIVER("GuC not available. Loading firmware and then"
+				 " resuming.\n");
+		guc->skip_load_on_resume = false;
+		intel_uc_init_hw(dev_priv);
+	}
 }
 
 /**
-- 
1.9.1



More information about the Intel-gfx-trybot mailing list