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>
I accidentally pushed
commit a08d62257dbdc8f4d3f5e655e0ba7bd192af37ff
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Thu May 23 11:03:25 2013 -0700
quick_dump: Add CCID
before I was ready, in order to get the mmio fix in. This fixes a parse
error in quick_dump.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
commit 16e44f5499e1754dfb10fc62b22675f5aa6ac781
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Apr 3 00:22:41 2013 +0200
lib: fixup register access on gen2/3
THis fix was incorrect for a few reasons:
1. It didn't reflect the state in mmio_data.safe
2. It skipped forcewake on gen6+ which is both incorrect and
unnecessary (for gen<6).
3. It had 2 goto done, the second of which was impossible to hit.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
We are changing the cwd, so we just need the relative patch from the
root for the kernel git repo. This allows the script to work from
anywhere.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Add a double buffer and a single buffer version of the above sequence,
to check if the modeset does a DPMS ON.
Tested on IVB, with and without the relevant kernel fix, got the
expected results.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently when exiting with error, we'll get stuck in a DPMS OFF state
if the error happens while we have DPMS OFF set in the test sequence.
This happens even though we switch back to text mode at exit. This might
be a bug in itself to be fixed later, but in any case we want a working
console, so do an explicit DPMS ON.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The rest of the tool suite that uses python already uses python3.
The tool configure requires python >= 3 (which is confusing because of
the no backward compat problem).
The world is slowly moving to python3.
Converted with 2to3.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Currently if we come across several sites that say that a specific
workaround is implemented for a platform, we just add the platform
several times to the list. eg.
WaFbcDisableDpfcClockGating: ivb, hsw, ivb, hsw
This patch prevent that by only adding the plaform if it's not already
there.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
