From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.mailbox.org ([80.241.60.212]:45743 "EHLO mx1.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750817AbdKSMnO (ORCPT ); Sun, 19 Nov 2017 07:43:14 -0500 Subject: Re: 4.9.62: intermittent flicker after upgrade from 4.9.61 To: Greg KH , Maarten Lankhorst Cc: =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , Matt Roper , 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 References: <20171118125100.GA32744@kroah.com> <20171119100712.GA25266@kroah.com> <20171119120813.GA30337@kroah.com> From: Rainer Fiebig Message-ID: Date: Sun, 19 Nov 2017 13:44:06 +0100 MIME-Version: 1.0 In-Reply-To: <20171119120813.GA30337@kroah.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: Greg KH wrote: > 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 >> #include >> +#include >> #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 > OK, after reverting the patches, the flicker *is* gone. BTW (for the future): Was it the right way to address stable@vger.kernel.org in this matter or would the bugreport at freedesktop.org have been enough? I'm a bit unsure about that. Thanks. Rainer Fiebig