Age | Commit message (Collapse) | Author |
|
To have a more accurate idea about any suspend/resume issues we can
perform the s/r until various phases in the s/r sequence. This way we
can isolate the given problem as being a device driver, kernel core or
BIOS related issue. Actual subtests using these new s/r phases will be
added as follow-up.
While at it also add the freeze suspend target, it's something we also
would need to test.
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
An interesting complication arises using machines with different
aperture sizes and special execbuf modes like secure dispatch which uses
the smaller global aperture. In order to avoid false positives from the
test, we need to make sure that the secure dispatch is capable of being
run before submitting.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88392
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Rather than guestimating a workload that should take a certain amount of
time, use a sigitimer to terminate a batch (and so complete the wait)
after an exact amount of time. And in the process expand testing to
cover multiple rings and hangcheck.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
|
|
The test is producing a lot of CI noise.
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
|
|
Reported-by: https://jenkins.freedesktop.org/job/IGT-ARM/210/
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This is superseded by vgem_basic/unload
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
intel_reg_read and intel_reg_dumper are no more. Switch over to intel_reg.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Source drm_lib.sh instead of drm_getopt.sh so that we get the
"executing", and "exiting" breadcrumbs in dmesg.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Leave the normal "executing" and "exiting" breadcrumbs into dmesg when
running the test.
v2: s/$1/$@/ (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
debugfs_wedged and drm_lib.sh are already using bashism so switch over
to using #!/bin/bash instead of #!/bin/sh.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
See tests/intel-ci/README for rationale and explanation.
v2: Use the current BAT set for fast-feedback.testlist first
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
It's more readable like this, and with the ifs it was a completely
separate test anyway.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
If we want to advance the seqno, we need to coordinate with all possible
users. The kernel doesn't want to do that for a lowlevel debug feature,
so it's up to userspace not to shoot itself in the foot.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
make_busy() already existed!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This is a test for the issue exposed by 97888, we perform a busy
bo update followed by a cursor update.
The page flip and cursor update should complete without hanging,
and the new fb should not be flipped yet as a result of the cursor
update.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
This reverts commit e4a1727efa617e32428c7e7c59abbb08cc97e16f.
This hack should no longer be needed with the previous commit applied.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
Since vgem doesn't have any callbacks from shmemfs to its, we don't need
to keep the module around to service a pagefault when only using the
shmemfs facilities. Adjust the test to try to unload and check the mmap
for access.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Suggested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Only try removing intel_ips if it's actually loaded, and let the errors
through to the logs if removal fails.
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Only try removing snd_hda_intel if it's actually loaded, and let the
errors through to the logs if removal fails. This is a clue if i915
removal fails later.
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add a helper for checking whether a module is reloaded, using
lsmod. Also make the grep stricter than before.
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Now will even more evilness.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
igt_subtest_group { /* to the request */ }
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97934
|
|
We found a bug where a dmabuf did not keep the module alive (and so when
i915 tried to use it later, it exploded).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Allowing modeset may prevent the test case from failing in case the atomic
check phase finds the userspace doesn't allow modeset for the commit and
returns -EINVAL. A real case is to run the test case on imx-drm which
requires a full modeset when we change an active plane's configuration,
e.g., pixel format and stride.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Marius Vlad <marius.c.vlad@intel.com>
Cc: Micah Fedke <micah.fedke@collabora.com>
Cc: Daniel Stone <daniels@collabora.com>
Signed-off-by: Liu Ying <gnuiyl@gmail.com>
|
|
This patch exposes atomic commit flags to crtc_commit_atomic()
so that users of the macro may control the flags.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Marius Vlad <marius.c.vlad@intel.com>
Cc: Micah Fedke <micah.fedke@collabora.com>
Cc: Daniel Stone <daniels@collabora.com>
Signed-off-by: Liu Ying <gnuiyl@gmail.com>
|
|
Just to tidy a discrepancy where doing the compare using the GTT (i.e. a
readback) is now faster than setting the contents initially (as the
readback only checks one pixel per page, do the same for setting the
object).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
vgem provides WC mmap on its dmabufs, so reading and comparing these is
slow. We can employ a similar w/a to the other WC mmaps (i.e. mmap__gtt
or mmap__wc) and only check one pixel per page. This will speed up those
tests, but I don't know if it makes detecting coherency issues more or
less likely. :|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Otherwise we inherit the bufmgr and fd across the fork, try to clean it
up in the child (affecting the parent's device), then try to clean it up
in the parent (triggering warns).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
commit 4337091f6af6 moved the initialisation of the pollfd into the
child, forgetting that it was also used in the parent as a sanity check.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97885
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Commit to a mode before querying it.
Tested-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=97172
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
The essence of the basic test is that neither the cursor nor the
nonblocking flip stall the application of the next.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
And replace with basic testing that rendering first is detected as being
busy, and then will automatically retire.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Execute the test in parallel in order to exercise a failure condition in
reordering requests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Min, average, exclude the post-exec sync time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Similar to benchmarks/gem_latency, but looking more at the dispatch cost
rather than wakeup cost, and looking for inter-engine costs. Still
probably better as a perf test.
ivb over the years:
IGT-Version: 1.16-gebee919 (x86_64) (Linux: 3.10-3-amd64 x86_64)
render: dispatch latency: 50.90, execution latency: 57.29 (target 4.64)
bsd: dispatch latency: 41.45, execution latency: 41.43 (target 4.75)
blt: dispatch latency: 41.02, execution latency: 41.00 (target 4.99)
IGT-Version: 1.16-gebee919 (x86_64) (Linux: 4.8.0-rc5+ x86_64)
render: dispatch latency: 12.61, execution latency: 15.44 (target 1.71)
bsd: dispatch latency: 12.08, execution latency: 12.07 (target 1.80)
blt: dispatch latency: 12.59, execution latency: 12.58 (target 1.85)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Add a heavier batch of (1M nops) in order to stress a context switch
onto a busy engine. (The immediate goal is try and fill the GuC
workqueue, but it seems like the lightweight test was enough anyway, as
well as gem_exec_nop.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The ideal execution time cannot be faster than the fastest ring! If all
other rings were infinitely fast, the seed would be max/nengine. Given
each is finite, this puts a floor on the ideal execution time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In an ideal world, we should be able to execute on every engine in
parallel and the single limiting factor would be how fast the GPU can
execute. Due to the serialisation in execbuf, we would lockstep with
execution to the slowest engine and so would execute the same number of
cycles on each. However in CI, we are limited by how fast the driver is,
particularly under invasive debugging. This makes asserting that the
average time == max/nengine impossible, and reveals that the assertion is
impossible to meet under general condition. It's an impractical
regression test. Therefore we relax the assertion to only detect should
something critically fail. Worst case behaviour is presumed that each
ring runs sequentially, and so running N rings in parallel should take no
longer than running N rings serially. (Pathologically it can be even
slower if no batching on the rings occur).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This was already tested by kms_atomic when passing object id's as
properties to set.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
On skylake there's a add_all_affected_planes call that will make
atomic commit use the old cursor state. Add a test that first does
a page flip then cursor update to expose the issue. The test currently
fails on the vblank wait, but that's a common issue affecting all the
tests.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
This will attempt to set any property from any type to each mode object,
to ensure that only enumerated properties can ever set to a mode object.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
Create an unbounded batch in order to ensure that the workload doesn't
disappear before the wait and so we should be given the RPS waitboost.
References: https://bugs.freedesktop.org/show_bug.cgi?id=97564
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|