[PATCH 4/7] tests/kms_fbc_crc: also gem_sync() on exec_nop()

[Paulo Zanoni <przanoni@gmail.com>]

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.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
---
 tests/kms_fbc_crc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c
index 11078e0..d81f4a2 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,
-- 
2.1.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx