diff mbox

[igt,2/8] tests/kms_fbc_crc: increase the FBC wait timeout

Message ID 1431024996-2267-3-git-send-email-przanoni@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Paulo Zanoni May 7, 2015, 6:56 p.m. UTC 
From: Paulo Zanoni <paulo.r.zanoni@intel.com>

Now that we moved to the frontbuffer tracking scheme, it may take a
long time for FBC to be updated after it is invalidated: 300ms is not
enough anymore.

The problem starts when i915_gem_execbuffer2() indirectly calls
intel_fb_obj_invalidate(), which disables FBC. After this, FBC only
gets reenabled when i915_gem_retire_work_handler() happens and
indirectly calls intel_frontbuffer_flush(). Notice that while FBC is
not yet enabled, the screen contents are correct, so this shouldn't
really be a bug.

Previous versions of this patch were replacing the gem_bo_busy() calls
with gem_sync(), but after some discussion we concluded this was not
the correct way to handle the problem, so let's just increase the
timeout so we can kill those subtest failures.

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

Patch

diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c
index 6022a6a..af4c370 100644
--- a/tests/kms_fbc_crc.c
+++ b/tests/kms_fbc_crc.c
@@ -204,7 +204,7 @@  static bool fbc_enabled(data_t *data)
 
 static bool wait_for_fbc_enabled(data_t *data)
 {
-	return igt_wait(fbc_enabled(data), 300, 30);
+	return igt_wait(fbc_enabled(data), 3000, 30);
 }
 
 static void test_crc(data_t *data, enum test_mode mode)