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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Feb 26 21:35:04 UTC 2018


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

--- Comment #26 from Rodrigo Vivi <rodrigo.vivi at gmail.com> ---
According to Art:
"
Buffer allocation overlap among enabled planes will cause a full frame
underrun, and that becomes a hard hange if pkgC or SAGV are enabled.  You need
to make sure the plane is disabled before reallocating the buffer it uses.  For
a single pipe it is sufficient to initiate the disabling of the plane before
the reallocation.  For multiple pipes it can be more complex.

In this case you should be doing something like this to ensure plane 2A turns
off before plane 1A steals the buffer
1.       PLANE_CTL_2A -> disabled
2.       PLANE_SURF_2A:  touch to arm double buffer update
3.       PLANE_BUF_CFG_1A -> (0-860)
4.       PLANE_SURF_1A: touch to arm double buffer update
If the planes are on different pipes there needs to be a wait for vblank
between step 2 and 3 to ensure the plane 2A disable completed.

General requirement is to never have an enabled plane's buffer allocation
overlap with another enabled plane.

If you disable plane X, don't give its buffer to plane Y until you are sure
plane X is disabled.
Be careful about the double-buffer arming.  For some stange legacy reason,
plane enable happens without needing arming from PLANE_SURF, so on
disable->enable you write PLANE_CTL last with enable bit set.
Once plane is enabled, arming always comes from PLANE_SURF.
"

So I confirmed that our code actually doesn't seem to respect this.
We program the BUF_CFG during atomic commit begin CRTC but we actually
disable the plane on middle of atomic commit.

I did some experiments to move the BUF_CFG right to after disabling planes
and only when disabling planes and result here was horrible. Blank and
corrupted
screens.

So, Ville and Marteen... ideas?

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


More information about the intel-gfx-bugs mailing list