Needed by an upcoming patch where we want to wait for an event without
starting a new round of test run.
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Move the panning to a more logical place where the rest of the test
steps are performed. As Daniel Vetter pointed it out, the proper place
is _after_ the flip command is sent, so that fb_set_base correctly waits
for any outstanding flip. So move the function between the flip and the
dpms/modeset off calls.
Signed-off-by: Imre Deak <imre.deak@intel.com>
We will need these in event handlers, so store them where the handlers
have access to them.
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
For better readability and to prepare for the upcoming patch marking
pending flip events with a flag.
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The intent for the time limit seems to be 2ms, but the current condition
will result in a 1s limit and makes the check against tv_usec redundant.
Fix the condition to check for a 2ms limit.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Though the FBs will be freed implicitly at process exit, with the
growing number of test cases it's probably better not to let them
accumulate and free them as soon as we can.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want -EBUSY for a pending flip and -EINVAL if the pipe is off
(either dpms off or completely off). With the small exception that
someone thought it would be funny to return -EBUSY when the crtc is
fully off.
This catches parallel access to bo->virtual causing sigbus
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: applied some bikeshed
- changed prefix from drm_ to gem_, it's a kernel gem test
- added autohell magic to link with pthreads
- .gitignore entry
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Yell if it's wrong.
For some odd reason this blows up on my snb. And always on the same
o->count frame on the 2nd crtc ... And we have to thank the hpd poll
helper for that. Comment explaining this added, also made the error
non-fatal.
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>
Needs a bit more relaxed select timeout to work (which is not
required when testing dummy_load vs. dpms, since the dpms forces the
sync, not the select timeout).
Since panning with set_crtc is synchronous, we need to stall for any
outstanding pageflips. This new testcase exercise that code. Unfortunately
we still need eyes to check whether we don't loose the offset :(
- don't yell around about dropped frames on tv connectors (and explain
why in a comment)
- wait a bit when using a test config that checks for dropped frames before
starting. Also allow for 1% of fudge, this makes it reliably work
- make the dummy load more variable, took too long on older machines.
We're suspecting that something is fishy with the event deliver/vblank
timestamp handling on gmch platforms. Unfortunately, this isn't it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Each mode line has a number just like '[i]'. So we can only test the specified mode with giving the number of mode to '-o' parameter.
Signed-off-by: Yi Sun <yi.sun@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
