On Mon, Dec 04, 2017 at 02:54:31PM +0200, Ville Syrjälä wrote:
On Mon, Dec 04, 2017 at 01:36:08PM +0100, gregkh@linuxfoundation.org wrote:
The patch below was submitted to be applied to the 4.14-stable tree.
I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst.
It fixes a regression. Why do you think it's not suitable for stable?
Because:
I could be totally wrong, and if so, please respond to stable@vger.kernel.org and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 3572f04c69ed4369da5d3c65d84fb18774aa60b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= ville.syrjala@linux.intel.com Date: Thu, 16 Nov 2017 18:02:15 +0200 Subject: [PATCH] drm/i915: Fix init_clock_gating for resume MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit
Moving the init_clock_gating() call from intel_modeset_init_hw() to intel_modeset_gem_init() had an unintended effect of not applying some workarounds on resume. This, for example, cause some kind of corruption to appear at the top of my IVB Thinkpad X1 Carbon LVDS screen after hibernation. Fix the problem by explicitly calling init_clock_gating() from the resume path.
I really hope this doesn't break something else again. At least the problems reported at https://bugs.freedesktop.org/show_bug.cgi?id=103549 didn't make a comeback, even after a hibernate cycle.
v2: Reorder the init_clock_gating vs. modeset_init_hw to match the display reset path (Rodrigo)
Cc: stable@vger.kernel.org Cc: Chris Wilson chris@chris-wilson.co.uk Cc: Rodrigo Vivi rodrigo.vivi@intel.com Fixes: 6ac43272768c ("drm/i915: Move init_clock_gating() back to where it was")
$ git describe --contains 6ac43272768c v4.15-rc1~19^2~13^2~1
How is this a 4.14 regression?
thanks,
greg k-h