| Age | Commit message (Collapse) | Author |
|---|
|
Every time we add something to debugfs, we test on the new platform
but forget to test that old platforms still work.
The test adds at most 200 ms extra time, which is worth it considering
how often we break debugfs.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
|
|
emon_crash should skip if the debugfs file could not be opened the first
time, and debugfs_test.read_all_entries should skip files that could not
be opened, instead of returning an error.
This is because in a typical IGT run there may be more debugfs files
registered than can be opened.
This is an example on f2-pnv-d510:
$ grep -r . /sys/kernel/debug/dri/0 >/dev/null
grep: /sys/kernel/debug/dri/0/i915_sseu_status: No such device
grep: /sys/kernel/debug/dri/0/i915_energy_uJ: No such device
grep: /sys/kernel/debug/dri/0/i915_sink_crc_eDP1: No such device
grep: /sys/kernel/debug/dri/0/i915_emon_status: No such device
grep: /sys/kernel/debug/dri/0/i915_guc_log_control: Invalid argument
grep: /sys/kernel/debug/dri/0/i915_fbc_false_color: No such device
grep: /sys/kernel/debug/dri/0/i915_cur_wm_latency: No such device
grep: /sys/kernel/debug/dri/0/i915_spr_wm_latency: No such device
grep: /sys/kernel/debug/dri/0/i915_pri_wm_latency: No such device
grep: /sys/kernel/debug/dri/0/i915_next_seqno: Permission denied
grep: /sys/kernel/debug/dri/0/i915_cache_sharing: No such device
grep: /sys/kernel/debug/dri/0/i915_min_freq: No such device
grep: /sys/kernel/debug/dri/0/i915_max_freq: No such device
grep: /sys/kernel/debug/dri/0/i915_pipe_C_crc: No such device
grep: /sys/kernel/debug/dri/0/i915_forcewake_user: Invalid argument
grep: /sys/kernel/debug/dri/0/crtc-1/crc/data: Input/output error
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
|
|
Nowadays, many VGA connectors are not actually native VGA but use a
discrete bridge to a digital connector. These bridges usually enforce
their own EDID instead of the one supplied by the chamelium.
Thus, the EDID read test for VGA is not relevant in that case and
should be skipped. Reported modes may also go beyond what the chamelium
can support. Thus, only supported resolutions should be tested for the
frame dump test and others should be pruned.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude <lyude@redhat.com>
|
|
This adds support for VGA frame comparison testing with the reference
generated from cairo. The retrieved frame from the chamelium is first
cropped, as it contains the blanking intervals, through a dedicated
helper. Another helper function asserts that the analog frame
matches or dump it to png if not.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude <lyude@redhat.com>
|
|
This merges the two test_display_crc_single and
test_display_crc_multiple functions into one, with a variable number of
frames to capture. This reduces code duplication.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude <lyude@redhat.com>
|
|
This adds support for dumping both the frame capture from the chamelium
and the reference frame generated by cairo when the captured crc does
not match the crc calculated from the reference, using common helpers.
Getting a dump of the frames is quite useful in order to compare them.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude <lyude@redhat.com>
|
|
This introduces CRC calculation for reference frames, instead of using
hardcoded values for them. The rendering of reference frames may differ
from machine to machine, especially due to font rendering, and the
frame itself may change with subsequent IGT changes.
These differences would cause the CRC checks to fail on different
setups. This allows them to pass regardless of the setup.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude <lyude@redhat.com>
|
|
This adds calls to igt_hotplug_detected and igt_flush_hotplugs to catch
and flush hotplugs from connector unplug (due to chamelium reset) and
plug. These need to be intercepted so that they are not delayed and
issued after resume, providing a false positive for the test result.
In addition, the final hotplug uevent flush is brought closer to the
suspend call, to decrease the likeliness of false positive.
However, false positives still do happen, because it is not possible to
make sure that the uevent caused by each connector's state change was
caught instead of being delayed and issued at resume time.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude <lyude@redhat.com>
|
|
It may occur that a hotplug uevent is detected at resume, even though it
does not indicate that an actual hotplug happened. This is the case when
link training fails on any other connector.
There is currently no way to distinguish what connector caused a hotplug
uevent, nor what the reason for that uevent really is. This makes it
impossible to find out whether the test actually passed or not.
To circumvent this problem, the link status of each connector is
collected before and after suspend and compared to skip the test if
the state was good before and turned to bad after resume.
This only concerns the EDID change test, where we cannot check the
connector state (that is not supposed to have changed). For actual
hotplug tests, the tests should be safe since they check each
connector's state after receiving the uevent.
The situation described here happens with DP-VGA bridges that fail link
training after resume, as they need some more time to response on their
AUX channel.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
Platforms with per-engine reset enabled (i915.reset=2) are unlikely to
perform a full chip reset, keeping the reset_count unmodified. In order
to keep the expectations of this test, enforce that full GPU reset is
enabled (i915.reset=1).
Later on, we can expand the reset_stats ioctl to also return the number
of per-engine resets and use reset_count + reset_engine_count when
checking for the updated reset count.
v2: Rebase, don't use gem_gpu_reset_type directly, since we now have
additional helpers.
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Acked-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
This allows us to proceed gracefully without invoking the global
CI-level timeout especially when opening the buggy crtc-data
file descriptor.
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
I can live without those logs, and it avoids a kernel
recompile&reboot.
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Allow tests to create Y-tiled bufferes using a separate
argument to the test without increasing the number of
subtests.
v2: Changed tiling option to string (Paulo)
v3 (from Paulo): minor nitpicks.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Praveen Paneri <praveen.paneri@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
The multidraw subtest was not taking whether or not the GEM buffer had
ever been in write-combining mode when checking for PSR state, so fix
that.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
|
|
This will make the IGT tests that use fences more useful, since they can
perform the waiting themselves when required.
To celebrate, also add plane-use-after-nonblocking-unbind-fencing,
the fence version of plane-use-after-nonblocking-unbind.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Gustavo Padovan <gustavo.padovan@collabora.com>
|
|
This is already done in igt_display_commit* functions.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Gustavo Padovan <gustavo.padovan@collabora.com>
|
|
Trying to set a fence on disabled pipes will be rejected by the kernel:
[ 1275.865029] [drm:drm_atomic_check_only [drm]] [CRTC:39:pipe B] requesting event but off
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99911
Acked-by: Gustavo Padovan <gustavo.padovan@collabora.com>
|
|
When a plane gets disabled, that commit has to complete before an
atomic commit on that disabled plane only. Else for the old commit,
new_plane_state may have been freed.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Gustavo Padovan <gustavo.padovan@collabora.com>
|
|
Trivial test to alternate executing a batch either stored in the last
slot (default) or the first slot (EXEC_BATCH_FIRST).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Negative testing ftw.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
References: https://bugs.freedesktop.org/show_bug.cgi?id=101717
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Currently the panning tests actually stop panning when they hit the
right edge fo the framebuffer. Let's make them ping-pong across the
fb to make it clear that they are indeed trying to pan around all the
time.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
This adds support for configurable suspend/resume delay and takes the
occasion to move igtrc configuation from igt_chamelium to igt_core.
This way, suspend/resume delay configuration can be used for all tests.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
Since most tests are already doing a reset, there is no need to
duplicate it at init time. This removes that duplicate reset and adds
a call to reset_state where in-test resets where not done previously.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
This reverts commit d7a0b61450797a3d6644c65aebf75c2a90da1a15.
|
|
This reverts commit f807953c4e90870df940ecb0e4b5c51caa50167e.
|
|
This reverts commit 537c4849d476661409425b0e2a5ad8bce4c561eb.
|
|
For tests with attempt to hit races and such by running for
relatively long time, it seems that it might be possible to get
by only testing some subtest-engine combinations as long as in
total we still exercise all engines per test.
More precisely, I think that if we view our engines as fast
(!rcs) and a little less fast (others), we group the race
hitting tests in those two camps, we keep the same coverage
by running each subtest against each engine group.
v2: Replace individual engine gem_sync subtests with all
variants. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Extended versions of the already existing short tests.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Exercise the ABI with a basic test now that we have removed the
defaul engine alias from the engine list.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Default is not an engine but an ABI alias for RCS. Remove it
from the engine list to eliminate redundant subtests and test
passes.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Testing LNCFCMOCS values on non-render engines is tricky. The values in
those registers are lost on RC6, which means that if users of non-render
engines want to see the proper values, they need to obtain a forcewake
and execute something on render (relying on it to restore the values)
before using non-render engine.
Previous version of the test did exactly that - we were relying on the
fact that we're taking forcewake (hidden by intel_register_access_init,
even though the test is not doing any mmio accesses) before iterating
through engines (and render is before other engines, so job done).
I really hope that this is not an ABI and those registers are not used
on non-render in any way. Let's limit testing LNCFCMOCS to render
engine only.
The other non-render issue is that when we're using I915_EXEC_BSD, we
can't be sure which BSD ring we'll end up executing on. Let's
explicitly select BSD1 and BSD2 in our tests.
While we're here, let's also remove the duplicated code and add some
structure by extracting moving more content into subtests.
We're only doing tests that involve "dirtying" the registers for the
render engine - since it's the only one that has those registers in its
context.
v2: Do not skip all BSD engines, test non-default contexts on render
only, change names in CI extended.testlist
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Łukasz Kałamarz <lukasz.kalamarz@intel.com>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Łukasz Kałamarz <lukasz.kalamarz@intel.com>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This reverts commit 9a6ed6c6398c2218d65392593fa43852810515cc.
Test actually exposes a bug in the kernel where opening the crtc-data
file takes a long time.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
When descending thru debugfs directory. Doing this tends to
takes forever. CRC pipe read tests for this are already
covered under kms_pipe_crc_basic.
v2: Be more verbose that the check is meant for the crtc control data
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Cc: arkadiusz.hiler@intel.com
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
This currently only happens when the power well is not enabled,
but in theory should happen every time the file is opened when
the CRTC is not enabled.
This fixes debugfs_test@read_all_entries failing on f2-bxt-j3405.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
Use the convenience function instead of handrolling it.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
On CHV pipe C when the cursor is visible with a negative X coordinate
a FIFO Underrun will occur. The kernel worked around this by disallowing
cursor updates on pipe C at negative X coordinates when the cursor is
visible.
This was done in the following kernel commit:
commit ef8dd37af85a8f37ca3a29074647511e52c56181
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Dec 18 19:24:39 2015 +0200
drm/i915: Workaround CHV pipe C cursor fail
kms_chv_cursor_fail was created to test this issue, but it also happens
in kms_cursor_crc, so workaround it there too.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97960
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The intent is that during interruptible runs we always force a
relocation between batch. This requires us to set an invalid
presumed_offset.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The content of the batch may no longer match the offset/presumed_offset
pair, so force the relocation by setting reloc.presumed_offset=-1
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Several tests were passing a presumed_offset that matches the actual
offset of the object and so were very suprised when the kernel promptly
skipped performing the relocation (as expected).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
They're not useful since GPU reset may kill off our spin batch.
This used to be the case but wasn't in the kernel when I wrote this
test. But the following commit reintroduced this behavior:
commit 36703e79a982c8ce5a8e43833291f2719e92d0d1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Jun 22 11:56:25 2017 +0100
drm/i915: Break modeset deadlocks on reset
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
DRM_MODE_PAGE_FLIP_EVENT is now rejected if no CRTC is affected by the
changes. Make sure the TEST_ONLY test keeps working, and test with
DRM_MODE_PAGE_FLIP_EVENT.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Since VGA hpd detection is done through RGB lines load detection and
nowadays often goes through a bridge to some digital interface, HPD
detection usually takes a while (up to a couple seconds).
Thus, it is not as relevant to stress it as many as 15 times.
This brings the toggle count down to 5 times, which makes the test run
a lot faster without really changing the outcome much.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
This adds HPD toggle after suspend and hibernate testing for VGA, in the
same fashion as currently done for DP and HDMI and includes VGA in the
common suspend and hibernate test.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
This adds support for the newly-introduced ScheduleHpdToggle XMLRPC
method of the Chamelium's interface and makes use of it instead of
starting pulses with an asynchronous call, suspending and dealing with
the result at resume.
The XMLRPC library does not guarantee that the call will be made before
caring for its outcome and this is in fact what was happening:
the call was being delayed until resume time, as can be seen from the
Chamelium's logs. The quite generous timeout for HPD event detection
would then catch the toggle, that was sent after resume.
This is especially useful for testing HPD during suspend/resume.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
Using a 1 s delay seems too large for detecting a connector change, that
may happen faster than this. Since the constraints on execution time are
high, it is preferable to use a much smaller sleep time.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
Without doing a full reprobe, hpd toggles are sent without much delay
between them. With a VGA connector attached, the reset occurring before
the test will toggle its state, with a delay (inherent to hpd detection
on VGA).
It often occurs that this VGA state toggle is detected in the middle of
the current connector test, triggering a hotplug event unrelated to the
current connector and thus causing the test to fail.
Thus, the state of all connectors is checked (and waited for) before
running the basic hotplug test.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
vgem is a nasty test case for various parts of the core as it is a
virtual device with drm_device.dev == NULL; this includes drm_setversion
for example.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
