As we require a pipe enabled to generate vblanks, the first step is to
then to check that pipe 0 is active or else skip the test.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Check that the more obvious userspace error conditions are handled by
the kernel, ideally without loss of data. These include nonblocking
waits, passing invalid buffers and passing buffers of the incorrect
length.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Here is a cheap way for this test to give consistent results. This
doesn't change the usefulness of this test, hopefully.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85270
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
gem_gpgpu_fill was added in commit 4ec8479 (tests: Add gem_gpgpu_fill),
but wasn't added to .gitignore.
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
This is simply a copy of gem_media_fill but using new
GPGPU fill operation.
v2: Use general fill func pointer.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
This test will not run on Android as the coreu service
remains running even after the android system is stopped.
Coreu is a client of drm and when the test finds this it
fails an assert.
Coreu is started by the init process and there is no
tidy, non invasive way to stop it (init just restarts it).
Coreu isn't doing anything and would not be expected to
interfere with this test. In addition, all the other
igt tests just rely on the user/test script to ensure
that there are no other drm clients, so this test can
do the same. On Android we must rely on coreu being
dormant when this test runs.
Signed-off-by: Tim Gore <tim.gore@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
kms_pwrite_crc was recently added and requires cairo, so
add this to the list of tests to exclude if cairo is not
avaiable
Signed-off-by: Tim Gore <tim.gore@intel.com>
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
If we wait for one vblank, we may end up returning almost immediately,
so trying to assert anything but >0 about the minimum duration is
bogus.
Instead wait for two vblanks and then we can assert that we should have
be blocked for at least one frame. And move the upper bound to a little
over two frames to match.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79050
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
gem_ring_sync_copy uses a lot of memory and gets OOM killed on smaller
systems (eg android devices). Most of the allocation is for "busy work"
to keep the render rings busy and for this we can just re-use the same
few buffers over and over. This enables the test to be run on low end
devices.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Tim Gore <tim.gore@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
The problem is that this causes writes to registers, and if the pipe
is off they might go nowhere (e.g. when runtime pm is enabled).
Furthermore we can only really check once the modeset setup is done,
but again most tests set up the CRC structure before calling
igt_commit and friends. We could add crc restore support to the
kernel's rpm code, but that will end up being rather invasive and
fragile hard-to-test code.
Now originally this was needed back when CRC support wasn't available
everywhere. But that's fixed now.
So given all this just drop that sanity check and make sure that we
only touch the debugfs file (and so the hw state) when we know the
pipe is running in the desired configuration.
A complementary kernel patch will try to catch offenders by returning
-EIO if the pipe is off.
v2: Forgot to git add one hunk.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86092
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
drm_open_any keeps a buffer handle around for the cleanup sync work,
so we can only grab the buffer count after the latst drm_open_any
call. Otherwise we'll detect a fake leak.
This broke in
commit 2f2c491cf3167befe7c79e4b17afb4f6284dfc84
Author: Mika Kuoppala <mika.kuoppala@intel.com>
Date: Fri Mar 28 10:52:46 2014 +0200
lib/drmtest: don't dup quiescent fd
since that additional open drm fd keeps a gem object for the default
context around. Hence why this also only blows up on gen6+ - earlier
platforms don't have hw context support.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79821
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This has the upside that we'll never forget to add it to thrashing
tests. But we'll also never miss to move it when adding basic
functionality tests to existing binaries. Chris already started this
refining work in e.g.
commit d77eda6614a1955717f224be023dedf74eb7735d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Nov 14 07:45:40 2014 +0000
igt/gem_linear_blits: Require that we do the full test
by moving igt_skip_on_simulation into subtests.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
More in line with the usual igt pattern and simplifies the code -
every called just wrapped it in igt_require.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This triggers a device suspended WARN in the kernel in
gen6_ggtt_insert_entries() while calling the GEM pwrite ioctl.
The sequence is suggested by Daniel.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a test to verify that pwriting to a future scanout buffer works
correctly. The specific problem occurs when the buffer is already
UC/WT before the pwrite, not the current scanout buffer, and not
currently in the CPU write domain. With the buggy kernel no clflush
will be performed after the pwrite, and hence we end up with cache
dirt on the display.
The problem only affects LLC platforms (non-LLC would clflush anyway
after pwrite), but we can let the test run on all platforms.
v2: Fix typos in commit message and add to .gitignore
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
kms_flip/nonblocking-read will block indefinitely if it fails, so
introduce a timeout to indicate test failure.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85718
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
The command parser's batch_len optimization causes the parser to
reject this batch as not having an MI_BATCH_BUFFER_END because
the length was not set correctly.
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The size of the batch buffer passed to the kernel is significantly
larger than the size of the batch buffer passed to the function. A
proposed optimization as part of the batch copy kernel series is to
use batch_len for the copy and parse operations, which leads to a
false "batch without MI_BATCH_BUFFER_END" failure for this test.
To fix this, modify the test to set batch_start_offset and batch_len
such that they define the range of actual commands in the batch,
including a few of the surrounding nops for alignment purposes.
v2: update batch_start_offset as well
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
TESTS_scripts was accidentally removed from EXTRA_DIST in commit 685e577
(Move library selftests to lib/tests).
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
to see if one can fool hangcheck by keeping non hanging
ring busy
v2: break from loop instead of return (Daniel Vetter)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
The optopt variable is not set if an invalid long option is used, so
check the current option character instead.
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
This test has a few checks that batch buffer addresses in the error
state match the expected address for the userspace supplied batch.
But the batch buffer copy piece of the command parser means that
the logged addresses are actually _supposed_ to be different. So
skip just those checks.
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit c45216b26d223ffd7f68c5794870214445a64b5c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Nov 4 07:30:57 2014 +0000
igt/gem_tiled_wb: Exercise CPU mmaps with swizzling
brought along a few interlopers.
This exercises the the extended get_tiling ioctl in order to determine
proper swizzling for direct access to objects through WB.
Userspace cannot handle bit17 swizzling through wc mmaps (because bit17
requires swizzling based on the actual physical address of the page -
which is unknown to userspace) and so we need an extended get_tiling
ioctl to report the actual as well as the logical swizzling on an
object.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fix distcheck issues introduced by commit 685e577 (Move library
selftests to lib/tests).
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
This seems to have been accidentally disabled in
commit 982f7eb238a0898c456e0574dee7c4507738d75f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Aug 29 15:19:57 2014 +0100
Prepare for 64bit relocation addresses
Apparently no one noticed.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This is a regression from
4306538d1d3f60877866c39c9ca953cc5e541dae is the first bad commit
commit 4306538d1d3f60877866c39c9ca953cc5e541dae
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
AuthorDate: Thu Oct 2 11:18:20 2014 +0200
Commit: Daniel Vetter <daniel.vetter@ffwll.ch>
CommitDate: Thu Oct 2 11:34:55 2014 +0200
tests: Sprinkle missing igt_exit() where needed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85582
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Again they're not really igt testcases so are in the way of
running spatch unconditionally. Move them someplace else.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
They're now igt tests, and so if you blindly run lib/igt.cocci with
spatch on tests/*c they get mangled. Move them away, but still keep
them as noinst targets.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
We were having a problem where the system-suspend test was passing,
but then the next test - gem-execbuf-stress - was failing because of
bugs caused by the suspend subtest. So add a single test that emulates
the same problem, and another test that just sets a mode after resume.
This way, we should be reproducing the problem even if you don't run
the tests in the order they are defined.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
