[Intel-gfx] [PATCH 07/11] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Thu Oct 19 10:09:53 UTC 2017
On 18/10/2017 07:46, Sagar Arun Kamble wrote:
> Disabling GuC interrupts involves access to GuC IRQ control registers
> hence ensure device is RPM awake.
>
> v2: Add comment about need to synchronize flush work and log runtime
> destroy
>
> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble at intel.com>
> Cc: Michal Wajdeczko <michal.wajdeczko at intel.com>
> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin 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/intel_guc_log.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c
> index f87e9f5..ed239cb 100644
> --- a/drivers/gpu/drm/i915/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/intel_guc_log.c
> @@ -656,8 +656,17 @@ void i915_guc_log_unregister(struct drm_i915_private *dev_priv)
> {
> mutex_lock(&dev_priv->drm.struct_mutex);
> /* GuC logging is currently the only user of Guc2Host interrupts */
> - if (i915_modparams.guc_log_level >= 0)
> + if (i915_modparams.guc_log_level >= 0) {
> + intel_runtime_pm_get(dev_priv);
> intel_disable_guc_interrupts(&dev_priv->guc);
> + intel_runtime_pm_put(dev_priv);
Is it possible to trigger the assert from I915_WRITE today and if so
which test case?
> + }
> + /*
> + * TODO: Need to synchronize access to relay channel from flush work
> + * and release here if interrupt stays enabled from hereon.
> + * Possibly with GuC CT recv. interrupts will stay enabled until GEM
> + * suspend/unload.
> + */
I think we normally don't put such reminders in code. Regardless if it
is going away in this patch series or not it looks equally pointless to me.
> guc_log_runtime_destroy(&dev_priv->guc);
Ha right, this is how the cleanup happens what I was wondering in the
previous patch. So intel_guc_log_destroy is pretty pointless now since
it effectively does only this. Or I missed something?
> mutex_unlock(&dev_priv->drm.struct_mutex);
> }
>
Regards,
Tvrtko
More information about the Intel-gfx
mailing list