All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Roper <matthew.d.roper@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 0/9] Wrap up ILK-style atomic watermarks
Date: Wed, 25 Nov 2015 09:04:11 -0800	[thread overview]
Message-ID: <20151125170411.GD23476@intel.com> (raw)
In-Reply-To: <20151125170011.GR4437@intel.com>

On Wed, Nov 25, 2015 at 07:00:11PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 25, 2015 at 08:48:26AM -0800, Matt Roper wrote:
> > We've been chasing a regression[1] that prevented us from merging the last
> > couple patches of the ILK-style atomic watermark series.  We've finally
> > identified the culprit --- if we fail to reconstruct the BIOS FB, our internal
> > driver state was left in an inconsistent state which caused confusion for the
> > watermark code.  Here's a series that collects that fix (along with a couple
> > other bugfixes that were found while debugging), a few debugging enhancements,
> > and the completion of the ILK atomic watermark series.
> > 
> >  * The first patch in this series addresses that issue and
> >    ensures that we cleanly turn off the primary plane if we're unable to inherit
> >    the framebuffer.  
> >  * Patches 2-4 just clarify/expand some of the information dumped by the
> >    driver while debugging.
> >  * Patches 5 and 6 fix two additional bugs that were discovered while
> >    searching for the cause of the regression.
> >  * Patch 7 just adds some extra paranoia and invariant checking to the
> >    watermark code.
> >  * Patches 8 and 9 are the two final patches from the original atomic watermark
> >    series; with the fixes earlier in the series, we've confirmed that they no
> >    longer cause regressions on Jani's machine.
> > 
> > [1] http://lists.freedesktop.org/archives/intel-gfx/2015-October/077113.html
> 
> Quickly skimmed through the series to see if there was a fix to
> the "merging optimal wms instead of merging active wms like we
> should" bug we have in the current code right now. Nothing
> relevant caught my eye at least.

I'm not sure I'm aware of this problem; is there a bugzilla or mailing
list thread that describes the issue?


Matt

> 
> > 
> > Matt Roper (9):
> >   drm/i915: Disable primary plane if we fail to reconstruct BIOS fb
> >   drm/i915: Dump in-flight plane state while dumping in-flight CRTC
> >     state
> >   drm/i915: Clarify plane state during CRTC state dumps (v2)
> >   drm/i915: Dump pipe config after initial FB is reconstructed
> >   drm/i915: Setup clipped src/dest coordinates during FB reconstruction
> >     (v2)
> >   drm/i915: Convert hsw_compute_linetime_wm to use in-flight state
> >   drm/i915: Add extra paranoia to ILK watermark calculations
> >   drm/i915: Sanitize watermarks after hardware state readout (v2)
> >   drm/i915: Add two-stage ILK-style watermark programming (v7)
> > 
> >  drivers/gpu/drm/drm_atomic_helper.c  |   1 +
> >  drivers/gpu/drm/i915/i915_drv.h      |   5 +
> >  drivers/gpu/drm/i915/intel_atomic.c  |   1 +
> >  drivers/gpu/drm/i915/intel_display.c | 195 +++++++++++++++++++++++++++++++++--
> >  drivers/gpu/drm/i915/intel_drv.h     |  31 +++++-
> >  drivers/gpu/drm/i915/intel_pm.c      | 186 ++++++++++++++++++++++++---------
> >  6 files changed, 359 insertions(+), 60 deletions(-)
> > 
> > -- 
> > 2.1.4
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-11-25 17:04 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-25 16:48 [PATCH 0/9] Wrap up ILK-style atomic watermarks Matt Roper
2015-11-25 16:48 ` [PATCH 1/9] drm/i915: Disable primary plane if we fail to reconstruct BIOS fb Matt Roper
2015-12-03 11:40   ` Maarten Lankhorst
2015-11-25 16:48 ` [PATCH 2/9] drm/i915: Dump in-flight plane state while dumping in-flight CRTC state Matt Roper
2015-12-03 12:27   ` Maarten Lankhorst
2015-12-04  9:31     ` Daniel Vetter
2015-11-25 16:48 ` [PATCH 3/9] drm/i915: Clarify plane state during CRTC state dumps (v2) Matt Roper
2015-12-03 12:28   ` Maarten Lankhorst
2015-11-25 16:48 ` [PATCH 4/9] drm/i915: Dump pipe config after initial FB is reconstructed Matt Roper
2015-12-03 12:29   ` Maarten Lankhorst
2015-11-25 16:48 ` [PATCH 5/9] drm/i915: Setup clipped src/dest coordinates during FB reconstruction (v2) Matt Roper
2015-12-03 12:06   ` Maarten Lankhorst
2015-12-03 17:08     ` Matt Roper
2015-11-25 16:48 ` [PATCH 6/9] drm/i915: Convert hsw_compute_linetime_wm to use in-flight state Matt Roper
2015-11-25 16:48 ` [PATCH 7/9] drm/i915: Add extra paranoia to ILK watermark calculations Matt Roper
2015-11-25 16:48 ` [PATCH 8/9] drm/i915: Sanitize watermarks after hardware state readout (v2) Matt Roper
2015-11-25 17:05   ` Ville Syrjälä
2015-11-30 23:56     ` [PATCH] drm/i915: Sanitize watermarks after hardware state readout (v3) Matt Roper
2015-12-01  7:42       ` Maarten Lankhorst
2015-11-30  9:50   ` [PATCH 8/9] drm/i915: Sanitize watermarks after hardware state readout (v2) Maarten Lankhorst
2015-11-30 23:09     ` Matt Roper
2015-11-30 23:22     ` [PATCH] drm/atomic-helper: Grab connection_mutex while duplicating state Matt Roper
2015-12-01  7:24       ` Daniel Vetter
2015-12-01  7:37       ` Maarten Lankhorst
2015-11-25 16:48 ` [PATCH 9/9] drm/i915: Add two-stage ILK-style watermark programming (v7) Matt Roper
2015-11-25 17:08   ` Ville Syrjälä
2015-12-01  0:08     ` Matt Roper
2015-11-25 17:00 ` [PATCH 0/9] Wrap up ILK-style atomic watermarks Ville Syrjälä
2015-11-25 17:04   ` Matt Roper [this message]
2015-11-25 17:14     ` 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=20151125170411.GD23476@intel.com \
    --to=matthew.d.roper@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@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.