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 07/14] drm/i915: Compute vlv/chv wms the atomic way
Date: Thu, 15 Dec 2016 18:09:26 +0200 [thread overview]
Message-ID: <20161215160926.GL31595@intel.com> (raw)
In-Reply-To: <c4366866-6806-be43-b61a-8e0b3ed8cba5@linux.intel.com>
On Thu, Dec 15, 2016 at 04:45:49PM +0100, Maarten Lankhorst wrote:
> Op 15-12-16 om 16:38 schreef Ville Syrjälä:
> > On Thu, Dec 15, 2016 at 04:30:54PM +0100, Maarten Lankhorst wrote:
> >> Op 12-12-16 om 21:35 schreef ville.syrjala@linux.intel.com:
> >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>
> >>> Start computing the vlv/chv watermarks the atomic way, from the
> >>> .compute_pipe_wm() hook. We'll recompute the actual watermarks
> >>> for only planes that are part of the state, the other planes will
> >>> keep their watermark from the last time it was computed.
> >>>
> >>> And the actual watermark programming will happen from the
> >>> .initial_watermarks() hook. For now we'll just compute the
> >>> optimal watermarks, and we'll hook up the intermediate
> >>> watermarks properly later.
> >>>
> >>> The DSPARB registers responsible for the FIFO paritioning are
> >>> double buffered, so they will be programming from
> >>> intel_begin_crtc_commit().
> >>>
> >>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>> ---
> >>> drivers/gpu/drm/i915/i915_drv.h | 8 +
> >>> drivers/gpu/drm/i915/intel_display.c | 21 ++-
> >>> drivers/gpu/drm/i915/intel_drv.h | 2 -
> >>> drivers/gpu/drm/i915/intel_pm.c | 327 +++++++++++++++++++++++------------
> >>> 4 files changed, 238 insertions(+), 120 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> >>> index 20bc04d5e617..f23698f99685 100644
> >>> --- a/drivers/gpu/drm/i915/i915_drv.h
> >>> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >>> @@ -493,6 +493,14 @@ struct i915_hotplug {
> >>> for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \
> >>> for_each_if ((1 << (domain)) & (mask))
> >>>
> >>> +#define for_each_intel_plane_in_state(__state, plane, plane_state, __i) \
> >>> + for ((__i) = 0; \
> >>> + (__i) < (__state)->base.dev->mode_config.num_total_plane && \
> >>> + ((plane) = to_intel_plane((__state)->base.planes[__i].ptr), \
> >>> + (plane_state) = to_intel_plane_state((__state)->base.planes[__i].state), 1); \
> >>> + (__i)++) \
> >>> + for_each_if (plane_state)
> >>> +
> >>> struct drm_i915_private;
> >>> struct i915_mm_struct;
> >>> struct i915_mmu_object;
> >>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> >>> index 3f027341b0f3..8d80873b6643 100644
> >>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>> @@ -6736,6 +6736,8 @@ static void valleyview_modeset_commit_cdclk(struct drm_atomic_state *old_state)
> >>> static void valleyview_crtc_enable(struct intel_crtc_state *pipe_config,
> >>> struct drm_atomic_state *old_state)
> >>> {
> >>> + struct intel_atomic_state *old_intel_state =
> >>> + to_intel_atomic_state(old_state);
> >>> struct drm_crtc *crtc = pipe_config->base.crtc;
> >>> struct drm_device *dev = crtc->dev;
> >>> struct drm_i915_private *dev_priv = to_i915(dev);
> >>> @@ -6780,7 +6782,8 @@ static void valleyview_crtc_enable(struct intel_crtc_state *pipe_config,
> >>>
> >>> intel_color_load_luts(&pipe_config->base);
> >>>
> >>> - intel_update_watermarks(intel_crtc);
> >>> + dev_priv->display.initial_watermarks(old_intel_state,
> >>> + pipe_config);
> >>> intel_enable_pipe(intel_crtc);
> >>>
> >>> assert_vblank_disabled(crtc);
> >>> @@ -6897,6 +6900,9 @@ static void i9xx_crtc_disable(struct intel_crtc_state *old_crtc_state,
> >>>
> >>> if (!IS_GEN2(dev_priv))
> >>> intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
> >>> +
> >>> + if (!dev_priv->display.initial_watermarks)
> >>> + intel_update_watermarks(intel_crtc);
> >>> }
> >>>
> >>> static void intel_crtc_disable_noatomic(struct drm_crtc *crtc)
> >>> @@ -12980,10 +12986,13 @@ static bool check_digital_port_conflicts(struct drm_atomic_state *state)
> >>> static void
> >>> clear_intel_crtc_state(struct intel_crtc_state *crtc_state)
> >>> {
> >>> + struct drm_i915_private *dev_priv =
> >>> + to_i915(crtc_state->base.crtc->dev);
> >>> struct drm_crtc_state tmp_state;
> >>> struct intel_crtc_scaler_state scaler_state;
> >>> struct intel_dpll_hw_state dpll_hw_state;
> >>> struct intel_shared_dpll *shared_dpll;
> >>> + struct intel_crtc_wm_state wm_state;
> >>> bool force_thru;
> >>>
> >>> /* FIXME: before the switch to atomic started, a new pipe_config was
> >>> @@ -12996,6 +13005,8 @@ clear_intel_crtc_state(struct intel_crtc_state *crtc_state)
> >>> shared_dpll = crtc_state->shared_dpll;
> >>> dpll_hw_state = crtc_state->dpll_hw_state;
> >>> force_thru = crtc_state->pch_pfit.force_thru;
> >>> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> >>> + wm_state = crtc_state->wm;
> >>>
> >>> memset(crtc_state, 0, sizeof *crtc_state);
> >>>
> >>> @@ -13004,6 +13015,8 @@ clear_intel_crtc_state(struct intel_crtc_state *crtc_state)
> >>> crtc_state->shared_dpll = shared_dpll;
> >>> crtc_state->dpll_hw_state = dpll_hw_state;
> >>> crtc_state->pch_pfit.force_thru = force_thru;
> >>> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> >>> + crtc_state->wm = wm_state;
> >> Is this required? In skl we throw away everything and rebuild using drm_atomic_crtc_state_for_each_plane_state.
> > I don't want to add all the planes into the state when not necessary.
> It doesn't. It uses the fact that updating planes requires crtc mutex, and only iterates over all planes in crtc_state->planes_mask.
Which is setting a somewhat dangerous precedent. So no, I don't think I
want to do that. It's not immediately obvious from the code that it's
100% safe either since the crtc lock is taken after the plane->state
is dereferenced. Which means someon can in parallel be looking at the
old plane state while the new state already exists. I can't think of
a way it could actually go wrong, but seems easier to stick to the
rules and avoid that particular headache entirely.
> Any planes outside it are disabled so wm values can be considered 0, and roughly does the following:
>
> for_each_plane_in_mask(crtc_state->planes_mask)
> if ((!plane_state = drm_atomic_get_existing_state(state, plane_state)) plane_state = plane->state;
>
> plane_state must be const, but that's no problem for wm calculations.
And recomputing stuff that didn't even change just seems wasteful.
--
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-12-15 16:09 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-12 20:35 [PATCH 00/14] drm/i915: VLV/CHV two-stage watermarks ville.syrjala
2016-12-12 20:35 ` [PATCH 01/14] drm/i915: Track visible planes in a bitmask ville.syrjala
2016-12-15 14:56 ` Maarten Lankhorst
2016-12-15 15:02 ` Ville Syrjälä
2016-12-15 17:11 ` Maarten Lankhorst
2016-12-15 17:20 ` Ville Syrjälä
2016-12-12 20:35 ` [PATCH 02/14] drm/i915: Track plane fifo sizes under intel_crtc ville.syrjala
2016-12-15 14:58 ` Maarten Lankhorst
2017-02-16 17:48 ` Ville Syrjälä
2016-12-12 20:35 ` [PATCH 03/14] drm/i915: Move vlv wms from crtc->wm_state to crtc->wm.active.vlv ville.syrjala
2016-12-12 20:35 ` [PATCH 04/14] drm/i915: Plop vlv wm state into crtc_state ville.syrjala
2016-12-12 20:35 ` [PATCH 05/14] drm/i915: Plop vlv/chv fifo sizes into crtc state ville.syrjala
2016-12-12 20:35 ` [PATCH 06/14] drm/i915: Compute VLV/CHV FIFO sizes based on the PM2 watermarks ville.syrjala
2016-12-12 20:35 ` [PATCH 07/14] drm/i915: Compute vlv/chv wms the atomic way ville.syrjala
2016-12-15 15:30 ` Maarten Lankhorst
2016-12-15 15:38 ` Ville Syrjälä
2016-12-15 15:45 ` Maarten Lankhorst
2016-12-15 16:09 ` Ville Syrjälä [this message]
2016-12-15 17:12 ` Maarten Lankhorst
2016-12-15 17:17 ` Ville Syrjälä
2016-12-29 15:42 ` Maarten Lankhorst
2016-12-12 20:35 ` [PATCH 08/14] drm/i915: Skip useless watermark/FIFO related work on VLV/CHV when not needed ville.syrjala
2016-12-15 15:37 ` Maarten Lankhorst
2017-02-16 17:54 ` Ville Syrjälä
2016-12-12 20:35 ` [PATCH 09/14] drm/i915: Compute proper intermediate wms for vlv/cvh ville.syrjala
2016-12-12 20:35 ` [PATCH 10/14] drm/i915: Nuke crtc->wm.cxsr_allowed ville.syrjala
2016-12-12 20:35 ` [PATCH 11/14] drm/i915: Only use update_wm_{pre, post} for pre-ilk platforms ville.syrjala
2016-12-12 20:35 ` [PATCH 12/14] drm/i915: Sanitize VLV/CHV watermarks properly ville.syrjala
2016-12-12 20:35 ` [PATCH 13/14] drm/i915: Workaround VLV/CHV sprite1->sprite0 enable underrun ville.syrjala
2016-12-15 15:34 ` Maarten Lankhorst
2016-12-15 15:47 ` Ville Syrjälä
2016-12-15 16:13 ` Maarten Lankhorst
2016-12-15 16:18 ` Ville Syrjälä
2016-12-12 20:35 ` [PATCH 14/14] drm/i915: Kill level 0 wm hack for VLV/CHV ville.syrjala
2016-12-15 17:10 ` Maarten Lankhorst
2016-12-12 20:35 ` [PATCH i-g-t] tests: Add kms_plane_blinker ville.syrjala
2016-12-15 15:17 ` Maarten Lankhorst
2016-12-15 15:23 ` Ville Syrjälä
2016-12-15 15:28 ` Maarten Lankhorst
2016-12-15 15:36 ` Ville Syrjälä
2016-12-15 15:41 ` Maarten Lankhorst
2016-12-15 16:42 ` Ville Syrjälä
2016-12-15 17:26 ` Ville Syrjälä
2016-12-19 7:07 ` Maarten Lankhorst
2016-12-12 21:15 ` ✗ Fi.CI.BAT: warning for drm/i915: VLV/CHV two-stage watermarks Patchwork
2016-12-13 7:42 ` Saarinen, Jani
2016-12-13 8:40 ` Chris Wilson
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=20161215160926.GL31595@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox