[Bug 104975] Delay in skl_disable_plane() causes a system freeze
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Fri Apr 20 19:30:59 UTC 2018
https://bugs.freedesktop.org/show_bug.cgi?id=104975
--- Comment #58 from Ville Syrjala <ville.syrjala at linux.intel.com> ---
(In reply to Ville Syrjala from comment #57)
> (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.
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.
--
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/3642e98b/attachment.html>
More information about the intel-gfx-bugs
mailing list