[Intel-gfx] Incorrect plane programming sequence results into a corrupted display/hard hung system

[Vyas, Tarun]

On KBL platforms, with HW overlay and/or PSR2, a hard hang with corrupted display is observed while running tests that frequently disable/re-enable primary/overlay planes. Details recorded in this FDO bug: https://bugs.freedesktop.org/show_bug.cgi?id=104975.

The issue has been root caused as a race where only partial register updates get latched on the next vblank, specifically, the updates that give the buffer allocation of the current plane before disabling it (again, details captured in the FDO bug above). There have been several optimizations to work around this bug:

1.       Enable Isochronous priority control (IPC)

2.       Increase the vblank evasion time to 250 usec (We have tried 500 usec but that doesn't helps).

3.       Disable DOUBLE_BUFFER_CTL while the updates are done, inside intel_pipe_update_start and intel_pipe_update_end (doesn't helps)

4.       Grab all the required locks before starting the pipe_update.

Per Ville, none of the above optimizations guarantee a *full* update before the vblank. As a result, to fix this issue the right way, the plane programming sequence needs to be altered in the driver as mentioned below:

"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."


Please comment as required.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20180412/c953bcf6/attachment-0001.html>