On 3/21/19 10:54 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-03-21 17:49:55)
On 3/21/19 10:14 AM, Sujaritha Sundaresan wrote:
Adding a call to intel_uc_suspend in i915_gem_suspend, which
is a common point for the suspend/resume and hibernate paths.
This fixes an unbalanced call that causes issues with the CTB
register/deregister.
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@xxxxxxxxx>
Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Michal Wajdeczko <michal.wajdeczko@xxxxxxxxx>
Signed-off-by: Sujaritha Sundaresan <sujaritha.sundaresan@xxxxxxxxx>
---
drivers/gpu/drm/i915/i915_gem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1a684b7e8c09..980855ebdeda 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4371,6 +4371,9 @@ void i915_gem_suspend(struct drm_i915_private *i915)
*/
switch_to_kernel_context_sync(i915, i915->gt.active_engines);
+ if (!__i915_wedged(&i915->gpu_error))
+ intel_uc_suspend(i915);
We can probably call intel_uc_suspend unconditionally, because it
internally checks for INTEL_UC_FIRMWARE_SUCCESS, which should be false
if we wedged due to the uc_reset_prepare we added to the wedge function.
\o/ I was hoping there was a more natural test inside intel_uc.
-Chris
Sure that seems like a more straight forward check.
I will drop the condition.
-Sujaritha
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
