diff mbox

[igt,4/4] tests/kms_fbc_crc: also gem_sync() on exec_nop()

Message ID 1418055164-1536-4-git-send-email-przanoni@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Paulo Zanoni Dec. 8, 2014, 4:12 p.m. UTC 
From: Paulo Zanoni <paulo.r.zanoni@intel.com>

When we're doing the context subtest, at the end of prepare_test() we
exec a single nop batch on the front buffer, which invalidates FBC.
With the new frontbuffer tracking scheme it may take a while for FBC
to be reenabled, so we end up failing the first fbc_enabled()
assertion inside test_crc().

Other possible implementations:
 - Call gem_sync() at the specific prepare_test() point, not at every
   exec_nop() call.
 - Change the fbc_enabled() assertion to wait_for_fbc_enabled() and
   give it a bigger timeout value.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
---
 tests/kms_fbc_crc.c | 2 ++
 1 file changed, 2 insertions(+)
diff mbox

Patch

diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c
index 354a2b7..decb83e 100644
--- a/tests/kms_fbc_crc.c
+++ b/tests/kms_fbc_crc.c
@@ -155,6 +155,8 @@  static void exec_nop(data_t *data, uint32_t handle, drm_intel_context *context)
 
 	intel_batchbuffer_flush_with_context(batch, context);
 	intel_batchbuffer_free(batch);
+
+	gem_sync(data->drm_fd, handle);
 }
 
 static void fill_render(data_t *data, uint32_t handle,