From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock.
Date: Fri, 10 Mar 2023 18:26:54 +0200 [thread overview]
Message-ID: <ZAtaTkXQ2UsLX21w@intel.com> (raw)
In-Reply-To: <ZApXyJsA6WUxrood@intel.com>
On Thu, Mar 09, 2023 at 05:03:52PM -0500, Rodrigo Vivi wrote:
> On Thu, Mar 09, 2023 at 12:03:19AM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 08, 2023 at 11:58:58AM -0500, Rodrigo Vivi wrote:
> > > uncore->lock only protects the forcewake domain itself,
> > > not the register accesses.
> > >
> > > uncore's _fw alternatives are for cases where the domains
> > > are not needed because we are sure that they are already
> > > awake.
> > >
> > > So the move towards the uncore's _fw alternatives seems
> > > right, however using the uncore-lock to protect the dsparb
> > > registers seems an abuse of the uncore-lock.
> > >
> > > Let's restore the previous individual lock and try to get
> > > rid of the direct uncore accesses from the display code.
> > >
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Cc: Jani Nikula <jani.nikula@intel.com>
> > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/i9xx_wm.c | 13 ++-----------
> > > drivers/gpu/drm/i915/display/intel_display_core.h | 3 +++
> > > drivers/gpu/drm/i915/i915_driver.c | 1 +
> > > 3 files changed, 6 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c b/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > index caef72d38798..8fe0b5c63d3a 100644
> > > --- a/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > +++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
> > > @@ -1771,16 +1771,7 @@ static void vlv_atomic_update_fifo(struct intel_atomic_state *state,
> > >
> > > trace_vlv_fifo_size(crtc, sprite0_start, sprite1_start, fifo_size);
> > >
> > > - /*
> > > - * uncore.lock serves a double purpose here. It allows us to
> > > - * use the less expensive I915_{READ,WRITE}_FW() functions, and
> > > - * it protects the DSPARB registers from getting clobbered by
> > > - * parallel updates from multiple pipes.
> > > - *
> > > - * intel_pipe_update_start() has already disabled interrupts
> > > - * for us, so a plain spin_lock() is sufficient here.
> > > - */
> >
> > I was wondering if we need to preserve the comment about irqs,
> > but since this is the only place using this lock, and it's never
> > called from an irq handler a non-irq disabling spinlock will suffice
> > anyway.
> >
> > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> thoughts on this: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114868v2/fi-kbl-7567u/igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-b-dp-1.html
This code doesn't run on that platform, so unrelated.
>
> maybe related to the usage of this uncore.lock in
>
> drivers/gpu/drm/i915/display/intel_vblank.c
>
> ?
>
> Should we create another spin lock and include both of these cases?
> (Then the irq comment is relevant again :))
We're already 4 spinlocks deep when in vblank code. Let's not add more ;)
>
> >
> > > - spin_lock(&uncore->lock);
> > > + spin_lock(&dev_priv->display.wm.dsparb_lock);
> > >
> > > switch (crtc->pipe) {
> > > case PIPE_A:
> > > @@ -1840,7 +1831,7 @@ static void vlv_atomic_update_fifo(struct intel_atomic_state *state,
> > >
> > > intel_uncore_posting_read_fw(uncore, DSPARB);
> > >
> > > - spin_unlock(&uncore->lock);
> > > + spin_unlock(&dev_priv->display.wm.dsparb_lock);
> > > }
> > >
> > > #undef VLV_FIFO
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h b/drivers/gpu/drm/i915/display/intel_display_core.h
> > > index fdab7bb93a7d..68c6bfb91dbe 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> > > @@ -253,6 +253,9 @@ struct intel_wm {
> > > */
> > > struct mutex wm_mutex;
> > >
> > > + /* protects DSPARB registers on pre-g4x/vlv/chv */
> > > + spinlock_t dsparb_lock;
> > > +
> > > bool ipc_enabled;
> > > };
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c
> > > index a53fd339e2cc..c78e36444a12 100644
> > > --- a/drivers/gpu/drm/i915/i915_driver.c
> > > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > > @@ -223,6 +223,7 @@ static int i915_driver_early_probe(struct drm_i915_private *dev_priv)
> > > mutex_init(&dev_priv->display.pps.mutex);
> > > mutex_init(&dev_priv->display.hdcp.comp_mutex);
> > > spin_lock_init(&dev_priv->display.dkl.phy_lock);
> > > + spin_lock_init(&dev_priv->display.wm.dsparb_lock);
> > >
> > > i915_memcpy_init_early(dev_priv);
> > > intel_runtime_pm_init_early(&dev_priv->runtime_pm);
> > > --
> > > 2.39.2
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2023-03-10 16:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-08 16:58 [Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock Rodrigo Vivi
2023-03-08 16:58 ` [Intel-gfx] [PATCH 2/2] drm/i915/i9xx_wm: Prefer intel_de functions over intel_uncore Rodrigo Vivi
2023-03-08 17:50 ` Ville Syrjälä
2023-03-08 17:56 ` Rodrigo Vivi
2023-03-08 18:18 ` Ville Syrjälä
2023-03-08 21:53 ` Ville Syrjälä
2023-03-08 22:03 ` [Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock Ville Syrjälä
2023-03-09 22:03 ` Rodrigo Vivi
2023-03-10 16:26 ` Ville Syrjälä [this message]
2023-03-10 19:09 ` Rodrigo Vivi
2023-03-09 21:55 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/display: Restore dsparb_lock. (rev2) Patchwork
2023-03-10 20:08 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/display: Restore dsparb_lock. (rev3) Patchwork
2023-03-24 19:16 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/display: Restore dsparb_lock. (rev4) Patchwork
2023-03-24 19:16 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-03-24 19:17 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-03-25 1:42 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2023-03-27 16:12 [Intel-gfx] [PATCH 1/2] drm/i915/display: Restore dsparb_lock Rodrigo Vivi
2023-03-28 16:22 ` Jani Nikula
2023-03-29 19:32 ` Rodrigo Vivi
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=ZAtaTkXQ2UsLX21w@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=rodrigo.vivi@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;
as well as URLs for NNTP newsgroup(s).