intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Matt Roper <matthew.d.roper@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 7/7] drm/i915: Add two-stage ILK-style watermark programming (v9)
Date: Wed, 6 Jan 2016 11:38:32 +0100	[thread overview]
Message-ID: <568CEEA8.2000809@linux.intel.com> (raw)
In-Reply-To: <1450137093-27438-1-git-send-email-matthew.d.roper@intel.com>

Hey,

Op 15-12-15 om 00:51 schreef Matt Roper:
> In addition to calculating final watermarks, let's also pre-calculate a
> set of intermediate watermark values at atomic check time.  These
> intermediate watermarks are a combination of the watermarks for the old
> state and the new state; they should satisfy the requirements of both
> states which means they can be programmed immediately when we commit the
> atomic state (without waiting for a vblank).  Once the vblank does
> happen, we can then re-program watermarks to the more optimal final
> value.
<snip>
> -static void ilk_update_wm(struct drm_crtc *crtc)
> +static void ilk_initial_watermarks(struct intel_crtc_state *cstate)
>  {
> -	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> -	struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
> -
> -	WARN_ON(cstate->base.active != intel_crtc->active);
> +	struct drm_i915_private *dev_priv = to_i915(cstate->base.crtc->dev);
> +	struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
>  
> -	/*
> -	 * IVB workaround: must disable low power watermarks for at least
> -	 * one frame before enabling scaling.  LP watermarks can be re-enabled
> -	 * when scaling is disabled.
> -	 *
> -	 * WaCxSRDisabledForSpriteScaling:ivb
> -	 */
> -	if (cstate->disable_lp_wm) {
> -		ilk_disable_lp_wm(crtc->dev);
> -		intel_wait_for_vblank(crtc->dev, intel_crtc->pipe);
> -	}
> +	mutex_lock(&intel_crtc->wm.wm_mutex);
> +	intel_crtc->wm.active.ilk = cstate->wm.intermediate;
> +	ilk_program_watermarks(dev_priv);
> +	mutex_unlock(&intel_crtc->wm.wm_mutex);
> +}
Do the locks even protect anything correctly? It seems to me like this mutex may
need to be in dev_priv.

ilk_program_watermarks seems to be depending on all crtc's wm state.

Not a criticism on this patch, but is there an way to hammer in per crtc only wm's without having to look at the exact details of the global wm state outside of modesets?
>  
> -	intel_crtc->wm.active.ilk = cstate->wm.optimal.ilk;
> +static void ilk_optimize_watermarks(struct intel_crtc_state *cstate)
> +{
> +	struct drm_i915_private *dev_priv = to_i915(cstate->base.crtc->dev);
> +	struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
>  
> -	ilk_program_watermarks(cstate);
> +	mutex_lock(&intel_crtc->wm.wm_mutex);
> +	if (cstate->wm.need_postvbl_update) {
> +		intel_crtc->wm.active.ilk = cstate->wm.optimal.ilk;
> +		ilk_program_watermarks(dev_priv);
> +		cstate->wm.need_postvbl_update = false;
You don't need to reset the flag here, it's already cleared when duplicating the state..

~Maarten
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-01-06 10:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-03 19:37 [PATCH 0/7] Wrap up ILK-style atomic watermarks (v2) Matt Roper
2015-12-03 19:37 ` [PATCH 1/7] drm/i915: Disable primary plane if we fail to reconstruct BIOS fb (v2) Matt Roper
2015-12-15 17:20   ` Matt Roper
2015-12-03 19:37 ` [PATCH 2/7] drm/i915: Extract plane dumping from intel_dump_pipe_config() Matt Roper
2015-12-03 19:37 ` [PATCH 3/7] drm/i915: Setup clipped src/dest coordinates during FB reconstruction (v2) Matt Roper
2015-12-03 19:37 ` [PATCH 4/7] drm/i915: Convert hsw_compute_linetime_wm to use in-flight state Matt Roper
2015-12-03 19:37 ` [PATCH 5/7] drm/i915: Add extra paranoia to ILK watermark calculations Matt Roper
2015-12-03 19:37 ` [PATCH 6/7] drm/i915: Sanitize watermarks after hardware state readout (v4) Matt Roper
2015-12-03 19:37 ` [PATCH 7/7] drm/i915: Add two-stage ILK-style watermark programming (v8) Matt Roper
2015-12-14 23:51   ` [PATCH 7/7] drm/i915: Add two-stage ILK-style watermark programming (v9) Matt Roper
2016-01-06 10:38     ` Maarten Lankhorst [this message]
2016-01-06 18:51       ` Matt Roper
2016-01-06 19:34       ` [PATCH] drm/i915: Add two-stage ILK-style watermark programming (v10) Matt Roper
2016-01-07 11:29         ` Maarten Lankhorst
2016-01-06 12:58 ` [PATCH 0/7] Wrap up ILK-style atomic watermarks (v2) Maarten Lankhorst

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=568CEEA8.2000809@linux.intel.com \
    --to=maarten.lankhorst@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.d.roper@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).