From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm/i915: Protect dev_priv->atomic_cdclk_freq with all the crtc locks
Date: Tue, 15 Nov 2016 15:41:27 +0200 [thread overview]
Message-ID: <20161115134127.GJ31595@intel.com> (raw)
In-Reply-To: <b37ca3f2-6d06-f3de-3d9a-017fc7fc0dd4@linux.intel.com>
On Tue, Nov 15, 2016 at 11:14:29AM +0100, Maarten Lankhorst wrote:
> Op 14-11-16 om 17:35 schreef ville.syrjala@linux.intel.com:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > A modeset on one pipe can update dev_priv->atomic_cdclk_freq without
> > actually touching the hardware, in which case we won't force a modeset
> > on all the pipes, and thus won't lock any of the other pipes either.
> > That means a parallel plane update on another pipe could be looking at
> > a stale dev_priv->atomic_cdcdlk_freq and thus fail to notice when the
> > plane configuration is invalid, or potentially reject a valid update.
> >
> > To overcome this we must protect writes to atomic_cdclk_freq with
> > all the crtc locks, and thus for reads any single crtc lock will
> > be sufficient protection.
> >
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 9 +++++++-
> > drivers/gpu/drm/i915/intel_display.c | 41 +++++++++++++++++++++++++++++++-----
> > 2 files changed, 44 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > index c0f1dfc7119e..66d2950dc657 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1874,7 +1874,14 @@ struct drm_i915_private {
> >
> > unsigned int fsb_freq, mem_freq, is_ddr3;
> > unsigned int skl_preferred_vco_freq;
> > - unsigned int cdclk_freq, max_cdclk_freq, atomic_cdclk_freq;
> > + unsigned int cdclk_freq, max_cdclk_freq;
> > +
> > + /*
> > + * For reading holding any crtc lock is sufficient,
> > + * for writing must hold all of them.
> > + */
> > + unsigned int atomic_cdclk_freq;
> > +
> > unsigned int max_dotclk_freq;
> > unsigned int rawclk_freq;
> > unsigned int hpll_freq;
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 70f3f0b70263..d7a4bc63b05b 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -13946,13 +13946,32 @@ static int haswell_mode_set_planes_workaround(struct drm_atomic_state *state)
> > return 0;
> > }
> >
> > +static int intel_lock_all_pipes(struct drm_atomic_state *state)
> > +{
> > + struct drm_crtc *crtc;
> > +
> > + /* Add all pipes to the state */
> > + for_each_crtc(state->dev, crtc) {
> > + struct drm_crtc_state *crtc_state;
> > +
> > + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> > + if (IS_ERR(crtc_state))
> > + return PTR_ERR(crtc_state);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static int intel_modeset_all_pipes(struct drm_atomic_state *state)
> > {
> > struct drm_crtc *crtc;
> > struct drm_crtc_state *crtc_state;
> > int ret = 0;
> >
> > - /* add all active pipes to the state */
> > + /*
> > + * Add all pipes to the state, and force
> > + * a modeset on all the active ones.
> > + */
> > for_each_crtc(state->dev, crtc) {
> > crtc_state = drm_atomic_get_crtc_state(state, crtc);
> > if (IS_ERR(crtc_state))
> > @@ -14018,12 +14037,24 @@ static int intel_modeset_checks(struct drm_atomic_state *state)
> > if (ret < 0)
> > return ret;
> >
> > + /*
> > + * Writes to dev_priv->atomic_cdclk_freq must protected by
> > + * holding all the crtc locks, even if we don't end up
> > + * touching the hardware
> > + */
> > + if (intel_state->cdclk != dev_priv->atomic_cdclk_freq) {
> > + ret = intel_lock_all_pipes(state);
> > + if (ret < 0)
> > + return ret;
> > + }
> > +
> Would it be terrible to just use intel_modeset_all_pipes here? Since this can only be different in the all crtc's disabled case
> it won't matter much.
Is there any benefit in doing that? A bit confusing IMO to force a
modeset when you don't have to.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-11-15 13:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-14 16:35 [PATCH 0/3] drm/i915: atomic_cdclk_freq fixes ville.syrjala
2016-11-14 16:35 ` [PATCH v2 1/3] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things ville.syrjala
2016-11-14 16:35 ` ville.syrjala
2016-11-15 10:15 ` Maarten Lankhorst
2016-11-17 8:17 ` Paul Bolle
2016-11-17 14:55 ` Joseph Yasi
2016-11-14 16:35 ` [PATCH 2/3] drm/i915: Protect dev_priv->atomic_cdclk_freq with all the crtc locks ville.syrjala
2016-11-15 9:08 ` Daniel Vetter
2016-11-15 9:18 ` Daniel Vetter
2016-11-15 9:52 ` Ville Syrjälä
2016-11-15 10:14 ` Maarten Lankhorst
2016-11-15 13:41 ` Ville Syrjälä [this message]
2016-11-15 13:53 ` Maarten Lankhorst
2016-11-17 15:06 ` Ville Syrjälä
2016-11-18 10:26 ` Maarten Lankhorst
2016-11-18 12:27 ` Ville Syrjälä
2016-11-14 16:35 ` [PATCH 3/3] drm/i915: Simplify error handling in intel_modeset_all_pipes() ville.syrjala
2016-11-15 9:19 ` Daniel Vetter
2016-11-14 17:16 ` ✓ Fi.CI.BAT: success for drm/i915: atomic_cdclk_freq fixes Patchwork
2016-11-23 20:27 ` [PATCH 0/3] " Ville Syrjälä
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=20161115134127.GJ31595@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=maarten.lankhorst@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 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.