All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: John Harrison <john.c.harrison@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 06/18] drm/i915/guc: Drop guc->interrupts.enabled
Date: Thu, 27 May 2021 10:13:55 -0700	[thread overview]
Message-ID: <20210527171354.GA12785@sdutt-i7> (raw)
In-Reply-To: <3b1eadf8-b043-365f-ada9-3a87901e8159@intel.com>

On Thu, May 27, 2021 at 10:17:20AM -0700, John Harrison wrote:
> On 5/25/2021 23:42, Matthew Brost wrote:
> > Drop the variable guc->interrupts.enabled as this variable is just
> > leading to bugs creeping into the code.
> > 
> > e.g. A full GPU reset disables the GuC interrupts but forgot to clear
> > guc->interrupts.enabled, guc->interrupts.enabled being true suppresses
> > interrupts from getting re-enabled and now we are broken.
> > 
> > It is harmless to enable interrupt while already enabled so let's just
> > delete this variable to avoid bugs like this going forward.
> Is it worth leaving the enabled flag in place but only using it to trip a
> WARN to catch such cases in a less catastrophic manner? Or are there valid
> reasons for calling enable when already enabled?
>

I don't think so as mentioned above a reset disables these interrupts
and if we didn't clear this field the WARN_ON would be triggered making
CI unhappy. Yes, the bug would less catastrophic but we'd still have to
waste time and energy chasing it.

Matt 
 
