<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#c58">Comment # 58</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 Ville Syrjala from <a href="show_bug.cgi?id=104975#c57">comment #57</a>) > (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. The race is something more subtle than that since manually poking those register across vblanks is obviously fine. It looks like I managed to avoid the planes staying on past their bedtime with the following branch: git://github.com/vsyrjala/linux.git double_buffer_ctl_ddb_wa I hope it will also prevent the hard hangs. Please test.</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>