I suspect that we should do different things for different pipes..
Spotted by Thomas Jarosh on #intel-gfx freenode.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
With base on EDID timing testing, when we take more than 1s to run
xrandr command, something is wrong.. So add this test for testing the time
we take to read the status of all the connectors from sysfs. It should do
us an average picture of how long we'd take to run xrandr (roughtly 2x
that value).
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
As asked by Daniel Vetter, this is a tech which checks if we can cause
division by zero in kernel by reading the i915_emon_status debugfs
entry repeatably.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Using debugfs facilities for forcewake-related stuff.
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
The crucial trick to reproduce the bug is that we need to have
a decent pile of active bos to retire. Because we unref the bo
after having it moved off the active list, our recursion depth
in fdo bug #42180 is limited by the number of active objects that
can retire at the same time.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42180
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Allow testdisplay to locate the sprite on the screen and potentially
scale it using different crtc width/height vs the source width/height
(determined by the resolution on the target pipe).
Also fix exit, making sure we properly disable all the planes.
Signed-off-by: Jesse Barnes <jbarnes@virtuougseek.org>
The goal of this tool is to be usable as a test for whether something
(suspend/resume, GPU reset, bugs, whatever) may have lost various
required hardware setup specified in the docs.
Reviewed-By: Eugeni Dodonov <eugeni.dodonov@intel.com>
Provokes the forcewake warning when the hangcheck runs and no
one waits for the gpu (and hence holds the dev->struct_mutex).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We actually want to test lru behaviour, so do a bit of work with
the fence before yielding to the next thread (we use twice as many
fences as there are, so yielding always is pretty bad, no matter how
clever our fence stealing).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows intel_gpu_top to run both in statistics-collecting mode
(collecting the per-ring statistics in gnuplot-friendly format) and
ncurses top-like mode at the same time.
It also allows to output the statistics directly to stdout, by using "-o
-", so the results can be parsed directly via a popen() parsing.
If you are using intel_gpu_top as previously (without any command-line
arguments), it should change nothing for you. If you were using its
logging facilities (e.g., the '-o file'), note that the logging will keep
running, but the detailed top-like interface will be on the screen at the
same time.
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
