Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@xxxxxxxxx>
Fixes: 19f81df2859eb1 ("drm/i915/perf: Add OA unit support for Gen 8+")
---
drivers/gpu/drm/i915/i915_perf.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 357e63beb373..2094358860d5 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1838,6 +1838,29 @@ static int gen8_enable_metric_set(struct i915_perf_stream *stream)
config_oa_regs(dev_priv, oa_config->mux_regs, oa_config->mux_regs_len);
+ /* It apparently takes a fairly long time for a new MUX
+ * configuration to be be applied after these register writes.
+ * This delay duration was derived empirically based on the
+ * render_basic config but hopefully it covers the maximum
+ * configuration latency.
+ *
+ * As a fallback, the checks in _append_oa_reports() to skip
+ * invalid OA reports do also seem to work to discard reports
+ * generated before this config has completed - albeit not
+ * silently.
+ *
+ * Unfortunately this is essentially a magic number, since we
+ * don't currently know of a reliable mechanism for predicting
+ * how long the MUX config will take to apply and besides
+ * seeing invalid reports we don't know of a reliable way to
+ * explicitly check that the MUX config has landed.
+ *
+ * It's even possible we've miss characterized the underlying
+ * problem - it just seems like the simplest explanation why
+ * a delay at this location would mitigate any invalid reports.
+ */
+ usleep_range(15000, 20000);
+
config_oa_regs(dev_priv, oa_config->b_counter_regs,
oa_config->b_counter_regs_len);
--
2.21.0.392.gf8f6787159e
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
