Quoting Oscar Mateo (2017-10-09 21:58:51)
> Apart from context based workarounds, we can now also test for global
> MMIO and whitelisting ones.
One thing to note here is that using the kernel list still has the
reliance on it being trustworthy and complete. You already noted one w/a
that is applied by the BIOS (and cannot be applied by the kernel). If
this was intended to be a tool that reported whether the system had all
known workarounds, it should be kernel independent. (Atm the igt goal is
simply be a regression test that the kernel w/a stick.)
> +static void wait_gpu(void)
> +{
> + int fd = drm_open_driver(DRIVER_INTEL);
> + gem_quiescent_gpu(fd);
> + close(fd);
> +}
> +static int mmio_workarounds_fail_count(struct intel_wa_reg *wa_regs, int num_wa_regs)
> +{
> + int i, fail_count = 0;
> +
> + if (!num_wa_regs)
> + return 0;
> +
> + /*
> + * There is a small delay after coming ot of rc6 to the correct
> + * render context values will get loaded by hardware (bdw,chv).
> + * This here ensures that we have the correct context loaded before
> + * we start to read values
> + */
> + wait_gpu();
Hmm. So my goal for gem_quiescent_gpu() is not to issue a new request,
i.e. if the hw is idle, it will remain idle and not necessarily start a
new context (or kick rc6).
If we need an active gpu context whilst doing the mmio, kick off a
spinbatch here. (We should augment that to allow us to wait until it has
started). Then kill the spinbatch after the reads.
Otherwise we just have the problem we had before on bxt where we did the
mmio long before the gpu had started.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
