Since we don't execute any subtests, using igt_exit leads to
inconsistent behaviour. In the future, this may be converted.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73641
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fix usage of shared variable LOCAL_PATH in deferred variable expansion area.
In Makefile language, rule and dependency definitions use immediate
expansions of variables, so they get expanded as soon as the rule is
created (1st pass). Rule implementation (a.k.a recipe) use deferred
expansion (2nd pass).
Android effectively makes all Android.mk files a single makefile by
including them all in a big tree from the toplevel makefile. The rules
are all evaluated in the first pass and targets are generated. Then the
2nd pass happens and the required target's recipes are run. At this
point, LOCAL_PATH has been assigned the value from the last evaluated
Android.mk in the 1st phase that defined LOCAL_PATH (most Android.mk use
this variable). In my particular case, it was the bootloader's
Android.mk that was evaluated last and had defined LOCAL_PATH to it's
path. The errors are rather misleading due to it looking like a bug in
another module's Android.mk rather than this one :)
Basically, if you want to use a variable that any other Android.mk
defines, then you can only use it in an immediate expansion context,
not a deferred expansion context as it will likely be re-defined by
the time the 2nd pass happens.
This patch stores it in a unique variable that should not be being
used by other Android.mk files. An alternative fix would be to use $@
and $< as the files in question are target and dependency, but I never
like using those as they can easily break if dependencies are added
etc. I prefer variable to be explicitly named to make them obvious.
See gnu make manual for explanation of deferred vs immediate
expansion of variables :
http://www.gnu.org/software/make/manual/make.html#Reading-Makefiles
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Robert Beckett <robert.beckett@intel.com>
Run all relevant tests on all rings.
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Split context related tests from non-context ones
and cleanup the naming.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's pure luck that nv can detile some of the intel layouts since one
of the video MC formats matches it. Since we can't possible fix this
comment the test out.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73538
Acked-by: Maarten Lankhorst <bugs@mblankhorst.nl>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Existing code was trying to be too clever and wasn't properly emitting
the high dword, or the correct length.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
kms_cursor_crc and kms_fbc_crc don't need glib.h. This was just some
copy-paste error on my part.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
The goal of the test is to confirm that gt_cur_freq_mhz can be forced
to the boundaries of the frequency range by collapsing gt_min_freq_mhz
and gt_max_freq_mhz to the target value. But we miss testing the upper
end of the range by targetting the current value of max after it has
been set equal to min. So fix by targetting orginal max instead of
current max.
This correction exposes a problem in setfreq where min is always set
to target before max, which should fail if the target value is greater
than max. So fix that too.
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
do_writeval now always checks the return value, whether we expect
success or a specific error. Also add new macro writeval_inval to
simplify repeated use of do_writeval to test for EINVAL return code.
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bionic C library may not re-read a buffered, read-only file which
results in failure to monitor changes in gt_cur_freq_mhz.
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
target_bo->offset was just being used to verify that the batch
submission worked and fortunately was not being relied upon for any
subsequent conditions. However, address 0 is valid and so the assertion
itself was bogus as it is possible (almost assured with full-ppgtt) for
the target_bo to be located at address 0.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72984
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The purpose of this test is to exercise the userspace latency hogs
reported by Arjan van de Ven. He found some applications blocked the
device by stalling on the GPU inside the pagefault handler.
Oops. We should be a bit more consistent with which verb form we're
picking. tile,tiled,tiling is even worse ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
NDEBUG is defined by default in Android and causes assert(x) to be
defined as void(x). This change ensures that asserts work as
expected in tools.
This flag is already inside tests/Android.mk
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Devon Davies <devon.davies@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
This tool only supports ILK. I take the fact that nobody has felt the
need to update for later platform a sign it's not very useful.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Also intel_iosf_read() does not exist, and would need a bit more
arguments.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
The GEN6_INSTDONE_1 and GEN6_INSTDONE_2 registers are just the old
INSTDONE_I965 and INSTDONE_1 registers but renamed. Let's use the old
names (this is what the kernel does).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
This is the only place where they are used and we've even started using
1 << n constants with gen 7.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
That's how the registers are named in the kernel defines.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
... in case we can't find a compatible mode. We already have
config[0], we can't return without freeing it first.
Caught by Valgrind.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
The kms_flip program calls kmstest_get_connector_config, which returns
a struct containing some allocated variables, including a pointer to
the CRTC. The problem is that we copy the values returned by this
structure to the test_output struct, but we ignore the CRTC pointer.
So free the CRTC pointer instead of leaking it.
Caught by Valgrind.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
4 pieces of code were looking very similar. Let's factor out a common
function in the not so unlikely case we need to tweak that code.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
I tried to get fancy before, but ended up pushing something which I
didn't test. Keep the thing simple and stupid, and just make it work.
Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
cairo_t is the short lived drawing context, whereas cairo_surface_t is
the heavyweight object that persists and is also tied to underlying GEM
objects. So make the kmstest API reflect the different weights and fix
the lifetime and underlying object reference leaks.
Based on the fix by Paulo Zanoni.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
QA reported a failure that I believe happened because we couldn't
become DRM master, so add code that checks for this and prints a nice
error message.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Also, skip the compilation of pm_lpsp in Android (uses Cairo)
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With Full PPGTT, each new fd creates a new context and thus a new
PPGTT, so we have to reduce the number of simultaneous fds or face
OOM problems. For every new PPGTT, its PDEs are stored in the GGTT
which imposes a limit of 1024 new contexts. We want to leave at
least 1/4 of the GGTT available for "important" stuff like scanout
buffers, so never open more than 768 fds.
v2: Unconditionally use the lower limit, as suggested by Daniel
Vetter
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use own copy of gem_quiescent_gpu() so that test still works
if it gets changed. Further improve the test by posting a batch
to rings in reverse order.
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
