Quoting Ville Syrjälä (2020-10-22 23:38:16)
> On Thu, Oct 22, 2020 at 10:08:14PM +0100, Chris Wilson wrote:
> > Since Ironlake uses intel_ips.ko for its dynamic frequency adjustment,
> > we do not have direct control over the frequency management so such
> > tests are defunct.
>
> We could just ignore what ips is saying, but maybe we don't want to.
The idea of the test is to set minimum frequency, run a spinner and
check we eventually reach maximum, and then go back to minimum.
ips has a really slow response time, iirc it was on the order of 2
minutes, though my memory may be over exaggerating it, but certainly you
can watch glxgears tick up over many of its 5s iterations.
So that rules it out for BAT selftests as being too slow. In place of
the rps cycle counters and threshold checks, we could investigate the
registers used by gen5_rps_irq_handle:
busy_up = intel_uncore_read(uncore, RCPREVBSYTUPAVG);
busy_down = intel_uncore_read(uncore, RCPREVBSYTDNAVG);
max_avg = intel_uncore_read(uncore, RCBMAXAVG);
min_avg = intel_uncore_read(uncore, RCBMINAVG);
Basic tests like busy spin, do those registers say to clock up etc.
The other test that would be worth seeing if we can do something about is
the "frequency response/scaling", i.e. check that the GPU does run faster
if we ask for a higher frequency. That would require thinking of a nice
way to measure throughput on ilk. Hmm, the blitter should scale with
frequency [one would hope!]. But the blitter includes memory bw, so not
as pure as the CS measurements we have on gen8+.
So with a bit of time, we could have a couple of selftests to confirm
that ilk can detect high/low loads, which may come in handy at some
point. A task for later.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
