[igt-dev] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Chris Wilson]

Quoting Antonio Argenziano (2018-03-09 19:15:45)
> 
> 
> On 08/03/18 17:03, Chris Wilson wrote:
> > Quoting Antonio Argenziano (2018-03-09 00:45:42)
> >>
> >>
> >> On 08/03/18 09:13, Chris Wilson wrote:
> >>> Exercise some new API that allows applications to request that
> >>> individual contexts are executed within a desired frequency range.
> >>>
> >>> v2: Split single/continuous set_freq subtests
> >>>
> >>> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >>> Cc: Paneri, Praveen <praveen.paneri at intel.com>
> >>> Cc: Kamble, Sagar A <sagar.a.kamble at intel.com>
> >>> Cc: Antonio Argenziano <antonio.argenziano at intel.com>
> >>> ---
> >>>    tests/Makefile.am      |   1 +
> >>>    tests/Makefile.sources |   1 +
> >>>    tests/gem_ctx_freq.c   | 604 +++++++++++++++++++++++++++++++++++++++++++++++++
> >>>    tests/meson.build      |   1 +
> >>>    4 files changed, 607 insertions(+)
> >>>    create mode 100644 tests/gem_ctx_freq.c
> >>>
> >>
> 
> >>> +             uint32_t cur, discard;
> >>> +
> >>> +             set_freq(fd, ctx, freq, freq);
> >>> +             get_freq(fd, ctx, &cur, &discard);
> >>
> >> igt_assert_eq(freq, cur)?
> > 
> > Not quite. The trick is that the interface is not strictly idempotent,
> > since we pass in MHz, the driver converts that into freq bins and spits
> > it back out to the nearest MHz. So cur is not strictly freq, it just
> > happens that 50MHz is the bin size on gen9.
> > 
> > The idea here is that we grab the adjusted freq from the driver to
> > validate with.
> 
> I see, can we enforce a tolerance? It feels like we are trusting the 
> kernel too much, but if that is the only thing we can do...

for (i = min; i <= max; i++)
	igt_assert(min <= set_and_fetch_freq(i) <= max);

I don't think we want to constrain the ABI any more than that.
But adding that level of check seems ok.

The behaviour is we ask the kernel for a range, the kernel tells us what
range it can provide based on the request. Then we expect that the
kernel upholds that contract. (Except where we make a conflicting
contract with another party, either parallel execution or sysadmin
override.)

Binding ourselves into a tighter contract feels overly prescriptive and
not flexible enough to weasel our way out of bad situations in future.
-Chris