[Intel-gfx] [PATCH v13 19/21] drm/i915/guc: Fix enable/disable of GuC GGTT invalidate functions
Sagar Arun Kamble
sagar.a.kamble at intel.com
Wed Oct 11 18:09:10 UTC 2017
On 10/11/2017 11:28 PM, Michal Wajdeczko wrote:
> On Wed, 11 Oct 2017 19:44:31 +0200, Sagar Arun Kamble
> <sagar.a.kamble at intel.com> wrote:
>
>>
>>
>> On 10/11/2017 11:05 PM, Michal Wajdeczko wrote:
>>> On Wed, 11 Oct 2017 10:54:14 +0200, Sagar Arun Kamble
>>> <sagar.a.kamble at intel.com> wrote:
>>>
>>>> i915_ggtt_enable_guc has to happen first during i915_gem_resume
>>>> if GuC loading is enabled before GTT restore. In case GuC is not
>>>> loaded this enabling happening during intel_uc_init_hw need to
>>>> skipped. (avoid the GEM_BUG_ON)
>>>> i915_ggtt_disable_guc at the end of reset/suspend/unload is needed
>>>> post GGTT suspend operations. Calling it during uc_sanitize covers
>>>> all scenarios. Hence, it is removed from intel_uc_fini_hw. Also these
>>>> needto be protected by struct_mutex. Hence struct_mutex locking is
>>>> added in i915_gem_sanitize while sanitizing uC. struct_mutex is
>>>> already
>>>> held during i915_gem_reset_prepare.
>>>>
>>>> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble at intel.com>
>>>> Cc: Michal Wajdeczko <michal.wajdeczko at intel.com>
>>>> Cc: Michał Winiarski <michal.winiarski at intel.com>
>>>> Cc: Chris Wilson <chris at chris-wilson.co.uk>
>>>> Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
>>>> ---
>>>> drivers/gpu/drm/i915/i915_gem.c | 4 ++++
>>>> drivers/gpu/drm/i915/intel_uc.c | 16 +++++++++++-----
>>>> 2 files changed, 15 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/i915_gem.c
>>>> b/drivers/gpu/drm/i915/i915_gem.c
>>>> index a4bbf6c..77a0746 100644
>>>> --- a/drivers/gpu/drm/i915/i915_gem.c
>>>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>>>> @@ -4759,6 +4759,10 @@ void i915_gem_resume(struct drm_i915_private
>>>> *dev_priv)
>>>> WARN_ON(dev_priv->gt.awake);
>>>> mutex_lock(&dev->struct_mutex);
>>>> + /* We need to notify the guc whenever we change the GGTT */
>>>> + if (i915_modparams.enable_guc_loading)
>>>> + i915_ggtt_enable_guc(dev_priv);
>>>> +
>>>> i915_gem_restore_gtt_mappings(dev_priv);
>>>> i915_gem_restore_fences(dev_priv);
>>>> diff --git a/drivers/gpu/drm/i915/intel_uc.c
>>>> b/drivers/gpu/drm/i915/intel_uc.c
>>>> index 9010ab5..0b799fe 100644
>>>> --- a/drivers/gpu/drm/i915/intel_uc.c
>>>> +++ b/drivers/gpu/drm/i915/intel_uc.c
>>>> @@ -184,8 +184,14 @@ int intel_uc_init_hw(struct drm_i915_private
>>>> *dev_priv)
>>>> guc_disable_communication(guc);
>>>> gen9_reset_guc_interrupts(dev_priv);
>>>> - /* We need to notify the guc whenever we change the GGTT */
>>>> - i915_ggtt_enable_guc(dev_priv);
>>>> + /*
>>>> + * We need to notify the guc whenever we change the GGTT.
>>>> + * During resume from sleep we would have already updated the
>>>> + * GGTT invalidate function for GuC during i915_gem_resume so
>>>> + * we need to skip here. Will enable here on driver load/reset.
>>>> + */
>>>> + if (!guc->suspended)
>>>> + i915_ggtt_enable_guc(dev_priv);
>>>> if (i915_modparams.enable_guc_submission) {
>>>> /*
>>>> @@ -309,9 +315,6 @@ void intel_uc_cleanup(struct drm_i915_private
>>>> *dev_priv)
>>>> guc_free_load_err_log(guc);
>>>> i915_guc_submission_cleanup(dev_priv);
>>>> -
>>>> - if (i915_modparams.enable_guc_loading)
>>>> - i915_ggtt_disable_guc(dev_priv);
>>>> }
>>>> /**
>>>> @@ -452,6 +455,9 @@ void intel_uc_sanitize(struct drm_i915_private
>>>> *dev_priv)
>>>> struct intel_uc_fw *huc_fw = &dev_priv->huc.fw;
>>>> if (i915_modparams.enable_guc_loading) {
>>>> + if (guc_fw->load_status == INTEL_UC_FIRMWARE_SUCCESS)
>>>
>>> Hmm, isn't that check redundant ?
>> uc_sanitize can happen without firmware loaded too in which case we
>
> If uc_sanitize can be loaded without firmware loaded, then I assume
> i915_modparams.enable_guc_loading will be cleared too, right ?
>
> I'm just wondering if we need to check both modparam and fw status.
actually load time uc_sanitize is happening before uc_sanitize_options
so enable_guc_loading will have
non-zero value for some platforms. So I think it makes sense to limit
this to only load_status based.
>
>> don't want to ggtt_disable_guc.
>> if we want to ggtt_disable_guc then we should remove the GEM_BUG_ON
>> in it.
>
> Hmm, this is the way how we run CI tests ;)
yes ... from long time :)
>
>>>
>>>> + i915_ggtt_disable_guc(dev_priv);
>>>> +
>>>> guc_fw->load_status = INTEL_UC_FIRMWARE_NONE;
>>>> huc_fw->load_status = INTEL_UC_FIRMWARE_NONE;
>>>> }
>>>
>>> Btw, what should we do with "suspended" flag during sanitize ?
>> suspended flag is set to true on suspend and false on resume.
>> sanitize is done post suspend and before resume so we should not
>> touch it.
>> initializing it to false during guc_init_early should take care of
>> reload (during unload we are suspending gem but we wont resume)
More information about the Intel-gfx
mailing list