<div dir="ltr">Hi!<div><br></div><div>I would like to report a problem which I believe is connected to changes introduced in this patch (<a href="https://lists.freedesktop.org/archives/intel-gfx/2017-February/120777.html">https://lists.freedesktop.org/archives/intel-gfx/2017-February/120777.html</a>). Specifically the problem is: screen freezes for 0.5 - 5 seconds (mostly for 2-3 seconds) when PSR is enabled (i915.enable_psr=1 kernel boot option). Freezes are more frequent with rich, dynamic screen content. The most reliable way to reproduce it, I discovered so far, is to start Gnome "Disk Usage Analyzer", analyze some catalog and move mouse pointer over color rectangles for a while. Usually that way I get 3-5 freezes in a minute. During normal PC usage freezes are happening less frequently, but still annoyingly. For the first time this problem appeared after update to kernel 4.12 and still there in recent 4.13 too.</div><div>I've looked into it a little and seems that mentioned patch is the one that brought it in. Git bisect indicates it as the first bad commit. After realizing that I tried to partly revert changes in the patch and found that following change:</div><div><pre style="white-space:pre-wrap;color:rgb(0,0,0)">   /* Treat this as an end-of-frame, like intel_user_framebuffer_dirty() */
-       if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU) {
-               i915_gem_clflush_object(obj, true);
-               intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
-       }
+       __i915_gem_object_flush_to_display(obj);
+       intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">when reverted solves the problem completely. One of the main difference is that in old version intel_fb_obj_flush was called conditionally and now it is called every time. So I surrounded the call with "if" just to check and it worked:<br></pre><pre><pre><font color="#000000"><span style="white-space:pre-wrap">/* Treat this as an end-of-frame, like intel_user_framebuffer_dirty() */
-       if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU) {
-               i915_gem_clflush_object(obj, true);
-               intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
-       }
+       __i915_gem_object_flush_to_display(obj);
+       if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU) {
+         intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
+ }<br></span></font></pre><pre> The above code was just a guess based on some logical insight. Although it eliminates the freezes, I don't really know if the change in calling intel_fb_obj_flush wasn't made intentionally. So could you please look at that case?</pre><pre>If you need any help in reproducing problem conditions or further diagnostic information, please let me know.</pre><pre><br></pre><pre>Thank you in advance,</pre><pre>Yaroslav Shabalin</pre></pre></div></div>