All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: sashiko-reviews@lists.linux.dev
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 7/9] drm/i915/de: Move unclaimed mmio detection into display code
Date: Fri, 6 Nov 2026 18:19:09 +0200	[thread overview]
Message-ID: <au39_Rv2aA4oXIUu@intel.com> (raw)
In-Reply-To: <sashiko-outbox-198239@kernel.org>

On Wed, Nov 04, 2026 at 10:36:37PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
> - [High] drm/i915/de: NULL deref on displayless devices in unclaimed MMIO checks
> - [Medium] drm/i915/de: intel_de_init() enables FPGA_DBG check on Ivy Bridge
> - [Medium] drm/i915/de: unclaimed MMIO status is not cleared on initialization
> - [Low] drm/i915/display: unused mmio.mmio_debug field in struct intel_display
> --
> 
> commit 74c572411ef669251a5e2e347d14a7771407e433
> Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> drm/i915/de: Move unclaimed mmio detection into display code
> 
> This commit moves the FPGA_DBG and CLAIM_ER unclaimed MMIO access detection
> from intel_uncore into the display code, protecting the tracking state with
> display->mmio.lock.
> 
> > diff --git a/drivers/gpu/drm/i915/display/intel_de.c b/drivers/gpu/drm/i915/display/intel_de.c
> > index 8b7a4e696ff96..0a51105e0fbad 100644
> > --- a/drivers/gpu/drm/i915/display/intel_de.c
> > +++ b/drivers/gpu/drm/i915/display/intel_de.c
> 
> [ ... ]
<snip>
> > @@ -304,7 +470,11 @@ void intel_de_init(struct intel_display *display)
> >  	spin_lock_init(&display->mmio.lock);
> >  
> >  	if (driver_is_i915()) {
> > -		if (display->platform.valleyview || display->platform.cherryview)
> > +		if (display->platform.valleyview || display->platform.cherryview)
> > +			display->mmio.funcs = &vlv_mmio_funcs;
> > +		else if (DISPLAY_VER(display) >= 7)
> > +			display->mmio.funcs = &ivb_mmio_funcs;
> > +		else if (DISPLAY_VER(display) >= 6)
> >  			display->mmio.funcs = &snb_mmio_funcs;
> >  		else
> >  			display->mmio.funcs = &i9xx_mmio_funcs;
> 
> [Severity: Medium]
> Does checking DISPLAY_VER(display) >= 7 in intel_de_init() unintentionally
> enable FPGA_DBG unclaimed MMIO checks on Ivy Bridge?

Yes, but only because I misremembered that IVB has the feature already.
IVB does have the FPGA_DBG register already (which is the part I
remembered correctly), but the unclaimed register access bit is not
there until HSW. I guess that makes perfect since since HSW is the
one that also introduced us to power wells. So I'll need to
s/ivb/hsw/ here.

> 
> Previously, intel_uncore_init_mmio() gated FPGA_DBG unclaimed MMIO detection
> on HAS_FPGA_DBG_UNCLAIMED(display). In
> drivers/gpu/drm/i915/display/intel_display_device.c, has_fpga_dbg is set on
> hsw_desc and bdw_desc onwards, whereas ivb_display has ip.ver = 7 and
> has_fpga_dbg = 0. Checking DISPLAY_VER(display) >= 7 assigns ivb_mmio_funcs to
> Ivy Bridge as well, and leaves HAS_FPGA_DBG_UNCLAIMED(display) unused.
> 
> Should this check HAS_FPGA_DBG_UNCLAIMED(display) instead?
> 
> > @@ -314,4 +484,7 @@ void intel_de_init(struct intel_display *display)
> >  		else
> >  			display->mmio.funcs = &i9xx_mmio_funcs;
> >  	}
> > +
> > +	if (display->mmio.funcs->check_for_unclaimed_mmio)
> > +		display->mmio.unclaimed_mmio_check = 1;
> >  }
> 
> [Severity: Medium]
> Previously, intel_uncore_init_mmio() cleared any stale unclaimed MMIO bit left
> set by BIOS or pre-boot firmware during initialization:
> 
> 	/* clear out unclaimed reg detection bit */
> 	if (intel_uncore_unclaimed_mmio(uncore))
> 		drm_dbg(&i915->drm, "unclaimed mmio detected on uncore init, clearing\n");
> 
> With that removed and not replaced in intel_de_init(), if mmio_debug is

Hmm. I thought I took care of that, but looks like I only adjusted the
resume path, not the init path.

