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.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to