| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Martin Peres <martin.peres@linux.intel.com>
|
|
Instead of first calling kmstest_unset_all_crtcs, and calling
igt_display_init for each test, use igt_display_reset to reset
igt_display between tests, and use atomic commit to disable all
unused crtcs in enable_output().
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
IGT has an api that can find a matching pipe for a given connector,
so use that.
igt_output_override_mode already forces a modeset on an affected pipe
since an earlier commit, so the second call to igt_output_set_pipe
can be removed.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
Setting broadcast rgb was only used by chamelium, but is now handled
in igt_display by default. This means that chamelium doesn't need to
set it, and this can be hidden. The broadcast RGB property is intel
connector specific, so rename the enum to intel_broadcast_rgb_mode.
Keep the property and enum public in case someone wants to test the
property later.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
With the replace_prop_blob functions we can safely replace the blob for
any property, without having to care about error handling ourselves.
This will for example allow overriding color management blobs, or for
kms_atomic set invalid mode blobs.
The color management blob functions are removed, they can now be
replaced by direct calls to replace the properties.
Changes since v1:
- Fix chamelium tests.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
Before capturing video, the Chamelium will always wait for the video
input to be stable (and perform the FSM if it was not). This means that
there is no need to explicitly do it beforehand.
When the receiver needs to be reset, the call will result in a timeout,
after which the follow-up call to capture the video will perform the FSM
that resets it. Skipping the explicit wait for video input stable allows
the Chamelium to perform the FSM directly, which saves valuable time.
Removing the associated call does not negatively impact the execution of
the CRC and frame comparison tests either.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
Resetting the Chamelium when preparing the video output is unnecessary
and significant increases the tests run-time. Since all video-related
tests work just as well without it, eliminate it.
This also adds a call to reset_test in the analog frame dump test, that
was missing before, although the chamelium was still reset by the call
to prepare_output.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
This introduces a fast fashion of testing display CRC, that only tests
a single mode (the highest resolution). It drastically reduces the run
time of the test, which is necessary for the fast-feedback test list.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
This introduces a fast fashion of testing basic hotplug detect, with
only 3 toggles. It drastically reduces the run time of the test, which
is necessary for the fast-feedback test list.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.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>
|
|
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>
|
|
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>
|
|
This adds two new tests: common-hpd-after-suspend and
common-hpd-after-hibernate that are aimed at testing HPD change during
suspend/hibernate for both DP and HDMI, at the same time.
The interest in bringing this test up is to reduce the time spent in
testing, with the downside of less precision regarding the test's
outcome. The per-connector tests are still available to get a more
precise idea of which connector causes a failure, when that happens.
VGA is explicitly excluded from this test as there is currently no
way of doing delayed hpd pulses for it.
The generic hpd suspend/resume test code is split in a dedicated
function, that allow testing one or all possible ports.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
This adds a call to igt_output_set_pipe in orde to refresh output via
igt_output_refresh and ensure that mode override can take effect.
Without this change, using a lower resolution during frame dumps
series with mode changes (e.g. test_display_frame_dump) would not
commit the mode change to the output and leave it with a framebuffer
too small for the previously-commited resolution.
This would cause the test to fail. This allows it to pass.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
This adds a call to close the DRM file descriptor. It is reauired as IGT
will attempt to become DRM master after running the test, resulting in a
failure.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@linux.intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
This reverts commit 25fbae15262cf570e207e62f50e7c5233e06bc67, restoring
commit 301ad44cdf1b868b1ab89096721da91fa8541fdc
Author: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Date: Thu Mar 2 10:37:11 2017 +0100
lib: Open debugfs files for the given DRM device
with fixes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
This reverts commit 301ad44cdf1b868b1ab89096721da91fa8541fdc.
When a render-only device is opened and gem_quiescent_gpu is called, we
need to use the debugfs dir for the master device instead.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
|
|
When opening a DRM debugfs file, locate the right path based on the
given DRM device FD.
This is needed so, in setups with more than one DRM device, any
operations on debugfs files affect the expected DRM device.
v2: - rebased and fixed new API additions
v3: - updated chamelium test, which was missed previously
- use the minor of the device for the debugfs path, not the major
- have a proper exit handler for calling igt_hpd_storm_reset with the
right device fd.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Robert Foss <robert.foss@collabora.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Now that we can just disable HPD storm detection, there's no need to
sleep between each hotplug cycle.
Signed-off-by: Lyude <lyude@redhat.com>
|
|
Recently we added i915_hpd_storm_ctl into i915's debugfs directory,
which allows us to control the thresholds i915 uses for detecting
hotplug interrupt storms from userspace, along with the ability to
entirely disable them. This adds some helper functions into IGT to
enable making use of this feature, along with adding some chamelium
tests for it.
Signed-off-by: Lyude <lyude@redhat.com>
|
|
This fixes VGA HPD tests without DDC failing due to leftover hotplug
events being received by the call to reset_state().
Signed-off-by: Lyude <lyude@redhat.com>
|
|
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Lyude <lyude@redhat.com>
Reviewed-by: Robert Foss <robert.foss@collabora.com>
|
|
For the purpose of testing things such as hotplugging and bad monitors,
the ChromeOS team ended up designing a neat little device known as the
Chamelium. More information on this can be found here:
https://www.chromium.org/chromium-os/testing/chamelium
This adds support for a couple of things to intel-gpu-tools:
- igt library functions for connecting to udev and monitoring it for
hotplug events, loosely based off of the unfinished hotplugging
implementation in testdisplay
- Library functions for controlling the chamelium in tests using
xmlrpc. A couple of RPC calls were ommitted here, mainly because they
didn't seem very useful for our needs (yet)
- A set of functions for doing CRC checks and frame comparisons in
tests
- A set of basic tests using the Chamelium library.
Cc: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Lyude <lyude@redhat.com>
Changes since v1:
- Don't try to guess connector mappings, have the user specify them
manually using a configuration file
- Open DRM fd using DRIVER_ANY, not DRIVER_INTEL
- Lower the hotplug timeout a little bit, since 30 seconds was leftover
from debugging these tests anyway
- Don't try to keep track of the original state of the chamelium ports,
and just leave them plugged in after each run. This makes more sense
to me, since I'd imagine in automated testing setups using chameliums
that all of the extra monitors will probably be provided by the
Chamelium to begin with, so keeping them plugged in would make sure
tests running afterwards that require >1 monitor don't get skipped.
- Add wait_for_connector() to the chamelium tests. After some more
testing, I found that depending on the system some tests would throw
false negatives due to us not waiting long enough for the system to
detect that we connected something to it. This mainly happened with
VGA connectors, since their lack of HPD makes them take significantly
longer for the hardware to notice. wait_for_connector() fixes this by
continually reprobing the status of the desired connector (without
relying on a hpd event happening, since that might never come) until
we get what we want, or we time out and fail.
- Use kmstest_get_property() for retrieving EDIDs instead of doing it by
hand
- Don't hardcode PIPE_A for bringing up the display, use kmstest to find
an appropriate CRTC to use.
Changes since v2:
- Fix incorrect usage of the list helpers when recording new EDIDs
- Add missing documentation
- Make sure documentation actually appears
- Since we finally got video capture working, add CRC functions and fix
the ones we couldn't actually test before
- In the exit handler, reset the xmlrpc env so we can properly reset the
Chamelium even after an RPC error
- Make sure compiling without Chamelium support still works
Changes since v3:
- Change the config file name from .igt_chamelium_rc to .igtrc
- Remove chamelium global context
- Get rid of define_common_connector_tests()
- Get rid of connector list, expose connectors as opaque objects and
provide helpers for accessing their attributes
- Get rid of configure.ac option for Chamelium
- Add tests for CRC functions
- Add frame dumping functions + tests
- Add FSM handling to chamelium_rpc()
- Use LIBUDEV_LIBS in automake, not UDEV_LIBS
- Documentation fixes
- Improve debugging output some more
- Remove skip_without_suspend_support, we no longer need to check for
suspend support before calling things
- Remove unnessecary malloc() checks with igt_assert()
- Don't use igt_require in chamelium_init, leave it up to the caller
whether or not to abort when failing to initialize the chamelium
- Use igt_assert_eq for making assertions about connector's statuses
- Define suspend/resume delay for tests as constant
|
