All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915: Don't require primary->fb in intel_crtc_active()
Date: Wed, 4 Mar 2015 11:45:42 +0200	[thread overview]
Message-ID: <20150304094542.GK11371@intel.com> (raw)
In-Reply-To: <1425435313-31711-1-git-send-email-matthew.d.roper@intel.com>

On Tue, Mar 03, 2015 at 06:15:12PM -0800, Matt Roper wrote:
> Universal planes allow us to have an active CRTC without a primary plane
> framebuffer bound.  Drop the test for primary->fb from
> intel_crtc_active() since we can clearly have active CRTC's without a
> framebuffer, and this check is now interfering with watermark
> calculations when we try to re-enable the primary plane.
> 
> Note that commit
> 
>         commit 0fda65680e92545caea5be7805a7f0a617fb6c20
>         Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>         Date:   Fri Feb 27 15:12:35 2015 +0000
> 
>             drm/i915/skl: Update watermarks for Y tiling
> 
> adds a test for primary plane enable/disable to trigger a watermark
> update (previously we ignored updates to primary planes, which wasn't
> really correct, but we got lucky since we always pretended the primary
> plane was on).  Tvrtko's patch tries to update watermarks when we
> re-enable the primary plane, but that watermark computation gets aborted
> early because intel_crtc_active() always returns false when the primary
> plane is disabled; this leads to watermark underruns (at least on
> platforms with ILK-style watermark code).

I think this will make a bunch of the old platforms blow up. Well, I
think they might already blow up since they now look at crtc->state->fb
based on the result of intel_crtc_active(). So I believe more fixes are
needed all over the wm code at least.

In fact looking at the code, I think most (or all?) of the call sites in
the in the ilk+ wm code should just be using crtc->active. So for some
extra safety it might make sense to do leave intel_crtc_active() alone
for now, or in fact we should maybe change it to also look at
primary->state->fb instead. That should more or less keep the old
platforms in the same state as they were before, while letting new
platforms handle each plane properly.

> 
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 589addf..92cb2ff 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -893,11 +893,8 @@ bool intel_crtc_active(struct drm_crtc *crtc)
>  	 *
>  	 * We can ditch the adjusted_mode.crtc_clock check as soon
>  	 * as Haswell has gained clock readout/fastboot support.
> -	 *
> -	 * We can ditch the crtc->primary->fb check as soon as we can
> -	 * properly reconstruct framebuffers.
>  	 */
> -	return intel_crtc->active && crtc->primary->fb &&
> +	return intel_crtc->active &&
>  		intel_crtc->config->base.adjusted_mode.crtc_clock;
>  }
>  
> -- 
> 1.8.5.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2015-03-04  9:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-04  2:15 [PATCH 1/2] drm/i915: Don't require primary->fb in intel_crtc_active() Matt Roper
2015-03-04  2:15 ` [PATCH 2/2] drm/i915: Don't assume primary & cursor are always on for wm calculation Matt Roper
2015-03-04  8:18   ` Jani Nikula
2015-03-04 16:17   ` shuang.he
2015-03-04 17:29   ` Tvrtko Ursulin
2015-03-06  1:31     ` [PATCH 2/2] drm/i915: Don't assume primary & cursor are always on for wm calculation (v2) Matt Roper
2015-03-06  9:58       ` Tvrtko Ursulin
2015-03-06 12:57       ` Ville Syrjälä
2015-03-04  9:45 ` Ville Syrjälä [this message]
2015-03-04 16:13   ` [PATCH 1/2] drm/i915: Don't require primary->fb in intel_crtc_active() Daniel Vetter
2015-03-04 18:21     ` Ville Syrjälä
2015-03-05 12:20       ` Daniel Vetter
2015-03-05 12:48         ` Ville Syrjälä
2015-03-04 16:14 ` Daniel Vetter
2015-03-04 17:26 ` Tvrtko Ursulin
2015-03-04 17:42   ` Matt Roper
2015-03-05 15:07     ` Tvrtko Ursulin
2015-03-06 16:44       ` Daniel Vetter

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=20150304094542.GK11371@intel.com \
    --to=ville.syrjala@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 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.