From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 8/9] drm/i915/de: Stop using intel_uncore_{read,write}()
Date: Fri, 6 Nov 2026 17:55:29 +0200 [thread overview]
Message-ID: <au34cXbMcXz307mG@intel.com> (raw)
In-Reply-To: <24b36f993e343935ae34e0671d8cb8935caebb95@intel.com>
On Fri, Nov 06, 2026 at 05:37:59PM +0200, Jani Nikula wrote:
> On Thu, 05 Nov 2026, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Stop using the heavier intel_uncore_{read,write}() and
> > just use intel_uncore_{read,write}_fw() for all display
> > register accesses.
> >
> > The main functional change here is that we now stop
> > grabbing uncore.lock for display registers. Its job
> > is now fully taken over by the display mmio.lock.
> >
> > The one little thing we want to keep from the uncore
> > implementation is the runtime pm asserts (sadly xe
> > doesn't implement them, but i915 does). We have the
> > parent interface for it, so just use it. That is one
> > extra vfunc call, but not sure there's any way around
> > it.
> >
> > One somewhat unexpected side effect (or bonus) is that
> > on ILK we also lose ilk_dummy_write(), which is currently
> > done ahead of all (non-fw) mmio accesses. The only
> > purpose of the dummy write is to wake the GT from
> > RC6 ahead of the actual mmio access. Display has
> > nothing to do with RC6, and I don't think we actually
> > ever enabled RC6 on ILK, so the whole thing is pointless.
> >
> > As a result of eliminating ilk_dummy_write() display
> > register accesses become faster on ILK (numbers in
> > nanoseconds):
> > | fw | non-fw |
> > read | 140 | 430 -> 140 |
> > write | 170 | 470 -> 170 |
> >
> > Register accesses on TGL also get a bit faster,
> > compared against the original code before the
> > display mmio vfuncs were introduced:
> > | fw | non-fw | theoretical non-fw(*)
> > read | 230 | 970 -> 840 | 2*230+230 = 690
> > write | 100 | 820 -> 740 | 2*230+100 = 560
> >
> > (*) two FPGA_DBG reads + the actual register access
> >
> > I presume the improvement was due to some combination of
> > eliminating the extra debug lock and just reducing the
> > runtime overhead in general. The remaining delta between
> > theory and practice seems to be mostly due to mmio.lock.
> > We'll probably want to think of ways to eliminate the lock
> > entirely, on the platforms that don't need it for register
> > access serialization...
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> I guess would like to see mmio tracing pulled into display side too.
That'll happen eventually. The current problem is that
(unline i915 core stuff) xe traces even the _fw()
accesses, so if we switch to a display specific
tracepoint right now we'll get double traces on xe
if the xe tracpoint is also enabled. But perhaps
that's fine as a temporary state of affairs?
>
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>
> > ---
> > drivers/gpu/drm/i915/display/intel_de.c | 9 +++++++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_de.c b/drivers/gpu/drm/i915/display/intel_de.c
> > index 0a51105e0fba..397145bc7e5b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_de.c
> > +++ b/drivers/gpu/drm/i915/display/intel_de.c
> > @@ -9,6 +9,7 @@
> >
> > #include "intel_de.h"
> > #include "intel_display_regs.h"
> > +#include "intel_display_rpm.h"
> >
> > static int intel_de_wait_for_register(struct intel_display *display,
> > intel_reg_t reg, u32 mask, u32 value,
> > @@ -341,11 +342,13 @@ __intel_de_read(struct intel_display *display, intel_reg_t reg,
> > unsigned long irqflags;
> > u32 val;
> >
> > + assert_display_rpm_held(display);
> > +
> > __mmio_wakelock_pre(display, reg, mmio_flags);
> > __mmio_lock_pre(display, &irqflags, mmio_flags);
> > __mmio_unclaimed_pre(display, reg, false, mmio_flags);
> >
> > - val = intel_uncore_read(__to_uncore(display), reg);
> > + val = intel_de_read_fw(display, reg);
> >
> > __mmio_unclaimed_post(display, reg, false, mmio_flags);
> > __mmio_lock_post(display, irqflags, mmio_flags);
> > @@ -360,11 +363,13 @@ __intel_de_write(struct intel_display *display, intel_reg_t reg, u32 val,
> > {
> > unsigned long irqflags;
> >
> > + assert_display_rpm_held(display);
> > +
> > __mmio_wakelock_pre(display, reg, mmio_flags);
> > __mmio_lock_pre(display, &irqflags, mmio_flags);
> > __mmio_unclaimed_pre(display, reg, true, mmio_flags);
> >
> > - intel_uncore_write(__to_uncore(display), reg, val);
> > + intel_de_write_fw(display, reg, val);
> >
> > __mmio_unclaimed_post(display, reg, true, mmio_flags);
> > __mmio_lock_post(display, irqflags, mmio_flags);
>
> --
> Jani Nikula, Intel
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2026-11-06 15:55 UTC|newest]
Thread overview: 40+ 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ä
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ä [this message]
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 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=au34cXbMcXz307mG@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@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