On Mon, Dec 04, 2017 at 10:45:50AM -0800, Rodrigo Vivi wrote:
On Mon, Dec 04, 2017 at 01:47:14PM +0000, Greg KH wrote:
On Mon, Dec 04, 2017 at 03:41:18PM +0200, Ville Syrjälä wrote:
On Mon, Dec 04, 2017 at 02:13:00PM +0100, Greg KH wrote:
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?
commit 6ac43272768ca901daac4076a66c2c4e3c7b9321 Author: Ville Syrjälä ville.syrjala@linux.intel.com Date: Wed Nov 8 15:35:55 2017 +0200
drm/i915: Move init_clock_gating() back to where it was... Cc: stable@vger.kernel.org
So 4.14 is going to break once that gets backported.
Ok, then the backporter should include both of those, as this one did not apply at all to the tree :(
Hi Greg,
I have few questions here around this history. Please help me to understand what is going on so we can improve the process and make sure this doesn't happen again.
I'm also bringing Daniel because he mentioned you have removed us from a blacklist and I don't know details about the history of that or on any details that could make you angry in the past with our fixes.
In summary:
- This patch here 3572f04c69ed ("drm/i915: Fix init_clock_gating\
for resume")
- Fixes 6ac43272768c (part of 4.15-rc2 now)
This patch got rejected and got a FAILED email
- Which fixes b7048ea12fbb (released first on v4.11)
- which fixes ed4a6a7ca853 (introduced on 4.7)
My questions:
- What happened with 6ac43272768c that wasn't considered for the 4.14 stable?
It did not apply, and got a FAILED email response.
It has the same Cc:stable tag as the last patch. Is there anything we should had done differently to make sure this patch was got by you on 4.14 before the second one blowing up your scripts?
Nope, not much you can do about it failing :)
- I wonder if 4.9 stable should also have all of them as well. Should it?
That's up to you all, not me.
Maybe the should part of it is more for Ville to tell us actually. But if so the next question would be what process should we follow for that? Just backport those 3 to 4.9.66 and test here and send to stable@ ml?
Yes that would be great.
- What was the reason that you used the "WTF - never to be seen again" tone instead of the regular "FAILED - if someone wants to apply..."? Or in other words, what can we do to improve and not make you angry again?
First off, the WTF is just an email script, don't take it personally.
Second, I sent it because it referred to a patch that was not in 4.14, and was not in any stable queue. I did not catch that I had already rejected it, as I really don't have a way to do that at all.
So all is fine, just backport the changes and send them to me and I'll be glad to queue them up.
thanks,
greg k-h