| Age | Commit message (Collapse) | Author |
|---|
|
Instead of shoving everything into do_test_display_audio, extract the logic to
initialize, start, stop, finish an audio test in helper functions. The struct
audio_state now carries all audio-related state.
This will allow to easily add more audio tests that don't use sine waves (via
audio_signal). This is necessary for future delay and amplitude tests.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
We run multiple audio sub-sub-tests inside the same sub-test to save a modeset.
With the current output it's not clear whether a particular sub-sub-test
succeeded or not.
After a sub-sub-test has completed, print its configuration (format, channels,
sampling rate) and its result.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
In these configurations the Chamelium device sends malformed data:
- More than 2 channels
- 2 channels, more than 16-bit samples and more than 32KHz sampling rate
In these cases, skip the test.
See crbug.com/950917.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This adds a new test_formats array, which is a list of PCM formats we want to
run the tests with. We try to run tests for all combinations of sampling rates
and formats.
The ALSA callback now needs to fill the playback buffer differently depending
on the format.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This allows us to test whether HW supports a PCM format, and only run the test
if it's the case.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This commit adds a new format argument to alsa_configure_output. This allows
the caller to decide the format used for the audio signal.
This removes the assumption that samples are S16_LE items in igt_alsa. The
alsa function snd_pcm_format_physical_width is used instead of sizeof(short).
This also removes the theorically incorrect assumption that sizeof(short) ==
sizeof(int16_t).
Right now S16_LE is hardcoded in the test. Tests with other formats will be
added in future commits.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
Explain that they can get dropped depending on the sampling rate and why.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Explain why we need to choose a big enough buffer for audio capture.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
The random tests allowed potentially invalid things:
- 1x1 fb's to be created. Force a minimum of 32 on YUV so a scaled
planar format plane will be at least 16x16. This will fix
scaled/planar format support in i915 and avoid a div by zero when
calculating a value modulo h/2 and w/2.
- Downscaling to any amount, restrict it to 2x to make the test pass.
- Some hw may not allow scaling, in those cases we should fallback
to no scaling at all.
- Attempting to configure a minimum of 4 planes, instead of a maximum.
This fails with a null pointer deref if the hw doesn't have 4
configurable overlay planes.
Changes since v1:
- Enforce a minimum displayed size of 16x16 for intel only,
otherwise it's 1x1.
- Fix comments.
Changes since v2:
- Fix comments harder.
- Pick a random format and its modifier from the plane itself,
instead of using igt_format_array_fill(). This will cause the test
to use all valid combinations of modifiers and formats.
- Set minimum dimension to 8 for !yuv, and 16 for YUV.
- Generate format / modifier before
Changes since v3:
- Rebase.
Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Simon Ser <simon.ser@intel.com> #v3
|
|
In order to be able to generate S32_LE signals, we need a higher precision than
S16_LE. Change the signal generation code to use double instead of int16_t and
introduce a new helper to fill a buffer with S16_LE samples. We already use
arrays of doubles elsewhere (see audio_signal_detect). Similar format-specific
helpers will be added for S32_LE in the future.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
The audio test is repeated with a few different frequencies. When the test
fails for one frequency, continue testing other frequencies so that we get a
better understanding of the situation: is only one frequency failing, or are
all of them failing?
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Now that we have all the required EDID bits in place, we can add a new
hdmi-audio test.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
These weren't tested on DisplayPort (because the Chamelium's default EDID
doesn't advertise them) so this doesn't remove some test cases.
On HDMI they don't work reliably: sometimes no audio data is captured by the
Chamelium. This needs to be investigated, but for now let's just disable them.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
The default Chamelium EDID works great with DisplayPort but has issues with
HDMI. The EDID advertises itself as a DisplayPort-only device, which causes
issues with HDMI audio. Additionally, the EDID doesn't contain a magic
incantation within a vendor-specific data block that is needed for audio to
work.
This patch makes it so an EDID is generated and set by IGT. The EDID is the
base IGT EDID patched to append a Short Audio Descriptor and Vendor Specific
Data block extension.
This generated EDID is suitable for HDMI audio. For DisplayPort audio, we keep
using the Chamelium's default EDID.
A new enum test_edid has been introduced to prevent mismatches between the
Chamelium EDID ID and the raw EDID.
The global variable holding the test frequencies has been renamed to prevent
shadowing by local variables.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Skip audio tests in case GetAudioFormat is not supported by the Chamelium
device (because it is outdated).
A new __chamelium_rpc function has been introduced. The difference with
chamelium_rpc is that it doesn't asserts that the XML-RPC succeeds.
A new chamelium_supports_get_audio_format function has been introduced. It
tries to call GetAudioFormats with abritrary parameters, and checks whether the
call fails because the method doesn't exist. It is not possible to generalize
it into chamelium_supports_method because some methods might have side-effects
(and the only way to check whether a method exists is to try to call it).
Signed-off-by: Simon Ser <simon.ser@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Arek <arkadiusz.hiler@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Before starting an audio test, make sure the Chamelium supports audio capture
on the port we want to use.
Old Chamelium devices don't support audio capture on DisplayPort ports. This
patch will make the tests skip DisplayPort ports.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
After scheduling an HPD toggle event, make sure that we wait for the
hotplug event for each connector that may be sent by the driver.
Depending on the scheduling there could be 1 event or as many events as
connectors we scheduled an HPD toggle event on, depending on the timing.
So if we don't yet see the expected connector state on a given connector
try to wait for an additional hotplug event and reprobe/recheck the
state.
v2:
- s/igt_assert(x >= y)/igt_assert_lte(y, x)/ to see the actual limits in
the debugging output. (Lyude)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110534
Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Cc: Lyude Paul <lyude@redhat.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-By: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
|
|
The audio test is now run multiple times with a variety of playback sampling
rates.
We now query the capture audio format from the Chamelium XML-RPC API instead of
hardcoding it.
One limitation is that we need to start sending an audio signal before being
able to query the capture audio format. However we need the capture sample rate
to decide which frequencies we generate. For now we use the playback rate and
check that it's the same as the capture rate.
Another limitation is that the DP receiver reports an unknown sampling rate
during the 44.1KHz test. In this case we assume the capture rate is the same as
the playback rate. We'll fail later anyway if this assumption is incorrect
since we check the signal we receive.
Chameleon bug: https://crbug.com/950913
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
Send a different signal to each channel and make sure captured audio channels
are not swapped or mixed up.
The Chamelium device has a bug and already swaps the left and right channels.
For this reason, clients need to retrieve the Chamelium channel mapping and
accomodate for this. See https://crbug.com/950922 for a discussion about this.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This commit updates the audio test to make sure we receive a signal from both
audio channels. However this commit doesn't check that left and right channels
are not swapped. Such a check requires some more work (because the Chamelium
device does swap left and right channels) and will be implemented in a future
commit.
This commit adds a new channel argument to audio_signal_add_frequency, to add
a frequency to a single channel only.
Some light refactoring has been performed: a proper audio_signal_fini
function has been introduced and size_t in now used when it should be.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
Before this patch, the audio test first sends an audio signal for 2s, and then
checks whether the captured signal matches.
This patch makes it so we send and check the signal in parallel. Thus we can
stop the test as soon as we receive the correct signal. This saves ~2s per
audio test.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This new test ensures DisplayPort audio works by using the Chamelium.
It enables the DisplayPort output and sends an audio signal containing a set of
frequencies we choose to all HDMI/DisplayPort audio devices. It starts
recording audio on the Chamelium device and uses the stream server to retrieve
captured audio pages. It then checks that the capture audio signal contains the
frequencies we sent, and only those, by computing a FFT.
A new library has been added to libigt to communicate with the stream server.
It implements a simple custom TCP protocol.
In case the test fails, a WAV file with the captured data is saved on disk.
Right now the test has a few limitations:
- Only the first channel is checked
- IGT only generates audio with a single sampling rate (48 KHz)
- Audio data is not captured in real-time
These limitations will be lifted in future patches.
PulseAudio must not run during the tests since ALSA is used directly. To ensure
this, edit /etc/pulse/client.conf and add `autospawn=no`. Then run
`pulseaudio --kill`.
This commit deletes the existing audio tests. They weren't run and required an
exotic configuration (HDMI audio splitter, dummy HDMI sink and a line-in port
on the DUT).
This patch also changes lib/igt_audio to use uint16_t instead of short. The
rationale is:
- The standard says a short is at least 16 bit wide, but a short can be
larger (in practice it won't happen, but better use types correctly)
- It makes it clearer that the audio format is S16_LE, since "16" is
in the type name.
This patch depends on the following Chameleon bugs:
- https://crbug.com/948060
- https://crbug.com/950857
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This function checks whether a port is an analog bridge. Analog
bridges provide their own EDID thus the vendor should be different
from "IGT".
There was a typo that made the function always return true for VGA
ports. The condition was essentially:
thing != 'I' || thing != 'T'
which is always true.
Apparently this didn't cause any harm, but it's probably better to fix
it anyway in case some tests were skipped and shouldn't.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Acked-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
Newer platforms don't support this format, but the tests don't check
if the format is supported on the primary plane.
After enabling an output we also don't refresh the output connection,
calling igt_output_set_pipe(output, PIPE_NONE) will do so, and prevent
skips because no connected output is detected.
Changes since v1:
- Use igt_plane_has_format_mod (Ville).
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
This introduces a new test for the Chamelium, that sets up planes
with randomized properties such as the format, dimensions, position,
in-framebuffer offsets and stride. The Chamelium capture is checked
against the reference generated by cairo with either a CRC or the
checkerboard-specific comparison method.
This test also includes testing of the VC4-specific T-tiled and
SAND-tiled modes, in all formats supported by the hardware.
Since this test does not share much with previous Chamelium display
tests (especially regarding KMS configuration), most of the code is
not shared with other tests.
This test can be derived with reproducible properties for regression
testing in the future. For now, it serves as a fuzzing test
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
Now that the checkerboard frame checking method is available through
the frame match helper, make use of it in YUV tests to increase the
reliability of the results.
The analog test tends to provide false positives, which are properly
detected by the checkerboard method in most instances.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
In prevision of adding support for another type of frame matching,
rename chamelium_assert_analog_frame_match_or_dump to drop the
analog part and feed it the check type. This way, the bulk of the
helper can apply to other frame matching types.
This requires moving the chamelium_check enum from the test to the
common chamelium header.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The modifier is part of how a frame is represented, so add it as an
extra argument so that it can be specified when converting framebuffers.
For now, only a linear modifier is supported.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
The NV12, NV16, NV21, NV61, YUV420, YVU420, YUV422 and YVU422 are YUV
formats that are currently supported in IGT.
We'll want to test those formats in addition to the RGB formats, so
let's add some subtests. One thing worth noting is some hardware isn't
able to output a pixel-perfect image, so we do the same kind of
comparison than for VGA.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The VGA tests were run so far as part of a separate function. However,
the only difference between that function and the do_test_display
function was the kind of comparison we wanted to use. Indeed, VGA
being an analog output, we can't rely on a pixel perfect image, and
thus only compare the CRCs, but we need to make some more advanced
comparison.
Let's add a new check method, add support for the analog check to
do_test_display and remove the old version.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The various tests in kms_chamelium are really variants of one another
but share little code.
In addition to the duplication, this gets in the way of the
introduction of more tests, or to be able to run all the tests on all
the output, which isn't the case at the moment, with the HDMI and DP
tests and the VGA tests being different.
Start by introducing a check parameter to the do_test_display
function, that will tell which test method we want to use to compare
the frames.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
This adds a new block size argument to the pattern generation helpers so
that different sizes of blocks can be used.
In the future, this allows us to use different block sizes when testing
overlay planes, making it visually explicit what is part of the main
plane and what is part of the overlay plane.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
In order to reuse the pattern generation helper for overlay planes,
let's provide the pattern generation helper with the explicit dimensions
instead of the mode (that only applies to the primary plane).
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
|
|
Using the width from the selected mode is not sufficient to correctly
paint a pattern on the framebuffer memory: the stride also has to be
taken in account for proper line start alignment.
Pass the stride and use it in chamelium_paint_xr24_pattern.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The xr24 pattern for chamelium testing appears mangled when checking it
on an actual display. This is because the horizontal and vertical
display sizes are inverted when used as width and height.
Put them back in order.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The connector and EDID blob retrieved when checking for analog bridges
need to be freed before returning from the associated function.
Fixes: f8d6afa67 ("tests/chamelium: Detect analog bridges and handle EDID accordingly")
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
|
|
Now that we have everything in place, we can add the support for the
subtests testing the output of planes setup with formats other than XR24.
Since YUV will be a bit trickier to handle, start with various common RGB
formats.
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
In order to introduce CRC subtests for DRM formats, we need to take an
intermediate step.
The current code will generate a pattern in XR24, and will try to compare
the CRC returned by the Chamelium for each frames.
This CRC is computed on an XR24 format as well, so it works. However, as
soon as we will start implementing other formats, if we just change the
format of the pattern, the raw content of the buffer, and therefore the
CRC's won't match anymore.
In order to address that, we will need an intermediate step, and we will
now still create the XR24 pattern, and compute its CRC, then convert it to
the format we want to test, and finally retrieve the CRC from the Chamelium
to compare it with the one from the XR24 pattern.
The current code is converted to the new prototype that will take the
fourcc of the format to test, even though we're still using XR24 everywhere
for now.
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The current pattern being used is the one generated through the
igt_create_color_pattern_fb.
However, in order to deal with multiple formats and the upsampling /
downsampling issues that might arise from converting back and forth between
formats, we will need to have a pattern with quite precise color values,
and without any shades or gradient of colors.
Let's create a function that will generate that pattern in the chamelium
code if we need to convert the framebuffer to a smaller depth, and use the
current pattern otherwise.
The easiest way to do that will be to only use values that would have the
same part on the common most significant bits (5, to deal with most
formats) and have the same bit repeated on the least significant bits that
are going to be dropped and / or padded when converting between formats.
Pixman will fill the lowest bits with 1, and our hardware (this has been
tested on a Raspberry Pi's VC4) is able to support that, so the easiest is
to just use all 1's for our components in order to still be able to compute
the CRCs.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
We have two use cases in our current sub-test suites: the tests that test
all the modes exposed by the driver, and the ones just picking up one.
Instead of having to deal with this two cases in the same function as it is
currently done, move the part that test a single mode into a separate
function, and just call it for every mode that we want to test if needs be.
This will result in a simpler function that will be easier to extend to
support formats.
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
If KMS is not supported on the device, drmModeGetResources() will return
NULL, often this is an indication that we should not attempt to run the
test. Although it would be preferred to use something like
igt_require_display() as the canonical check and assert that
drmModeGetResources() did not hit an error, it is not always practical
as the tests do not utilize the common igt_display abstraction.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Simple rule of thumb, if a kms_* test calls igt_display_init() in its
global fixture, skip the entire test if the driver has disabled KMS.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
Only try to set those values if the properties are supported.
This fixes the kms_chameium tests to run on vc4 again.
Reported-by: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
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>
|
