Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/dg2: Catch and log more unexpected values in DG1_MSTR_TILE_INTR
Date: Wed, 25 May 2022 11:05:35 -0700	[thread overview]
Message-ID: <Yo5v7/pLw4eF8xxw@mdroper-desk1.amr.corp.intel.com> (raw)
In-Reply-To: <f37468b3-1066-ee4b-fb5b-7664fd180fd6@linux.intel.com>

On Wed, May 25, 2022 at 05:03:13PM +0100, Tvrtko Ursulin wrote:
> 
> On 24/05/2022 18:51, Matt Roper wrote:
> > On Tue, May 24, 2022 at 10:43:39AM +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > > 
> > > Catch and log any garbage in the register, including no tiles marked, or
> > > multiple tiles marked.
> > > 
> > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > > Cc: Matt Roper <matthew.d.roper@intel.com>
> > > ---
> > > We caught garbage in DG1_MSTR_TILE_INTR with DG2 (actual value 0xF9D2C008)
> > > during glmark and more badness. So I thought lets log all possible failure
> > > modes from here and also use per device logging.
> > > ---
> > >   drivers/gpu/drm/i915/i915_irq.c | 33 ++++++++++++++++++++++-----------
> > >   drivers/gpu/drm/i915/i915_reg.h |  1 +
> > >   2 files changed, 23 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> > > index 73cebc6aa650..79853d3fc1ed 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -2778,24 +2778,30 @@ static irqreturn_t dg1_irq_handler(int irq, void *arg)
> > >   	u32 gu_misc_iir;
> > >   	if (!intel_irqs_enabled(i915))
> > > -		return IRQ_NONE;
> > > +		goto none;
> > >   	master_tile_ctl = dg1_master_intr_disable(regs);
> > > -	if (!master_tile_ctl) {
> > > -		dg1_master_intr_enable(regs);
> > > -		return IRQ_NONE;
> > > +	if (!master_tile_ctl)
> > > +		goto enable_none;
> > > +
> > > +	if (master_tile_ctl & ~(DG1_MSTR_IRQ | DG1_MSTR_TILE_MASK)) {
> > > +		drm_warn(&i915->drm, "Garbage in master_tile_ctl: 0x%08x!\n",
> > > +			 master_tile_ctl);
> > 
> > I know we have a bunch of them already, but shouldn't we be avoiding
> > printk-based stuff like this inside interrupt handlers?  Should we be
> > migrating all these error messages over to trace_printk or something
> > similar that's safer to use?
> 
> Not sure - I kind of think some really unexpected and worrying situations
> should be loud and on by default. Risk is then spam if not ratelimited.
> Maybe we should instead ratelimit most errors/warnings coming for irq
> handlers?

It's not the risk of spam that's the problem, but rather that
printk-based stuff eventually calls into the console code to flush its
buffers.  That's way more overhead than you want in an interrupt handler
so it's bad on its own, but if you're using something slow like a serial
console, it becomes even more of a problem.

While the unexpected bits in the master tile register are strange and
may point to a bigger problem somewhere else, they're also harmless on
their own since we should just ignore those bits and only process the
valid tiles.

> 
> In this particular case at least DRM_ERROR with no device info is the odd
> one out in the entire file so I'd suggest changing at least that, if the
> rest of my changes is of questionable benefit.

Changing DRM_ERROR -> drm_err would probably be fine in the short term
since it doesn't really make us any worse off.  Changing to drm_warn
might not be great since we're generating a lot more lines of output and
probably multiplying the already bad overhead that shouldn't be
happening in an interrupt handler.  But if we could update the interrupt
handler to just save away the details and do the actual drm_warn later,
outside the interrupt handler code, that would be okay.  We should
probably work toward something like that for all of our interrupt
handler warning/error messages.


Matt

> 
> Regards,
> 
> Tvrtko
> 
> > 
> > 
> > Matt
> > 
> > > +		goto enable_none;
> > >   	}
> > >   	/* FIXME: we only support tile 0 for now. */
> > > -	if (master_tile_ctl & DG1_MSTR_TILE(0)) {
> > > -		master_ctl = raw_reg_read(regs, GEN11_GFX_MSTR_IRQ);
> > > -		raw_reg_write(regs, GEN11_GFX_MSTR_IRQ, master_ctl);
> > > -	} else {
> > > -		DRM_ERROR("Tile not supported: 0x%08x\n", master_tile_ctl);
> > > -		dg1_master_intr_enable(regs);
> > > -		return IRQ_NONE;
> > > +	if (REG_FIELD_GET(DG1_MSTR_TILE_MASK, master_tile_ctl) !=
> > > +	    DG1_MSTR_TILE(0)) {
> > > +		drm_warn(&i915->drm, "Unexpected irq from tile %u!\n",
> > > +			 ilog2(REG_FIELD_GET(DG1_MSTR_TILE_MASK,
> > > +					     master_tile_ctl)));
> > > +		goto enable_none;
> > >   	}
> > > +	master_ctl = raw_reg_read(regs, GEN11_GFX_MSTR_IRQ);
> > > +	raw_reg_write(regs, GEN11_GFX_MSTR_IRQ, master_ctl);
> > > +
> > >   	gen11_gt_irq_handler(gt, master_ctl);
> > >   	if (master_ctl & GEN11_DISPLAY_IRQ)
> > > @@ -2810,6 +2816,11 @@ static irqreturn_t dg1_irq_handler(int irq, void *arg)
> > >   	pmu_irq_stats(i915, IRQ_HANDLED);
> > >   	return IRQ_HANDLED;
> > > +
> > > +enable_none:
> > > +	dg1_master_intr_enable(regs);
> > > +none:
> > > +	return IRQ_NONE;
> > >   }
> > >   /* Called from drm generic code, passed 'crtc' which
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> > > index d8579ab9384c..eefa301c6430 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -5774,6 +5774,7 @@
> > >   #define DG1_MSTR_TILE_INTR		_MMIO(0x190008)
> > >   #define   DG1_MSTR_IRQ			REG_BIT(31)
> > > +#define   DG1_MSTR_TILE_MASK		REG_GENMASK(3, 0)
> > >   #define   DG1_MSTR_TILE(t)		REG_BIT(t)
> > >   #define GEN11_DISPLAY_INT_CTL		_MMIO(0x44200)
> > > -- 
> > > 2.32.0
> > > 
> > 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation

  reply	other threads:[~2022-05-25 18:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-24  9:43 [Intel-gfx] [PATCH] drm/i915/dg2: Catch and log more unexpected values in DG1_MSTR_TILE_INTR Tvrtko Ursulin
2022-05-24 10:01 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for " Patchwork
2022-05-24 10:22 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-05-24 11:46 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-05-24 17:51 ` [Intel-gfx] [PATCH] " Matt Roper
2022-05-25 16:03   ` Tvrtko Ursulin
2022-05-25 18:05     ` Matt Roper [this message]
2022-05-26 10:18       ` Tvrtko Ursulin
2022-05-27 18:42         ` Matt Roper
2022-06-06 11:55           ` Tvrtko Ursulin
2022-06-06 15:21             ` Matt Roper
2022-06-07  9:20               ` Tvrtko Ursulin
2022-05-25 18:14     ` Lucas De Marchi
2022-05-26 10:29       ` Tvrtko Ursulin

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=Yo5v7/pLw4eF8xxw@mdroper-desk1.amr.corp.intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=tvrtko.ursulin@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox