All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/uncore: keep track of last mmio accesses
Date: Mon, 4 Apr 2022 13:38:58 -0700	[thread overview]
Message-ID: <YktXYifH6HkafDvW@mdroper-desk1.amr.corp.intel.com> (raw)
In-Reply-To: <20220404181844.2649726-1-lucas.demarchi@intel.com>

On Mon, Apr 04, 2022 at 11:18:44AM -0700, Lucas De Marchi wrote:
> Sine gen6 we use FPGA_DBG register to detect unclaimed MMIO registers.
> This register is in the display engine IP and can only ever detect
> unclaimed accesses to registers in this area. However sometimes there
> are reports of this triggering for registers in other areas, which
> should not be possible.
> 
> This keeps track of the last 4 registers which should hopefully be
> sufficient to understand where these are coming from. And without
> increasing the debug struct too much:

Doesn't the unclaimed access checking happen within uncore->lock,
guaranteeing that an unclaimed access triggered by an uncore read/write
is always from the current one and not a previous one?  Presumably if
the wrong access is being identified, then the true culprit is probably
a __raw_uncore_{read,write} that doesn't have any checking of its own
and doesn't use the uncore lock?  I think we could probably confirm this
theory by updating __unclaimed_reg_debug() to drop the "!before"
condition and print a slightly different message if we detect an
unclaimed access has already happened before we do the new operation.


Matt

> 
> Before:
> 	struct intel_uncore_mmio_debug {
> 		spinlock_t                 lock;                 /*     0    64 */
> 		/* --- cacheline 1 boundary (64 bytes) --- */
> 		int                        unclaimed_mmio_check; /*    64     4 */
> 		int                        saved_mmio_check;     /*    68     4 */
> 		u32                        suspend_count;        /*    72     4 */
> 
> 		/* size: 80, cachelines: 2, members: 4 */
> 		/* padding: 4 */
> 		/* last cacheline: 16 bytes */
> 	};
> 
> After:
> 	struct intel_uncore_mmio_debug {
> 		spinlock_t                 lock;                 /*     0    64 */
> 		/* --- cacheline 1 boundary (64 bytes) --- */
> 		int                        unclaimed_mmio_check; /*    64     4 */
> 		int                        saved_mmio_check;     /*    68     4 */
> 		u32                        last_reg[4];          /*    72    16 */
> 		u32                        last_reg_pos;         /*    88     4 */
> 		u32                        suspend_count;        /*    92     4 */
> 
> 		/* size: 96, cachelines: 2, members: 6 */
> 		/* last cacheline: 32 bytes */
> 	};
> 
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 18 +++++++++++++++++-
>  drivers/gpu/drm/i915/intel_uncore.h |  4 ++++
>  2 files changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> index 8b9caaaacc21..31a23b0e2907 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1509,9 +1509,25 @@ __unclaimed_reg_debug(struct intel_uncore *uncore,
>  		     check_for_unclaimed_mmio(uncore) && !before,
>  		     "Unclaimed %s register 0x%x\n",
>  		     read ? "read from" : "write to",
> -		     i915_mmio_reg_offset(reg)))
> +		     i915_mmio_reg_offset(reg))) {
> +		unsigned int i;
> +
>  		/* Only report the first N failures */
>  		uncore->i915->params.mmio_debug--;
> +
> +		drm_dbg(&uncore->i915->drm, "Last register accesses:\n");
> +		for (i = uncore->debug->last_reg_pos;
> +		     i < uncore->debug->last_reg_pos + INTEL_UNCORE_MMIO_DEBUG_REG_COUNT;
> +		     i++)
> +			drm_dbg(&uncore->i915->drm, "0x%x\n",
> +				uncore->debug->last_reg[i % INTEL_UNCORE_MMIO_DEBUG_REG_COUNT]);
> +	}
> +
> +	if (!before) {
> +		uncore->debug->last_reg[uncore->debug->last_reg_pos++] =
> +			i915_mmio_reg_offset(reg);
> +		uncore->debug->last_reg_pos %= INTEL_UNCORE_MMIO_DEBUG_REG_COUNT;
> +	}
>  }
>  
>  static inline void
> diff --git a/drivers/gpu/drm/i915/intel_uncore.h b/drivers/gpu/drm/i915/intel_uncore.h
> index 52fe3d89dd2b..5b5d2858ae11 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.h
> +++ b/drivers/gpu/drm/i915/intel_uncore.h
> @@ -38,10 +38,14 @@ struct intel_runtime_pm;
>  struct intel_uncore;
>  struct intel_gt;
>  
> +#define INTEL_UNCORE_MMIO_DEBUG_REG_COUNT	4
> +
>  struct intel_uncore_mmio_debug {
>  	spinlock_t lock; /** lock is also taken in irq contexts. */
>  	int unclaimed_mmio_check;
>  	int saved_mmio_check;
> +	u32 last_reg[INTEL_UNCORE_MMIO_DEBUG_REG_COUNT];
> +	u32 last_reg_pos;
>  	u32 suspend_count;
>  };
>  
> -- 
> 2.35.1
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795

  parent reply	other threads:[~2022-04-04 20:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-04 18:18 [Intel-gfx] [PATCH] drm/i915/uncore: keep track of last mmio accesses Lucas De Marchi
2022-04-04 20:17 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/uncore: keep track of last mmio accesses (rev2) Patchwork
2022-04-04 20:38 ` Matt Roper [this message]
2022-04-04 23:53   ` [Intel-gfx] [PATCH] drm/i915/uncore: keep track of last mmio accesses Lucas De Marchi
2022-04-04 20:48 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uncore: keep track of last mmio accesses (rev2) Patchwork
2022-04-05  0:23 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/uncore: keep track of last mmio accesses (rev3) Patchwork
2022-04-05  0:54 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-04-05  2:25 ` [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/uncore: keep track of last mmio accesses (rev2) Patchwork
2022-04-05  8:29 ` [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/uncore: keep track of last mmio accesses (rev3) 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=YktXYifH6HkafDvW@mdroper-desk1.amr.corp.intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lucas.demarchi@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.