[Bug 104975] Delay in skl_disable_plane() causes a system freeze
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Sat Apr 21 00:59:44 UTC 2018
https://bugs.freedesktop.org/show_bug.cgi?id=104975
--- Comment #59 from Azhar <azhar.shaikh at intel.com> ---
(In reply to Ville Syrjala from comment #58)
> (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.
With this patch on Linux-stable 4.15.18 without the support of IPC on BXT+,
still causes hard hangs.
--
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/20180421/6d399d39/attachment-0001.html>
More information about the intel-gfx-bugs
mailing list