<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 17, 2016 at 3:17 AM, Paul Bolle <span dir="ltr"><<a href="mailto:pebolle@tiscali.nl" target="_blank">pebolle@tiscali.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 2016-11-14 at 18:35 +0200, <a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a> wrote:<br>
> From: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a><wbr>><br>
><br>
> When we end up not recomputing the cdclk, we need to populate<br>
> intel_state->cdclk with the "atomic_cdclk_freq" instead of the<br>
> current cdclk_freq. When no pipes are active, the actual cdclk_freq<br>
> may be lower than what the configuration of the planes and<br>
> pipes would require from the point of view of the software state.<br>
><br>
> This fixes bogus WARNS from skl_max_scale() which is trying to check<br>
> the plane software state against the cdclk frequency. So any time<br>
> it got called during DPMS off for instance, we might have tripped<br>
> the warn if the current mode would have required a higher than<br>
> minimum cdclk.<br>
><br>
> v2: Drop the dev_cdclk stuff (Maarten)<br>
><br>
> Cc: Maarten Lankhorst <<a href="mailto:maarten.lankhorst@linux.intel.com">maarten.lankhorst@linux.<wbr>intel.com</a>><br>
> Cc: Mika Kahola <<a href="mailto:mika.kahola@intel.com">mika.kahola@intel.com</a>><br>
> Cc: <a href="mailto:bruno.pagani@ens-lyon.org">bruno.pagani@ens-lyon.org</a><br>
> Cc: Daniel J Blueman <<a href="mailto:daniel.blueman@gmail.com">daniel.blueman@gmail.com</a>><br>
> Cc: Paul Bolle <<a href="mailto:pebolle@tiscali.nl">pebolle@tiscali.nl</a>><br>
> Cc: Joseph Yasi <<a href="mailto:joe.yasi@gmail.com">joe.yasi@gmail.com</a>><br>
> Tested-by: Paul Bolle <<a href="mailto:pebolle@tiscali.nl">pebolle@tiscali.nl</a>> (v1)<br>
<br>
</span>I've run v2 of this patch (on top of v4.8.8) for over a day now without<br>
hitting the WARN_ON_ONCE. Of course, my machine was suspended for large parts<br>
of that period. But still, the WARN_ON_ONCE used to be triggered much quicker.<br>
So in short: you can drop "(v1)" as I tested both versions now.<br>
<br>
By the way, the scary i915 *ERROR*s are gone now too, as are the visual<br>
glitches that accompanied those *ERROR*s. Apparently the v4.8.y series picked<br>
up a few fixes. Those made i915 a much better experience. Nice! <br>
<span class=""><br>
> Tested-by: Joseph Yasi <<a href="mailto:joe.yasi@gmail.com">joe.yasi@gmail.com</a>> (v1)<br></span></blockquote><div><br></div><div>I've also applied this patch (and the other two in the series) on top of 4.8.8. I haven't hit the WARN_ON_ONCE with the patches either.</div><div><br></div><div>The flickering I was experiencing earlier turned out to be due to a motherboard failure. Replacing the motherboard fixed that problem.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Cc: <a href="mailto:stable@vger.kernel.org">stable@vger.kernel.org</a><br>
> Fixes: 1a617b77658e ("drm/i915: Keep track of the cdclk as if all crtc's were active.")<br>
<br>
</span>(I seem to remember discussing the reasons why a v4.6 bug was first noticed on<br>
v4.8. I haven't looked into that yet. By now it's unlikely I ever will. Sorry<br>
about that.)<br>
<span class=""><br>
> Bugzilla: <a href="https://bugs.freedesktop.org/show_bug.cgi?id=98214" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/<wbr>show_bug.cgi?id=98214</a><br>
> Signed-off-by: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a><wbr>><br>
> Reviewed-by: Maarten Lankhorst <<a href="mailto:maarten.lankhorst@linux.intel.com">maarten.lankhorst@linux.<wbr>intel.com</a>><br>
<br>
</span>Thanks,<br>
<br>
<br>
Paul Bolle<br>
</blockquote></div><br></div></div>