summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorDaniel Vetter <daniel.vetter@ffwll.ch>2016-06-13 16:13:48 +0200
committerDaniel Vetter <daniel.vetter@ffwll.ch>2016-06-16 14:28:36 +0200
commit6c9c1b38d50d7905cdbccc83cef580b92a277996 (patch)
tree545db3296d348661e93fc126b652cef8050d918a /Documentation
parent94f050246b424ae82983bb199480aa9d620cf1bf (diff)
drm/i915: Move fb_bits updating later in atomic_commit
Currently it's part of prepare_fb, still in the first phase of atomic_commit which might fail. Which means that we need to have some heuristics in cleanup_fb to figure out whether things failed, or whether we just clean up the old fbs. That's fragile, and worse, once we start pipelining commits gets confused: While the last commit is still getting cleanup up we already hammer in the new one, and fb_bits aren't refcounted, resulting in lost bits and WARN_ON galore. We could instead try to make cleanup_fb more clever, but a simpler fix is to postpone the fb_bits tracking past the point of no return, where we commit all the software state. That also makes conceptually more sense, since fb_bits must be updated synchronously from the ioctl (they track usage from userspace pov, not from the hw pov), right before we're fully committed to the updated. This fixes WARNING splats from track_fb with page_flip implemented through atomic_commit. Testcase: igt/kms_flip/flip-vs-rmfb Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465827229-1704-4-git-send-email-daniel.vetter@ffwll.ch
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions