[Intel-gfx] [PATCH] drm/i915/guc: GuC suspend path cleanup
Sujaritha
sujaritha.sundaresan at intel.com
Thu Mar 21 19:46:11 UTC 2019
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 at intel.com>
>>> Cc: Chris Wilson <chris at chris-wilson.co.uk>
>>> Cc: Michal Wajdeczko <michal.wajdeczko at intel.com>
>>> Signed-off-by: Sujaritha Sundaresan <sujaritha.sundaresan at intel.com>
>>> ---
>>> 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
More information about the Intel-gfx
mailing list