stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Rainer Fiebig <jrf@mailbox.org>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Matt Roper" <matthew.d.roper@intel.com>,
	daniel.vetter@intel.com, jani.nikula@linux.intel.com,
	airlied@linux.ie, intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: 4.9.62: intermittent flicker after upgrade from 4.9.61
Date: Sun, 19 Nov 2017 13:08:13 +0100	[thread overview]
Message-ID: <20171119120813.GA30337@kroah.com> (raw)
In-Reply-To: <dcc6748a-dd2b-13db-0310-29382d2d40b6@mailbox.org>

On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote:
> Greg KH wrote:
> > On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote:
> >> Greg KH wrote:
> >>> On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote:
> >>>> Hi!
> >>>>
> >>>> Hopefully the right addressee.
> >>>>
> >>>> Encountered two bad backports which cause screen-flicker.
> >>>> dmesg shows:
> >>>>
> >>>> ...
> >>>> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
> >>>> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
> >>>> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
> >>>> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun
> >>>> ...
> >>>>
> >>>> CPU: Intel Core i3 (Clarkdale/Ironlake)
> >>>>
> >>>> The backports are:
> >>>>
> >>>> - diff --git a/drivers/gpu/drm/i915/intel_pm.c
> >>>> b/drivers/gpu/drm/i915/intel_pm.c
> >>>>     index 49de476..277a802 100644
> >>>> - diff --git a/drivers/gpu/drm/i915/intel_drv.h
> >>>> b/drivers/gpu/drm/i915/intel_drv.h
> >>>>     index a19ec06..3ce9ba3 100644
> >>>>
> >>>> After reversing them the flicker is gone, no more messages in dmesg. All
> >>>> else OK so far.
> >>>
> >>> So which commit was the one that caused the problem?  I will be glad to
> >>> revert it.
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >>>
> >>>
> >>
> >> I started by reverting the more complex one first ("index
> >> 49de476..277a802100644"). But the kernel wouldn't compile then.
> > 
> > What git commit id is that?  I don't see those ids in the 4.9-stable
> > tree.
> > 
> >> So I also reverted "index a19ec06..3ce9ba3 100644". After that the
> >> kernel compiled just fine and the problems were gone (still are).
> > 
> > Same here, what git commit id was this?
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> OK, no mistake. IIRC, I took the patches (and the IDs) from the
> changelog for patch-4.9.62. I've attached both, so you can check yourself.
> 
> I've also applied a freshly downloaded patch-4.9.62 to a freshly
> expanded 4.9 and re-compiled. The flicker is there. I haven't yet
> reverted the two patches but I'm confident that after having done so the
> flicker will be gone. If not I'll let you know.
> 
> As a good news: 4.14 is *not* affected. So to me it seems those two
> patches are part of sort of a package and can not be backported alone.
> 
> So long!
> Rainer Fiebig

> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 49de476..277a802 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -27,6 +27,7 @@
>  
>  #include <linux/cpufreq.h>
>  #include <drm/drm_plane_helper.h>
> +#include <drm/drm_atomic_helper.h>
>  #include "i915_drv.h"
>  #include "intel_drv.h"
>  #include "../../../platform/x86/intel_ips.h"
> @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const struct drm_i915_private *dev_priv,
>  				 const struct intel_crtc *intel_crtc,
>  				 int level,
>  				 struct intel_crtc_state *cstate,
> -				 struct intel_plane_state *pristate,
> -				 struct intel_plane_state *sprstate,
> -				 struct intel_plane_state *curstate,
> +				 const struct intel_plane_state *pristate,
> +				 const struct intel_plane_state *sprstate,
> +				 const struct intel_plane_state *curstate,
>  				 struct intel_wm_level *result)
>  {
>  	uint16_t pri_latency = dev_priv->wm.pri_latency[level];
> @@ -2341,28 +2342,24 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state *cstate)
>  	struct intel_pipe_wm *pipe_wm;
>  	struct drm_device *dev = state->dev;
>  	const struct drm_i915_private *dev_priv = to_i915(dev);
> -	struct intel_plane *intel_plane;
> -	struct intel_plane_state *pristate = NULL;
> -	struct intel_plane_state *sprstate = NULL;
> -	struct intel_plane_state *curstate = NULL;
> +	struct drm_plane *plane;
> +	const struct drm_plane_state *plane_state;
> +	const struct intel_plane_state *pristate = NULL;
> +	const struct intel_plane_state *sprstate = NULL;
> +	const struct intel_plane_state *curstate = NULL;
>  	int level, max_level = ilk_wm_max_level(dev), usable_level;
>  	struct ilk_wm_maximums max;
>  
>  	pipe_wm = &cstate->wm.ilk.optimal;
>  
> -	for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
> -		struct intel_plane_state *ps;
> +	drm_atomic_crtc_state_for_each_plane_state(plane, plane_state, &cstate->base) {
> +		const struct intel_plane_state *ps = to_intel_plane_state(plane_state);
>  
> -		ps = intel_atomic_get_existing_plane_state(state,
> -							   intel_plane);
> -		if (!ps)
> -			continue;
> -
> -		if (intel_plane->base.type == DRM_PLANE_TYPE_PRIMARY)
> +		if (plane->type == DRM_PLANE_TYPE_PRIMARY)
>  			pristate = ps;
> -		else if (intel_plane->base.type == DRM_PLANE_TYPE_OVERLAY)
> +		else if (plane->type == DRM_PLANE_TYPE_OVERLAY)
>  			sprstate = ps;
> -		else if (intel_plane->base.type == DRM_PLANE_TYPE_CURSOR)
> +		else if (plane->type == DRM_PLANE_TYPE_CURSOR)
>  			curstate = ps;
>  	}
>  
> @@ -2384,11 +2381,9 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state *cstate)
>  	if (pipe_wm->sprites_scaled)
>  		usable_level = 0;
>  
> -	ilk_compute_wm_level(dev_priv, intel_crtc, 0, cstate,
> -			     pristate, sprstate, curstate, &pipe_wm->raw_wm[0]);
> -
>  	memset(&pipe_wm->wm, 0, sizeof(pipe_wm->wm));
> -	pipe_wm->wm[0] = pipe_wm->raw_wm[0];
> +	ilk_compute_wm_level(dev_priv, intel_crtc, 0, cstate,
> +			     pristate, sprstate, curstate, &pipe_wm->wm[0]);
>  
>  	if (IS_HASWELL(dev) || IS_BROADWELL(dev))
>  		pipe_wm->linetime = hsw_compute_linetime_wm(cstate);
> @@ -2398,8 +2393,8 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state *cstate)
>  
>  	ilk_compute_wm_reg_maximums(dev, 1, &max);
>  
> -	for (level = 1; level <= max_level; level++) {
> -		struct intel_wm_level *wm = &pipe_wm->raw_wm[level];
> +	for (level = 1; level <= usable_level; level++) {
> +		struct intel_wm_level *wm = &pipe_wm->wm[level];
>  
>  		ilk_compute_wm_level(dev_priv, intel_crtc, level, cstate,
>  				     pristate, sprstate, curstate, wm);
> @@ -2409,13 +2404,10 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state *cstate)
>  		 * register maximums since such watermarks are
>  		 * always invalid.
>  		 */
> -		if (level > usable_level)
> -			continue;
> -
> -		if (ilk_validate_wm_level(level, &max, wm))
> -			pipe_wm->wm[level] = *wm;
> -		else
> -			usable_level = level;
> +		if (!ilk_validate_wm_level(level, &max, wm)) {
> +			memset(wm, 0, sizeof(*wm));
> +			break;
> +		}
>  	}
>  
>  	return 0;

> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index a19ec06..3ce9ba3 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -457,7 +457,6 @@ struct intel_crtc_scaler_state {
>  
>  struct intel_pipe_wm {
>  	struct intel_wm_level wm[5];
> -	struct intel_wm_level raw_wm[5];
>  	uint32_t linetime;
>  	bool fbc_wm_enabled;
>  	bool pipe_enabled;

Ok, so this looks like commit 8777b927b92cf5b6c29f9f9d3c737addea9ac8a7
upstream which is commit 7de694782cbe7840f2c0de6f1e70f41fc1b8b6e8 in
4.9.62.

I've cc:ed the authors of that patch now.

Maarten, any hints?  Should I revert this from 4.9-stable, or was there
a follow-on patch that resolved this issue in mainline?

thanks,

greg k-h

  reply	other threads:[~2017-11-19 12:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-18 12:47 4.9.62: intermittent flicker after upgrade from 4.9.61 Rainer Fiebig
2017-11-18 12:51 ` Greg KH
2017-11-18 16:08   ` Rainer Fiebig
2017-11-19 10:07     ` Greg KH
2017-11-19 11:02       ` Rainer Fiebig
2017-11-19 11:56       ` Rainer Fiebig
2017-11-19 12:08         ` Greg KH [this message]
2017-11-19 12:44           ` Rainer Fiebig
2017-11-19 13:27             ` Greg KH
2017-11-20  8:40               ` Jani Nikula
2017-11-20  8:51                 ` Rainer Fiebig
2017-11-20 11:27                   ` Maarten Lankhorst
2017-11-20 11:38                     ` Rainer Fiebig
2017-11-20 12:07                       ` Maarten Lankhorst
2017-11-20 11:45                     ` Rainer Fiebig
2017-11-20 12:17                     ` Rainer Fiebig
2017-11-23 21:09                       ` Rainer Fiebig
2017-11-24  6:48                         ` Greg KH
2017-11-24  6:57                           ` Rainer Fiebig
2017-11-24  7:03                           ` Rainer Fiebig
2017-11-28  9:17                           ` Greg KH
2017-11-18 17:19   ` Rainer Fiebig

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=20171119120813.GA30337@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=airlied@linux.ie \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jrf@mailbox.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthew.d.roper@intel.com \
    --cc=stable@vger.kernel.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 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).