[Bug 104975] Delay in skl_disable_plane() causes a system freeze

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=104975

--- Comment #57 from Ville Syrjala <ville.syrjala at linux.intel.com> ---
(In reply to marc.herbert from comment #51)
> Created attachment 138830 [details]
> vertical corruption unless wait for vblank after disabling cursor
> 
> Could this be related? See screenshot attached and workaround by:
> 
> Kristian H. Kristensen
> 
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/
> 877396
> 
> CHROMIUM: drm/i915: Wait for vblank after disabling cursor
> 
> The cursor disable write is latched on vsync but if we do a modeset
> before that happens the write seems to be discarded and the cursor
> stays on. The CURCNTL register will still read back 0 as if the write
> took, but underlying hardware didn't change. We don't disable the
> cursor often, so we can just force the pre-GEN9 path for cursor
> that waits for vblank.
> 
> 	 * Unfortunately, the GEN9+ double buffering seems to be buggy when it
> 	 * races with a modeset....
> 
> I'm guessing that this issue may well be present in upstream kernels and
> regular Linux distros, the difference being that no other distro so far has
> shipped with Y-tiled framebuffers.
> 
> 
> (I doubt many distros have shipped with hardware overlays either -- Marc)

I'm definitely seeing something odd going on with the plane double buffering on
my SKL here. The PLANE_CTL=0 write doesn't seem to stick sometimes and instead
I'm seeing the plane scanning out stale data instead of being off. I suspect
this could happen when the PLANE_CTL write lands before the vblank, and the
PLANE_SURF write lands after the vblank, but I'll need to do some more low
level hw poking to confirm that theory.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180420/d090c8eb/attachment-0001.html>