<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Delay in skl_disable_plane() causes a system freeze" href="https://bugs.freedesktop.org/show_bug.cgi?id=104975#c57">Comment # 57</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Delay in skl_disable_plane() causes a system freeze" href="https://bugs.freedesktop.org/show_bug.cgi?id=104975">bug 104975</a> from <a class="email" href="mailto:ville.syrjala@linux.intel.com" title="Ville Syrjala <ville.syrjala@linux.intel.com>"> Ville Syrjala</a> <pre>(In reply to marc.herbert from <a href="show_bug.cgi?id=104975#c51">comment #51</a>) > Created <a href="attachment.cgi?id=138830" name="attach_138830" title="vertical corruption unless wait for vblank after disabling cursor">attachment 138830</a> <a href="attachment.cgi?id=138830&action=edit" title="vertical corruption unless wait for vblank after disabling cursor">[details]</a> > vertical corruption unless wait for vblank after disabling cursor > > Could this be related? See screenshot attached and workaround by: > > Kristian H. Kristensen > > <a href="https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/">https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/</a> > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> </ul> </body> </html>