This changes how we compute the variance. We want an unbiased variance
when reasoning about a sample.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Paulo suggested that we could short-circuit the search for a good
divider if we find a 0 deviation of the DCO frequency from the central
frequency.
Out of the 373 test frequencies, 34 hit that fast path.
Suggested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Paulo noticed that, because we were only comparing positive deviations
with positive deviations and negative deviations with negative
deviations, we weren't actually always using the absolute minimal
deviation at all.
This improves the average deviation across all tested frequencies (373):
before: average deviation: 215.13
after: average deviation: 194.47
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Follow Paulo's comment on the corresponding kernel patch.
This means we also have to move the break when we have cycled through
the even dividers as well.
This improves the number of even dividers used across the tested
frequencies (373) (at the expense of a slightly worse average deviation,
but "even dividers take precedence over a lower deviation".
before:
even/odd dividers: 338/35
average deviation: 206.52
after:
even/odd dividers: 363/10
average deviation: 215.13
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
It's interesting to watch the effect of some algorithm tweaks on the
average deviation between the central freq and the dco freq. A metric
we'd like to minimize.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
The CRC debug interface is a bit more than a simple textual file in
debugfs as there are a small command language to control what we want
from them.
This tool starts, slowly, by allowing us to dump the pipe CRCs whenever
we want. It can be handy to check what is the current CRC when we reach
a certain state on the screen (when using --interactive-debug for
instance) against a known CRC.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
The tool I used to generate that list doesn't support expanding the list
of registers when dealing with something like CUR_WM_A_*. Expand it by
hand for now (tm).
Remove CUR_PAL_${pipe}_* for the same reason (and because it's not very
useful to have).
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
With the recent developments, add scaler and NV12 registers to the dump.
Also add the cursor registers that were missing in the first batch.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
When -lrt was added, it was missing a '\' at the end of line. Add it.
Cc: Tim Gore <tim.gore@intel.com>
Cc: Thomas Wood <thomas.wood@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
We might as well verify that we have a semblance of all being in order
by making sure the DCO frequency is within the expected bounds.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
I had various problems (infinite loops, unable to compute dividers for
certain frequencies) after implementing a BSpec update. Much easier to
debug that in userspace.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Global variable names should reflect the fact that they are indeed
global, and at the very least they should not be as short as just
"mmio". Rename mmio to igt_global_mmio.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Three Tools for the Elven-kings under the sky,
Seven for the Dwarf-lords in their halls of stone,
Nine for Mortal Men doomed to die,
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
One Tool to rule them all, One Tool to find them,
One Tool to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
J.R.R. Tolkien's epigraph to The Lord of The Tools
| sed 's/Ring/Tool/g'
Introduce intel_reg as the one Intel graphics register multitool to
replace intel_reg_read, intel_reg_write, intel_iosf_sb_read,
intel_iosf_sb_write, intel_vga_read, intel_vga_write, intel_reg_dumper,
intel_reg_snapshot, and quick_dump.py.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Attempting to build IGT on linux without libunwind fails
due to tools/quick_dump not linking the rt library,
causing an undefined symbol error for clock_gettime.
Adding -lrt to the list of libraries in Makefile.am fixes
this.
Signed-off-by: Tim Gore <tim.gore@intel.com>
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
../../lib/.libs/libintel_tools.a(igt_core.o): In function `print_backtrace':
intel-gpu-tools/lib/igt_core.c:981: undefined reference to `_Ux86_64_getcontext'
intel-gpu-tools/lib/igt_core.c:982: undefined reference to `_ULx86_64_init_local'
intel-gpu-tools/lib/igt_core.c:983: undefined reference to `_ULx86_64_step'
intel-gpu-tools/lib/igt_core.c:987: undefined reference to `_ULx86_64_get_proc_name'
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Every time _chipset.so has undefined symbols we fail to notice it
at build time and then get to wonder why quick_dump fails to actually
work. Pass -Wl,--no-undefined to the linker to get a build time error
instead of the current runtime error.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
- decode the register for BXT too
- decode interlace on VLV/CHV too
- don't decode rotation and bpc on platforms where these fields are not defined
Signed-off-by: Imre Deak <imre.deak@intel.com>
Add an optional dependency on libunwind to print stack traces when a
test assertion fails.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
These two registers contains the 48bit fault address.
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Add decodings for FAULT_REG
v2: fix fault encodings and ignore addr type for gen8+ (Michel)
fix engine mask
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
The watermark registers on the gmch platform are a bit of a mess. Add
a tool to make some sense of them. While at it decode the ilk-bdw wm
registers as well. SKL+ is left out for now since it's a very different
beast.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Some IOSF SB units ogranize their registers in a pecualiar way. Even
though the registers are 32 bits wide, the register offsets only
increment by one when going from one register to the next. Correctly
deal with this when dumping several consecutive registers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Add a command line option '-c <count>' that can be used to read set of
consecutive registers without having to specify the offset for each of
them.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Replace the silly strcasecmp() if ladder with and array that maps the
unit names to port numbers. And keep the thing sorted so we can do
the lookup with bsearch() for extra speed :)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
intel_dpio_{read,write} as redundant as intel_iosf_sb_{read,write}
handle the same task.
The difference between the tools was the opcode used to read/write the
registers, but with DPIO both opcodes work just fine, so there's no need
for both sets of tools.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