> disabled by default, won't a stale FPGA_DBG_RM_NOCLAIM or CLAIM_ER bit from
> boot firmware remain latched until intel_de_arm_unclaimed_mmio_detection()
> runs at the end of the first modeset or in
> intel_display_driver_mmio_suspend_late(), triggering a false-positive error or
> falsely arming oneshot mmio_debug reporting?
> 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h b/drivers/gpu/drm/i915/display/intel_display_core.h
> > index aded2af8c92a6..cb18ee040b5d6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> > @@ -539,11 +539,18 @@ struct intel_display {
> >  		 * serializes all display register accesses done
> >  		 * using intel_de_{read,write}(), but not those
> >  		 * done using intel_de_{read,write}_fw().
> > +		 *
> > +		 * The lock also protects mmio.mmio_debug and
> > +		 * mmio.unclaimed_mmio_check.
> >  		 */
> >  		spinlock_t lock;
> >  
> >  		struct intel_uncore *uncore;
> >  		const struct intel_mmio_funcs *funcs;
> > +
> > +		/* protected by mmio.lock */
> > +		int mmio_debug;
> > +		int unclaimed_mmio_check;
> >  	} mmio;
> 
> [Severity: Low]
> This isn't a bug, but display->mmio.mmio_debug is never used since
> check_unclaimed_mmio_pre(), check_unclaimed_mmio_post(), and
> intel_de_arm_unclaimed_mmio_detection() all use display->params.mmio_debug.
> Should mmio.mmio_debug be dropped from struct intel_display?

Aye. Looks like some crap I accidentally left in.

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2026-11-06 16:19 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-04 22:18 [PATCH 0/9] drm/i915/de: Work towards uncore elimination Ville Syrjala
2026-11-04 22:18 ` [PATCH 1/9] drm/i915/de: Introduce dislay->mmio and intel_de_init() Ville Syrjala
2026-11-04 22:31   ` sashiko-bot
2026-11-05  8:58     ` Jani Nikula
2026-11-05 20:03     ` Ville Syrjälä
2026-11-04 23:29   ` Michał Grzelak
2026-11-04 22:18 ` [PATCH 2/9] drm/i915/de: Convert intel_de_{read,write}() into vfuncs Ville Syrjala
2026-11-06 14:50   ` Jani Nikula
2026-11-06 15:35     ` Ville Syrjälä
2026-11-04 22:18 ` [PATCH 3/9] drm/i915/de: Introduce mmio read/write templates Ville Syrjala
2026-11-04 23:32   ` Michał Grzelak
2026-11-06 14:52   ` Jani Nikula
2026-11-06 16:03     ` Ville Syrjälä
2026-11-04 22:18 ` [PATCH 4/9] drm/i915/de: Eliminate runtime overhead from DMC wakelock on pre-LNL platforms Ville Syrjala
2026-11-06 14:53   ` Jani Nikula
2026-11-04 22:18 ` [PATCH 5/9] drm/i915/de: Introduce display->mmio.lock Ville Syrjala
2026-11-04 22:35   ` sashiko-bot
2026-11-05  9:32   ` Jani Nikula
2026-11-05 13:43     ` Ville Syrjälä
2026-11-05 13:47       ` Jani Nikula
2026-11-06 14:55   ` Jani Nikula
2026-11-04 22:18 ` [PATCH 6/9] drm/i915/uncore: Don't meddle with mmio debug upon user forcewake Ville Syrjala
2026-11-06 14:58   ` Jani Nikula
2026-11-04 22:18 ` [PATCH 7/9] drm/i915/de: Move unclaimed mmio detection into display code Ville Syrjala
2026-11-04 22:36   ` sashiko-bot
2026-11-06 16:19     ` Ville Syrjälä [this message]
2026-11-06 16:39   ` Jani Nikula
2026-11-06 17:24     ` Ville Syrjälä
2026-11-04 22:18 ` [PATCH 8/9] drm/i915/de: Stop using intel_uncore_{read,write}() Ville Syrjala
2026-11-06 15:37   ` Jani Nikula
2026-11-06 15:55     ` Ville Syrjälä
2026-11-04 22:18 ` [PATCH 9/9] drm/xe: Nuke the intel_uncore_{read,write}() wrappers Ville Syrjala
2026-11-06 15:38   ` [PATCH 9/9] drm/xe: Nuke the intel_uncore_{read, write}() wrappers Jani Nikula
2026-11-05  0:01 ` ✗ CI.checkpatch: warning for drm/i915/de: Work towards uncore elimination Patchwork
2026-11-05  0:03 ` ✓ CI.KUnit: success " Patchwork
2026-11-05  0:40 ` ✓ Xe.CI.BAT: " Patchwork
2026-11-05  2:14 ` ✓ i915.CI.BAT: " Patchwork
2026-11-05  4:38 ` ✓ i915.CI.Full: " Patchwork
2026-11-05  7:10 ` ✗ CI.checkpatch: warning for drm/i915/de: Work towards uncore elimination (rev2) Patchwork
2026-11-05  7:13 ` ✓ CI.KUnit: success " Patchwork
2026-11-05  7:47 ` ✓ Xe.CI.BAT: " Patchwork
2026-11-06  1:17 ` ✓ Xe.CI.FULL: " 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=au39_Rv2aA4oXIUu@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.