Ooops. Reported by Paulo. Also add a new testcase for make check to
make sure this actually works.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The goal is here to both: demonstrate a simple usage of render copy with
the possibility to write pngs to visualize what it's doing and to
provide a test bed to port the render copy function to new
architectures.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Let's add a new test that sets a mode, wait for a few vblanks (3) and
then make sure we read 3 identical CRCs.
Some subtests check for various parsing errors.
In the process, improve the debugfs helpers to deal with CRCs.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
If we're really fast we've trying to stop the signal helper again
we somehow race somewhere and it'll never happen. So add a testcase for
this. Since I expect more to come for testsuite tests add a separate
make target for them. Run tests with
$ make check
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This test chekcs our code that enables Package C8+. The environment
requirements for this test are quite complicated:
- The machine needs to be properly configured to reach PC8+ when
possible, which means all the power management policies and device
drivers must be properly configured.
- You need at least one output connected.
- You need the /dev/cpu/0/msr file available.
- You need the /dev/i2c-* files available.
v2: - Many many changes due to the latest review comments and rebase.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Iterate through all valid/invalid crtc/connector combinations. At the
moment only clone configurations are tested as the single output cases
are tested already by testdisplay. Also from combinations where all
connectors are on the same crtc (clone-single-crtc) only those are
tested that are invalid, as I haven't found any machine that supports
these (have to be GT2 with dvo and vga output).
For configurations with one crtc per connector the FBs are per-crtc atm.
Signed-off-by: Imre Deak <imre.deak@intel.com>
This exercises a race in the flink name descruction of the current drm
gem core. When racing a gem close with a gem open the open can sneak
in and cause the kernel to leak the flink name and its reference.
This results in leaked gem objects that won't get reaped even at drm
file close time. On my 2 core/4 threads snb machine this leaks on the
order of 1k objects per second.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This exercise the bug fixed in
commit 94a335dba34ff47cad3d6d0c29b452d43a1be3c8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jul 17 14:51:28 2013 +0200
drm/i915: correctly restore fences with objects attached
For fun I've also added a subtest for the inverse transition.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a test going through all connectors/crtcs/modes/formats painting to
a front FB with CPU or painting to a back FB with CPU and blitting it
to the front FB.
Only formats understood by cairo are supported for now.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
This adds a test to make sure that the execbuffer validation routine is
checking for invalid addresses, single entry overflow, and multi-entry
wrapping overflow.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
basic test to share a BO, add as a udl framebuffer, and call the dirty
ioctl on it so we cause the vmapping to happen
[danvet: Snatched up from Dave's prime branch, ocd name and bikeshed
whitespace a bit.]
Attempt to stress test performing relocations whilst the batch is in the
CPU domain.
A freshly allocated buffer starts in the CPU domain, and the pwrite
should also be performed whilst in the CPU domain and so we should
execute the relocations within the CPU domain. If for any reason one of
those steps should land it in the GTT domain, we take the secondary
precaution of filling the mappable portion of the GATT.
In order to detect whether a relocation fails, we first fill a target
buffer with a sequence of invalid commands that would cause the GPU to
immediate hang, and then attempt to overwrite them with a legal, if
short, batchbuffer using a BLT. Then we come to execute the bo, if the
relocation fail and we either copy across all zeros or garbage, then the
GPU will hang.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is based on tests/gem_partial_pwrite_pread which aims to detect
incoherency between CPU reads and writes to a bo whilst using it as a
source and target for GPU writes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Unfortunately this requires slab poisoning to catch anything :(
Also add a new helper to drmtest to get the available fence count.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
