[igt-dev] [PATCH i-g-t] tests/perf_pmu: Compare against requested freq in frequency subtest

[Dixit, Ashutosh]

On Tue, 08 Nov 2022 17:49:04 -0800, Dixit, Ashutosh wrote:
>
> > Is it then expected to respect the 300MHz max in this case? Or if it can't,
> > should it be reflected in the sysfs readback?
>
> The max is set to 300 MHz but is not respected. So the sysfs readback shows
> max as 300 MHz but actual requested freq is higher. The flow is that i915
> sets min/max using h2g. GuC FW validates the parameters in the top-half and
> returns success (which results in max freq being set in i915 to 300 MHz)
> but the actual min/max freq change in PCODE is done later in the
> bottom-half because of which the delay is needed.
>
> Though Vinay we never read the max freq back from FW, that is we call
> intel_rps_get_max_frequency and not intel_guc_slpc_get_max_freq when
> displaying in sysfs. That is we display i915 cached values rather than
> interrogate FW, assuming that FW min/max values are same as the cached
> values. I can add a couple more prints and see what actual FW values are.

So I submitted this patch which queries freq's from FW rather than
displaying cached values:

https://patchwork.freedesktop.org/series/110685/

But here also we see the same min/max freq's:

https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110685v1/bat-dg2-11/igt@perf_pmu@frequency.html

So this means freq's set in FW match the cached values in i915.

(Compare the above results against:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8071/bat-dg2-11/igt@perf_pmu@frequency.html
which uses cached values).

So again we are back to the earlier conclusion that "max is set to 300 MHz
but is not respected".

So finally let's think about whether v1 or v2 of the IGT patch makes sense:

https://patchwork.freedesktop.org/series/110574/

Thanks.
--
Ashutosh