GitLab

Problem with old non blocking commit:
In some cases with high resolution and high frame rate (such as playing graphics or media content on a 4K 60Hz monitor), switching modes (extended->mirrored) will cause DRM to get 2 nearly back to back nonblocking commits from Chrome: One for disabling planes on old controller, and another actual content flip. Due to the close time proximity of the 2 nonblocking commits, while prepping the 2nd one, DRM will throw -EBUSY error because at this time, the flip_done for the 1st commit was not yet complete as userspace is not allowed to get ahead of the previous commit with nonblocking ones (a kernel check).
Behavior after the EBUSY depends on the application. On Chrome, the GPU crashes, and resets, trying to recover to a good state, but content would be reset as well.

Fix with blocking commit:
Making DisablingOverlayPlanes a blocking commit will guarantee that the flip_done for this commit is complete before OS sends any subsequent non-blocking page flips. On blocking commits, DRM does not hand control back to OS until well after the flip_done is complete.

Rationale of the new design:
DisablingOverlayPlanes happens on the same thread and during the same time as the full modeset, which is a blocking commit. So makes sense that all modeset-related commits to be blocking until everything has been set/reset properly.


BUG: b/171409360,b/172306392
TEST: with 4K display attached to a kohaku, switch from extended to mirror mode.
Change-Id: Icff491be107267eb49cf3a2846b6d219a0f82c4d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2559170
Commit-Queue: Mark Yacoub <markyacoub@google.com>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Cr-Commit-Position: refs/heads/master@{#831976}