[PATCH i-g-t] tests/kms_explicit_fence: Replace fixed sleep with vblank wait

[Karthik B S <karthik.b.s@intel.com>]

The premature-update detection window between the NONBLOCK atomic
commit and the CRC sample used a fixed 100ms sleep. On
high-refresh-rate panels this 100ms wait covers many vblank
intervals (~24 at 240 Hz vs ~6 at 60 Hz) and is long enough to let
the display engine enter PSR/DC5. A subsequent CRC read then comes
back as 0xffffffff (read from a powered-down well), causing the
test to fail spuriously on these panels.

Replace the fixed sleep with 2-vblank wait:

 - It is the minimum wait that guarantees one full vblank boundary
   has elapsed past the commit, so a same-vblank-latch bug in the
   driver still has a deterministic window to manifest before the
   CRC is sampled.
 - It scales with the panel refresh rate, keeping the wait short
   on high-refresh panels (~8 ms at 240 Hz, ~33 ms at 60 Hz).

Cc: S Sebinraj <s.sebinraj@intel.com>
Cc: Krzysztof Karas <krzysztof.karas@intel.com>
Signed-off-by: Karthik B S <karthik.b.s@intel.com>
---
 tests/kms_explicit_fence.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/kms_explicit_fence.c b/tests/kms_explicit_fence.c
index 2ec9bf39d..d50a5af63 100644
--- a/tests/kms_explicit_fence.c
+++ b/tests/kms_explicit_fence.c
@@ -283,10 +283,10 @@ static void multiplane_atomic_fence_wait(data_t *data)
 		     "driver did not wait for all IN_FENCEs!");
 
 	/*
-	 * Wait briefly and verify display hasn't updated via CRC check.
-	 * In a buggy implementation, the display might update prematurely.
+	 * Wait 2 vblanks to catch premature latch bugs while
+	 * avoiding long idle windows that trigger PSR/DC power states.
 	 */
-	usleep(100000); /* 100ms */
+	igt_wait_for_vblank_count(data->crtc, 2);
 
 	/* Check if out fence signaled prematurely */
 	ret = sync_fence_status(out_fence);
-- 
2.43.0