On 25/05/2018 16:14, Chris Wilson wrote:
We may not idle immediately after a hang, and indeed may send a pulse
down the pipeline periodically to become idle. Rather than make a flimsy
assumption about how long we need to sleep before the system idles,
wait for the system to declare itself idle; flushing it to idle in the
process!
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com>
---
tests/perf_pmu.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 590e6526b..9af192dd8 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -281,16 +281,9 @@ single(int gem_fd, const struct intel_execution_engine2
*e, unsigned int flags)
/* Check for idle after hang. */
if (flags & FLAG_HANG) {
- /* Sleep for a bit for reset unwind to settle. */
- usleep(500e3);
- /*
- * Ensure batch was executing before reset, meaning it must be
- * idle by now. Unless it did not even manage to start before we
- * triggered the reset, in which case the idleness check below
- * might fail. The latter is very unlikely since there are two
- * sleeps during which it had an opportunity to start.
- */
+ gem_quiescent_gpu(gem_fd);
igt_assert(!gem_bo_busy(gem_fd, spin->handle));
+
val = pmu_read_single(fd);
slept = measured_usleep(batch_duration_ns / 1000);
val = pmu_read_single(fd) - val;
Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