> Either way, it seems like a plausible change and CI is happy with it, so:
> Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
> 
> John.
> 
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > ---
> >   drivers/gpu/drm/i915/gt/uc/intel_guc.c | 27 +++++++++-----------------
> >   drivers/gpu/drm/i915/gt/uc/intel_guc.h |  1 -
> >   2 files changed, 9 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > index ab2c8fe8cdfa..18da9ed15728 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > @@ -96,12 +96,9 @@ static void gen9_enable_guc_interrupts(struct intel_guc *guc)
> >   	assert_rpm_wakelock_held(&gt->i915->runtime_pm);
> >   	spin_lock_irq(&gt->irq_lock);
> > -	if (!guc->interrupts.enabled) {
> > -		WARN_ON_ONCE(intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
> > -			     gt->pm_guc_events);
> > -		guc->interrupts.enabled = true;
> > -		gen6_gt_pm_enable_irq(gt, gt->pm_guc_events);
> > -	}
> > +	WARN_ON_ONCE(intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
> > +		     gt->pm_guc_events);
> > +	gen6_gt_pm_enable_irq(gt, gt->pm_guc_events);
> >   	spin_unlock_irq(&gt->irq_lock);
> >   }
> > @@ -112,7 +109,6 @@ static void gen9_disable_guc_interrupts(struct intel_guc *guc)
> >   	assert_rpm_wakelock_held(&gt->i915->runtime_pm);
> >   	spin_lock_irq(&gt->irq_lock);
> > -	guc->interrupts.enabled = false;
> >   	gen6_gt_pm_disable_irq(gt, gt->pm_guc_events);
> > @@ -134,18 +130,14 @@ static void gen11_reset_guc_interrupts(struct intel_guc *guc)
> >   static void gen11_enable_guc_interrupts(struct intel_guc *guc)
> >   {
> >   	struct intel_gt *gt = guc_to_gt(guc);
> > +	u32 events = REG_FIELD_PREP(ENGINE1_MASK, GUC_INTR_GUC2HOST);
> >   	spin_lock_irq(&gt->irq_lock);
> > -	if (!guc->interrupts.enabled) {
> > -		u32 events = REG_FIELD_PREP(ENGINE1_MASK, GUC_INTR_GUC2HOST);
> > -
> > -		WARN_ON_ONCE(gen11_gt_reset_one_iir(gt, 0, GEN11_GUC));
> > -		intel_uncore_write(gt->uncore,
> > -				   GEN11_GUC_SG_INTR_ENABLE, events);
> > -		intel_uncore_write(gt->uncore,
> > -				   GEN11_GUC_SG_INTR_MASK, ~events);
> > -		guc->interrupts.enabled = true;
> > -	}
> > +	WARN_ON_ONCE(gen11_gt_reset_one_iir(gt, 0, GEN11_GUC));
> > +	intel_uncore_write(gt->uncore,
> > +			   GEN11_GUC_SG_INTR_ENABLE, events);
> > +	intel_uncore_write(gt->uncore,
> > +			   GEN11_GUC_SG_INTR_MASK, ~events);
> >   	spin_unlock_irq(&gt->irq_lock);
> >   }
> > @@ -154,7 +146,6 @@ static void gen11_disable_guc_interrupts(struct intel_guc *guc)
> >   	struct intel_gt *gt = guc_to_gt(guc);
> >   	spin_lock_irq(&gt->irq_lock);
> > -	guc->interrupts.enabled = false;
> >   	intel_uncore_write(gt->uncore, GEN11_GUC_SG_INTR_MASK, ~0);
> >   	intel_uncore_write(gt->uncore, GEN11_GUC_SG_INTR_ENABLE, 0);
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index c20f3839de12..4abc59f6f3cd 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -33,7 +33,6 @@ struct intel_guc {
> >   	unsigned int msg_enabled_mask;
> >   	struct {
> > -		bool enabled;
> >   		void (*reset)(struct intel_guc *guc);
> >   		void (*enable)(struct intel_guc *guc);
> >   		void (*disable)(struct intel_guc *guc);
> 

WARNING: multiple messages have this Message-ID (diff)
From: Matthew Brost <matthew.brost@intel.com>
To: John Harrison <john.c.harrison@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 06/18] drm/i915/guc: Drop guc->interrupts.enabled
Date: Thu, 27 May 2021 10:13:55 -0700	[thread overview]
Message-ID: <20210527171354.GA12785@sdutt-i7> (raw)
In-Reply-To: <3b1eadf8-b043-365f-ada9-3a87901e8159@intel.com>

On Thu, May 27, 2021 at 10:17:20AM -0700, John Harrison wrote:
> On 5/25/2021 23:42, Matthew Brost wrote:
> > Drop the variable guc->interrupts.enabled as this variable is just
> > leading to bugs creeping into the code.
> > 
> > e.g. A full GPU reset disables the GuC interrupts but forgot to clear
> > guc->interrupts.enabled, guc->interrupts.enabled being true suppresses
> > interrupts from getting re-enabled and now we are broken.
> > 
> > It is harmless to enable interrupt while already enabled so let's just
> > delete this variable to avoid bugs like this going forward.
> Is it worth leaving the enabled flag in place but only using it to trip a
> WARN to catch such cases in a less catastrophic manner? Or are there valid
> reasons for calling enable when already enabled?
>

I don't think so as mentioned above a reset disables these interrupts
and if we didn't clear this field the WARN_ON would be triggered making
CI unhappy. Yes, the bug would less catastrophic but we'd still have to
waste time and energy chasing it.

Matt 
 
> Either way, it seems like a plausible change and CI is happy with it, so:
> Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
> 
> John.
> 
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > ---
> >   drivers/gpu/drm/i915/gt/uc/intel_guc.c | 27 +++++++++-----------------
> >   drivers/gpu/drm/i915/gt/uc/intel_guc.h |  1 -
> >   2 files changed, 9 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > index ab2c8fe8cdfa..18da9ed15728 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > @@ -96,12 +96,9 @@ static void gen9_enable_guc_interrupts(struct intel_guc *guc)
> >   	assert_rpm_wakelock_held(&gt->i915->runtime_pm);
> >   	spin_lock_irq(&gt->irq_lock);
> > -	if (!guc->interrupts.enabled) {
> > -		WARN_ON_ONCE(intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
> > -			     gt->pm_guc_events);
> > -		guc->interrupts.enabled = true;
> > -		gen6_gt_pm_enable_irq(gt, gt->pm_guc_events);
> > -	}
> > +	WARN_ON_ONCE(intel_uncore_read(gt->uncore, GEN8_GT_IIR(2)) &
> > +		     gt->pm_guc_events);
> > +	gen6_gt_pm_enable_irq(gt, gt->pm_guc_events);
> >   	spin_unlock_irq(&gt->irq_lock);
> >   }
> > @@ -112,7 +109,6 @@ static void gen9_disable_guc_interrupts(struct intel_guc *guc)
> >   	assert_rpm_wakelock_held(&gt->i915->runtime_pm);
> >   	spin_lock_irq(&gt->irq_lock);
> > -	guc->interrupts.enabled = false;
> >   	gen6_gt_pm_disable_irq(gt, gt->pm_guc_events);
> > @@ -134,18 +130,14 @@ static void gen11_reset_guc_interrupts(struct intel_guc *guc)
> >   static void gen11_enable_guc_interrupts(struct intel_guc *guc)
> >   {
> >   	struct intel_gt *gt = guc_to_gt(guc);
> > +	u32 events = REG_FIELD_PREP(ENGINE1_MASK, GUC_INTR_GUC2HOST);
> >   	spin_lock_irq(&gt->irq_lock);
> > -	if (!guc->interrupts.enabled) {
> > -		u32 events = REG_FIELD_PREP(ENGINE1_MASK, GUC_INTR_GUC2HOST);
> > -
> > -		WARN_ON_ONCE(gen11_gt_reset_one_iir(gt, 0, GEN11_GUC));
> > -		intel_uncore_write(gt->uncore,
> > -				   GEN11_GUC_SG_INTR_ENABLE, events);
> > -		intel_uncore_write(gt->uncore,
> > -				   GEN11_GUC_SG_INTR_MASK, ~events);
> > -		guc->interrupts.enabled = true;
> > -	}
> > +	WARN_ON_ONCE(gen11_gt_reset_one_iir(gt, 0, GEN11_GUC));
> > +	intel_uncore_write(gt->uncore,
> > +			   GEN11_GUC_SG_INTR_ENABLE, events);
> > +	intel_uncore_write(gt->uncore,
> > +			   GEN11_GUC_SG_INTR_MASK, ~events);
> >   	spin_unlock_irq(&gt->irq_lock);
> >   }
> > @@ -154,7 +146,6 @@ static void gen11_disable_guc_interrupts(struct intel_guc *guc)
> >   	struct intel_gt *gt = guc_to_gt(guc);
> >   	spin_lock_irq(&gt->irq_lock);
> > -	guc->interrupts.enabled = false;
> >   	intel_uncore_write(gt->uncore, GEN11_GUC_SG_INTR_MASK, ~0);
> >   	intel_uncore_write(gt->uncore, GEN11_GUC_SG_INTR_ENABLE, 0);
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index c20f3839de12..4abc59f6f3cd 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -33,7 +33,6 @@ struct intel_guc {
> >   	unsigned int msg_enabled_mask;
> >   	struct {
> > -		bool enabled;
> >   		void (*reset)(struct intel_guc *guc);
> >   		void (*enable)(struct intel_guc *guc);
> >   		void (*disable)(struct intel_guc *guc);
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-05-27 17:21 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-26  6:42 [PATCH 00/18] Non-interface changing GuC CTBs updates Matthew Brost
2021-05-26  6:42 ` [Intel-gfx] " Matthew Brost
2021-05-26  6:42 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Non-interface changing GuC CTBs updates (rev2) Patchwork
2021-05-27 17:13   ` John Harrison
2021-05-27 17:09     ` Matthew Brost
2021-05-26  6:42 ` [PATCH 01/18] drm/i915/guc: skip disabling CTBs before sanitizing the GuC Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26  6:42 ` [PATCH 02/18] drm/i915/guc: use probe_error log for CT enablement failure Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26  6:42 ` [PATCH 03/18] drm/i915/guc: enable only the user interrupt when using GuC submission Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26  6:42 ` [PATCH 04/18] drm/i915/guc: Remove sample_forcewake h2g action Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26  6:42 ` [PATCH 05/18] drm/i915/guc: Keep strict GuC ABI definitions Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26  6:42 ` [PATCH 06/18] drm/i915/guc: Drop guc->interrupts.enabled Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-27 17:17   ` John Harrison
2021-05-27 17:17     ` John Harrison
2021-05-27 17:13     ` Matthew Brost [this message]
2021-05-27 17:13       ` Matthew Brost
2021-05-26  6:42 ` [PATCH 07/18] drm/i915/guc: Stop using fence/status from CTB descriptor Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26  6:42 ` [PATCH 08/18] drm/i915: Promote ptrdiff() to i915_utils.h Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26  6:42 ` [PATCH 09/18] drm/i915/guc: Only rely on own CTB size Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26  6:42 ` [PATCH 10/18] drm/i915/guc: Don't repeat CTB layout calculations Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26  6:42 ` [PATCH 11/18] drm/i915/guc: Replace CTB array with explicit members Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26  6:42 ` [PATCH 12/18] drm/i915/guc: Update sizes of CTB buffers Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26  6:42 ` [PATCH 13/18] drm/i915/guc: Relax CTB response timeout Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26 12:25   ` Michal Wajdeczko
2021-05-26 12:25     ` [Intel-gfx] " Michal Wajdeczko
2021-05-26 17:38     ` Matthew Brost
2021-05-26 17:38       ` [Intel-gfx] " Matthew Brost
2021-05-26  6:42 ` [PATCH 14/18] drm/i915/guc: Start protecting access to CTB descriptors Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26  6:42 ` [PATCH 15/18] drm/i915/guc: Ensure H2G buffer updates visible before tail update Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26 12:36   ` Michal Wajdeczko
2021-05-26 12:36     ` [Intel-gfx] " Michal Wajdeczko
2021-05-26 17:58     ` Matthew Brost
2021-05-26 17:58       ` [Intel-gfx] " Matthew Brost
2021-05-28  1:13       ` John Harrison
2021-05-28  1:13         ` John Harrison
2021-05-28  6:52         ` Michal Wajdeczko
2021-05-28  6:52           ` Michal Wajdeczko
2021-05-26  6:42 ` [PATCH 16/18] drm/i915/guc: Stop using mutex while sending CTB messages Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26  6:42 ` [PATCH 17/18] drm/i915/guc: Don't receive all G2H messages in irq handler Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26  6:42 ` [PATCH 18/18] drm/i915/guc: Always copy CT message to new allocation Matthew Brost
2021-05-26  6:42   ` [Intel-gfx] " Matthew Brost
2021-05-26  6:43 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Non-interface changing GuC CTBs updates (rev2) Patchwork
2021-05-27 17:13   ` John Harrison
2021-05-27 17:08     ` Matthew Brost
2021-05-26  7:11 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-05-26  9:47 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210527171354.GA12785@sdutt-i7 \
    --to=matthew.brost@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=john.c.harrison@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.