At least on my old atom i945 they take forever. Also, metric tons of
pipe B underruns while running rcs-flip-vs-panning. No idea why that
happens.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We run flips and vblank waits in parallel, which means the step
for each is the maximum. If we'd switch to an interleaved scheme
(to be able to check the correlation) we'd need to add them instead.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't have a reference value for the vblank counter yet, so
will end up waiting for a long time for the vblank counter to
wrap around again.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's broken since it doesn't take the order the events arrived into
account and so will fall over for longer seq_step values in the vblank
event: Since the flip completes right away, but the vblank later on
they won't have the same timestamp.
For now just give up, we could resurrect this by strictly alternating
between a flip and a vblank wait.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I've blown the conversion in
commit 37e5b318c5dac290611099e2eec21df1e49fa71f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Oct 4 18:42:26 2013 +0200
tests/kms_flip: use igt_assert more
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70332
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some kernels inadvertedly forwarded dpms changes to crtcs connected to
shared encoders even though that specific output wasn't enabled.
Hilarity ensued.
Note that we only have shared encoders on hsw (DP+HDMI) and with sdvo
cards (multi-function encoders).
v2: Do a full OFF->ON->OFF transition to make sure something actually
happens.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On machines with many outputs and many crtcs it takes too long.
So scale the runtime by the number of output combinations we're trying
to light up.
Compensate the test runtime a bit by doubling most subtests' duration.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At least for pipe A/B we should always fail the test if we can't light
up the preferred mode - the kernel should filter out impossible modes
and for our hw pipe A/B are the least constrained.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to be careful to remember that fb-width is not always the same
as hdisplay, since for panning we allocate a larger framebuffer. So fix
up the printfs to use hdisplay/vsisplay since that should be uniform
across the array.
Regression from
commit 919d68901187fa797a9b648fcf87c838fae22fa3
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Aug 29 15:33:53 2013 +0100
kms_flips: Operate on an array of crtc
Buzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68832
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The goal is to flip the same framebuffer on a pair of CRTCs (clone mode)
and check that (a) the flip works in all combinations of workloads, and
(b) that we can hit the desired refresh rate under the simplest, most
ideal of conditions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This should be no functional change as we operate on an array of
crtc[1]. Later we shall test clone mode across a number of crtc.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For machine with split BCS/RCS rings, we also need to test whether we
correctly wait upon outstanding render work before flipping and changing
modes. This should also serve to exercise the ring selection code for
flips.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It's unused. Also most of our tests failed to ask for the right type
of drm fd anyway. So it's imo better to just let them fall over when
they don't get master but want it, like they already do today.
This also allows us to garbage-collect the master parameter to
drm_get_card and associated code.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also sprinkle igt_assert and igt_require over the setup code to clean
up code while at it. To avoid gcc getting upset about unitialized
variables just move them out of main as global data (where they always
get initialized to 0) - gcc can't see through our igt_fixture and
igt_subtest maze properly.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is mostly important to get the SKIP reporting right, but I've
found a few stragglers that wanted to get converted over to the igt
result reporting completely.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mostly a sed job with too manual fixups:
- one case of using _exit instead of exit
- and one case which under some conditions use 77, so convert that
check to an igt_skip.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Requested-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The _block postfix meant to convey that a C statement/block must
follow can be misread as the verb to block. So drop it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Doesn't do more than an if (drmtest_run_test(name)) right now, but
as soon as we get a bit of infrastructure to handle test failures and
skipping, this will get more interesting.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's start by a small set of tests, to eventually consider running
more.
The current list should then be:
gem_mmap
gem_pread_after_blit
gem_ring_sync_loop
gem_ctx_basic
gem_pipe_control_store_loop
gem_storedw_loop_render
gem_storedw_loop_blt
gem_storedw_loop_bsd
gem_render_linear_blits
gem_tiled_blits
gem_cpu_reloc
gem_exec_nop
gem_mmap_gtt
v2 add (Daniel Vetter)
gem_exec_bad_domains
gem_exec_faulting_reloc
gem_flink
gem_reg_read
gem_reloc_overflow
gem_tiling_max_stride
prime_*
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
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>
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>
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>
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>
This is one reason for some of the sporadic kms_flip failures.
One such is https://bugs.freedesktop.org/show_bug.cgi?id=59834.
v2:
- use unsigned long for KDSETMODE/KDGETMODE
- fix passing the parameter to KDGETMODE as it should be by value
- actually testing that it works..
v3:
- don't do an explicit DPMS_ON, only switch to graphics mode.
v4:
- use the newly added drmtest_set_vt_graphics_mode(), which will also
take care of restoring the original mode. (Daniel)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to clear out the error_state. While at it also make sure that
the hang was indeed detected.
Whoever writes the next test to race against gpu hangs should probably
extract these two functions into the drmtest library. Which just one
user that's not really worth it right now.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
flip-vs-bad-tiling tests that page flipping to a Y-tiled buffer returns
an error correctly, rather than triggering kernel BUG for instance.
Create a third fb for this purpose. After the fb has been created,
change its tiling mode to Y. When performing a flip, target this
Y-tiled fb and make sure we get the expected error value.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The flip-vs-panning-vs-hang is just like the regular flip-vs-panning
test, except it also hangs the GPU. This will test whether panning
works after a pending page flip has been cancelled by a GPU reset,
and also whether page flip events get delivered correctly.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Do not use the TEST_HANG flag to determine whether page flip events are
used. Add a new TEST_NOEVENT flag that can be used to disable the use
of events instead.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
autoconf can be configured to not generate a config.h but to give the
defines with command line arguments instead. In this case, there's no
config.h to include.
To work in both cases autoconf adds a HAVE_CONFIG_H define on the command
line to signal there's a config.h to include.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
The flip-vs-modeset-vs-hang test will:
1. simulate a GPU hang
2. exec a nop batch
3. schedule a page flip
4. perform a modeset operation
With the current buggy kernel driver, the modeset operation will
hang indefinitely waiting for the flip to complete. Since the
rings are stopped, that will never happen. The current GPU reset
code doesn't play well with page flips either, so a GPU reset
won't fix things.
Once the kernel driver is fixed, the eventual GPU reset will
save the day.
The nop batch buffer is required only because the kernel can't
currently detect GPU hangs, unless there is at least one user
submitted request pending.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
