They simply take forever with the current kernel implementation. And
since everyone switched over to the event based interface I don't see
much incentive to try to fix that.
So just disable them.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The intel_reg_dumper tool reads a lot of display registers. If we
don't turn on the power well, dmesg will get flooded with tons of
messages about unclaimed registers. So here we enable the "Debug"
power well register and then restore its state later. It's impossible
to guarantee that other things won't mess with the debug register
between our put and get calls, but at least we're trying our best to
keep things working fine, and it's the debug register anyway.
As far as I know, nothing else uses the Debug register for anything,
so we should be safe for now.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
In the atexit handler, we attempt to quiesce the GPU. This involves
opening a fd - which will fail if the test is not being run as root and
will obliterate the test status and pollute the output.
We need to be careful in case other devices grow an error file in the
future. The first step here is just to check the minor that corresponds
with the debugfs path found for the device
As /sys/class/drm/cardX/error is a new interface for 3.11, we need to be
quiet when it does not exist or else we upset the automated tests.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66533
Since these two tests exercise a working set larger than aperture, they
require stalls which are prone to being interrupted - so interrupt them
and check that everything still works.
Test both debugfs and sysfs error_state interfaces.
v2: sysfs error_state not mandatory
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Update sysfs file name.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In preparation to have sysfs entries used in scripts
rename to more specific name.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add the names of all VLV DPIO registers.
v2: Use the third element to signal DPIO registers, and split
the code changes to a separate patch
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Add a small comment about what the elements in the register
tuple mean.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Repurpose the (currently unused) third element in the register
definition tuple to indicate the type of the register. 'DPIO'
is the only special register type for now.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Accidentally replaced the intel_copy_bo() with the set_bo() in the
"overwrite-source" in 4fd34977aff60f58cd955eb9c2d568d5fb824611 when
clearly I wanted to simply add the calls to set_bo() first.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Accidentally left in the hack to run the
"overwrite-source-interruptible" for only one loop, used whilst testing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Hiding the initial set_bo() required for the "overwrite-source" tests
lead to a nice bit of hilarity as I missed repeating the initialisation
for the multiple loops of the interruptible version of
"overwrite-source".
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Daniel preferred to keep the old tests intact lest we accidentally break
them, and to add the new interruptible tests as new subtests.
In the process also make sure the GPU is idle before starting each loop.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to exercise the bug behind:
commit 22fd5ca947b58901927d100d2b1aa0f1672b3435
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jun 28 16:54:08 2013 +0100
drm/i915: Only clear write-domains after a successful wait-seqno
we need to check for concurrent access with the potential to be
interrupted by a signal. The framework for doing so is already in place,
so just enable it and repeat the tests for longer to give better chance
of being interrupted at just the wrong moment.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I'd been working under the falsehood that we would always generate an
error for an invalid reloc->target_handle before reserving any object.
However, only the execlist is checked up front for validity before
reservation so ENOSPC is a genuine error condition raised by the test.
Fix it so that we stop reporting that limit as a test failure.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65391
Limit the broken handles to UINT32_MAX-4096 so that we can be sure that
they do not alias with a valid handle.
References: https://bugs.freedesktop.org/show_bug.cgi?id=65391
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We may fail to set a mode if it fails some hidden constraints, such as
bandwidth on the third pipe. This is expected, so skip testing such
modes.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66111
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Certain modes may not be supported by certain combinations of pipes.
This is impossible to determine upfront, and we await an atomic
modesetting query operation. In the meantime, if we fail to set a mode,
just skip that test.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66000
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>
Factor out parts that will be used by an upcoming patch adding
kmstest_create_fb2.
Also call the fb paint functions directly, there is not much
point in passing a function pointer for that.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
This is used by multiple test cases, so make it shared.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
These are used by multiple test cases, so make them shared.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
At DDX commit Chris mentioned the tendency we have of finding out more
PCI IDs only when users report. So Let's add all new reserved Haswell IDs.
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=63701
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
When publishing first HSW ids we weren't allowed to use "GT3" codname.
But this is the correct codname and Mesa is using it already.
So to avoid people getting confused why in Mesa it is called GT3 and here
it is called GT2_PLUS let's fix this name in a standard and correct way.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
What this test is interested in is the handling of the LUT for very
large arrays, irrespective of whether such batch are actually
executable. So adjust the pass/fail checks to be explicit in the error
they are looking for, so that we do not conflate memory/aperture
pressure as a failure in the LUT API.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65391
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64270
v2:
- Make sure also that the GPU is idle at start and error exit of any
test using drm_open_any(). (Daniel)
v3:
- actually call gem_quiescent_gpu() at exit
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
