| Age | Commit message (Collapse) | Author |
|---|
|
DRM_FORMAT_MOD_LINEAR is the more sensible name for
DRM_FORMAT_MOD_NONE. Use the better name.
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Add typechecking to the min/max macros and make their locals truly
unique-ish to reduce the risk of shadowing.
v2: small bug fix, write also height coordinate on rotation
test. (jheikkil)
v3: Fix up a couple of other max/max_t instances (Ashutosh)
Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: Chris Wilson <chris.p.wilson@intel.com>
Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
|
|
Use the definition from kernel headers.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
|
|
There are many use case where we can integrate chamelium with other tests,
Migrating some of basic chamelium functions to igt_chamelium lib to avoid
Code rewriting.
v2: Moved one more function reset_state from tests/kms_chamelium to
lib/igt_chamelium.
v3: - Shifted disabling of modeset to igt_kms
- Replace connection_str with kmstest_connector_status_str (Petri)
- Generalized require__connector_present (Petri)
- Avoided using data_chamelium_t struct (Petri)
v4: - Moved function to library (Petri)
- Renamed some functions and added documentation (Petri)
v6: - Documentation of functions(Petri)
- Shifted function to igt_kms and renamed (Petri)
Signed-off-by: Kunal Joshi <kunal1.joshi@intel.com>
Signed-off-by: Karthik B S <karthik.b.s@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Test hpd test for a connector with all valid pipes set in
it's valid crtc mask.
v1: Added hpd test for a connector with all it's pipes for DP & HDMI
v2: Added hdp test case for VGA <Joshi, Kunal1>
Signed-off-by: Mohammed Khajapasha <mohammed.khajapasha@intel.com>
|
|
The functions for handling uevents are named with "_hotplug" as suffix
such as igt_watch_hotplug(). Earlier hotplug was the only uevent that
was requested to be detected, but in fact, these APIs are generic and
can be used for detecting other uevents too.
Currently we have tests like kms_lease, kms_content_protection using
the uevent handling infrastructure for detecting uevents other than
hotplug.
This patch renames the functions and replace the "_hotplug" suffix
with "_uevents".
v2: Rebase
v3: Added changes in lib igt_chamelium.c, that was missed earlier.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Suggested-by: Ramalingam C <ramalingam.c@intel.com>
Suggested-by: Hiler, Arkadiusz <arkadiusz.hiler@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Acked-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
After replugging a connector and the kernel reports the connector as
connected the cached modes returned by drmModeGetConnectorCurrent() (the
kernel's cached list of modes) may be stale. The modes will be only
updated by a full reprobe. Ensure this by setting output->force_reprobe
which will result in calling drmModeGetConnector().
This fixes sporadic test failures due to seeing no modes unexpectedly.
So far things happened to work, because some in-kernel user of the
output - like fbdev - does a full reprobe sometime after the hotplug
event.
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Receiver reset is always required after we set a new mode, so let's disable
the mode (reset_state() does that) before we switch to a new mode.
With this we will get the HPD pulses reliably for each iteration over
all the supoprted modes.
For more details
Refer c8dc1fd926a5 ("tests/kms_chamelium: Capture on type-c")
Cc: Hiler Arkadiusz <arkadiusz.hiler@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Issue: https://gitlab.freedesktop.org/drm/intel/issues/262
Signed-off-by: Kunal Joshi <kunal1.joshi@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Chamelium uses HPD pulses to signal the need for a receiver reset
using DPMS cycle.Some connectors (e.g. DP over TypeC) have limitations
and will receive just a single such pulse and discard the rest.
This lasts until we disable the mode completetly and only then reenable it.
Receiver reset is always required after we set a new mode, so let's disable
the mode (reset_state() does that) before we switch to a new mode.
With this we will get the HPD pulses reliably for each iteration over
all the supoprted modes.
v2: Correction in code flow (Arek)
v3: Modified commit message. (Arek)
Cc: Hiler Arkadiusz <arkadiusz.hiler@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Issue: https://gitlab.freedesktop.org/drm/intel/issues/262
Suggested-by: Hiler Arkadiusz <arkadiusz.hiler@intel.com>
Signed-off-by: Kunal Joshi <kunal1.joshi@intel.com>
Reviewed-by: Hiler Arkadiusz <arkadiusz.hiler@intel.com>
|
|
The default scenario is now performing all hotplugs with modes disabled
on all connectors. This is the quickest of the tests and represents
userspace not caring about the new display (e.g. explicitly disabled).
*-hpd-enable-disable-mode covers the most common userspace behavior
where each hotplug event is accompanied by a corresponding enabling /
disabling commit.
*-hpd-with-enabled-mode explicitly targets the scenario where we have
mode enabled and never disable it as we do hotplugs to reproduce the
issue we see with TypeC connectors for ICL and TGL.
v2:
- refresh igt_display output state after reprobing
- get mode and set pipe only after we have connector plugged in
v3: fix VGA subtest names (Kunal)
Cc: Kunal Joshi <kunal1.joshi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Issue: https://gitlab.freedesktop.org/drm/intel/issues/323
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Kunal Joshi <kunal1.joshi@intel.com>
|
|
Each tests resets the state to be sure it starts with a clean slate.
Let's add disabling modeset to the pile, to be sure that we get the
hotplug events and the connector state is correct.
Cc: Kunal Joshi <kunal1.joshi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Issue: https://gitlab.freedesktop.org/drm/intel/issues/323
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Kunal Joshi <kunal1.joshi@intel.com>
|
|
Doing disabling modeset from igt_display_require() is quite tricky, as
there are some tests that depend on the leftover mode set by fbcon in
order to work + PSR debugfs checks seem to behave a bit weird.
While those issues are being worked on let's do a disabling modeset
between igt_display_require() and chamelium_init() so port
auto-discovery works reliably on all configurations.
Issue: https://gitlab.freedesktop.org/drm/intel/issues/323
Cc: Kunal Joshi <kunal1.joshi@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Kunal Joshi <kunal1.joshi@intel.com>
|
|
Chamelium provides us with hsync_offset value which is read form its
receiver register described as "Hsync start edge to H active start
edge", vsync_offest is analogous.
Let's calculate the correct things on IGT side.
v2: keep the original checks for HDMI (Petri)
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Nidhi Gupta <nidhi1.gupta@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
The driver can emit multiple hotplug events in response to a hotplug
interrupt, which may cause tests fail receiving a spurious early hotplug
event and concluding that an expected state didn't get set. Let's use
Arek's idea and wait for multiple hotplug events - with the current 20s
timeout - rechecking if the expected state got set after each hotplug.
The reasons for multiple hotplug events I noticed are:
- Both a get connector IOCTL and an HPD interrupt can generate a hotplug
event.
- Resetting chamelium results in an intermittent state where HPD gets
asserted, generating a hotplug connect uevent, then HPD gets
deasserted generating the expected hotplug disconnect uevent.
Suggested-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Using chamelium as a display for non-chamelium-aware test is
challenging. The board can be left in multiple different states after
kms_chamelium tests even though we have atexit() handlers and other
measures which try to assure that all ports are plugged in. Sadly this
is not 100% reliable. We also had a few boards hard hanging (happens
very seldom) and requiring manual intervention.
This leads to changes in the testing configuration - we may end up with
any number of connectors plugged in which makes a lot of kms_ tests to
flip between skip and pass depending on a run.
In an attempt to make connectors state less random this patch makes
igt_display_require() chamelium-aware. If chamelium is configured for
given machine we try to reach it and make sure everything is plugged in.
If we fail to do so we abort the execution because the testing
configuration is an unknown.
For machines without a configured chamelium this boils down to a nop.
I have run a bunch of tests and measured how much time we spend in the
Chamelium section of igt_display_require() (n = 1000) with chamelium
configured:
Min: 0.0030s Max: 0.0113s
Avg: 0.0089s Median: 0.0089s
With ~1000 of KMS subtests in a run it's only a mere 9s.
This will however add a bit of extra execution time to test skips
because of doing kmstest_set_vt_graphics_mode() and
igt_display_require() before even checking whether Chamelium is
configured.
v2: do kmstest_set_vt_graphics_mode() before requiring display (Petri)
Fixes: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/20
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
chamelium_wait_reachable() is asserting internally if the chamelium not
reachable. Let's make it return bool instead and create
void chamelium_assert_reachable() that fails the run.
v2: Add docs (Petri)
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
The test is making Chamelium's receiver signal a need for retraining to
the upstream, which i915 handles correctly. Then it asserts a number of
conditions that are neither a part of the DisplayPort spec, conformance
test suite or the current driver's behavior.
The test needs a complete rethinking. Let's remove it instead of letting
it bitrot further.
Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1059
Cc: Martin Peres <martin.peres@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Currently, only hard coded pixel formats are validated which are not
generic across platforms which leads to SKIPS.
Added support to validate only those pixel formats which are supported by
platform. Covering both RGB and YUV pixel formats.
v2: added support for RGB pixel formats (Swati)
v3: simplified constraint and made it more readable (Petri)
v4: -used igt_format_str instead of macro to print fourcc code (Ville)
-dropped patch#1 because of above change
v5: -Removed connector_dynamic_subtest_end macro and modified
connector_dynamic_subtest to allow scoping depending on
requirement (Petri)
-Changed test names to make it more revealing (Arek)
Signed-off-by: Kunal Joshi <kunal1.joshi@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Removing igt_skip_on_simulation() from all the kms tests
since this feature is not supported anymore.
v2: Rebase
Signed-off-by: Swati Sharma <swati2.sharma@intel.com>
Signed-off-by: Karthik B S <karthik.b.s@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
We test so many audio configurations that igt_debug's ring buffer gets
overflown which often puts the actual failure out of our reach.
Let's promote failure-indicating messages to critical log level, so we
see which exact configuration has borked.
Cc: Martin Peres <martin.peres@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111696
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
We've seen cases in which /proc/asound doesn't exist (e.g. with the new SOF
framework). We've also seen cases in which no soundcard is exposed by ALSA (see
bugzilla link). Last, some audio drivers din't support ELDs (non-Intel
drivers). In all of these cases, skipping the tests depending on ELD support
makes more sense and makes it clearer what happens.
v2: also check that the driver supports ELDs entries in procfs
Signed-off-by: Simon Ser <simon.ser@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102370
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Add test descriptions to all subtest groups and subtests.
Each connector type has its own group, with a different set of subtests.
To avoid duplication, descriptions are defined at the test function level.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
A reprobe_connector has been mungled by mistake in a previous patch. The old
connector status was used, which always failed because it's asserted to be
DRM_MODE_CONNECTED before the unplug.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Fixes: 87209d8421ea ("tests/kms_chamelium: chatty connector status assertions")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Getting network back after waking up from suspend takes some time.
If it's not quick enough, it may cause any following chamelium_rpc
to fail.
This includes the chamelium port reset in exit handler:
igt_chamelium-CRITICAL: Test assertion failure function chamelium_rpc,
file ../lib/igt_chamelium.c:349:
igt_chamelium-CRITICAL: Failed assertion: !chamelium->env.fault_occurred
igt_chamelium-CRITICAL: Last errno: 113, No route to host
igt_chamelium-CRITICAL: Chamelium RPC call failed: libcurl failed to execute
the HTTP POST transaction, explaining:
Failed to connect to 192.168.1.224 port 9992: No route to host
Stack trace:
#0 ../lib/igt_core.c:1674 __igt_fail_assert()
#1 [chamelium_rpc+0x1ea]
#2 ../lib/igt_chamelium.c:2274 chamelium_reset()
#3 ../lib/igt_chamelium.c:2361 chamelium_deinit()
#4 ../lib/igt_core.c:2124 call_exit_handlers()
So let's wait for Chamelium to be reachable after each suspend_autoresume.
v2: Bump the network timeout to 20s,
the slowest observed bring-up was 17s. (Petri)
Do not DECREF if we get NULL from __chmelium_rpc(). (Simon & CI)
Cc: Simon Ser <simon.ser@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109380
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Simon Ser <simon.ser@intel.com>
|
|
read it
test_edid_read sets an EDID on a port, plugs it and reads it back. Sometimes
retrieving the blob fails. Check whether the blob is set at all before trying
to get it. This makes it obvious it's not drmModeGetPropertyBlob failing for
another reason.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106766
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
This test generates an EDID with support for modes tied to a specific aspect
ratio. It then plugs a connector with this EDID and iterates the list of modes
to find the one with the expected aspect ratio flag. The connector is then
enabled and the Chamelium board is used to capture the AVI InfoFrame. The
InfoFrame fields are then checked.
To advertise support for a mode with a specific aspect ratio, sinks add Video
Identification Codes in the CEA extension. The VIC chosen by the source is
contained in the AVI InfoFrame. The InfoFrame also contains a picture aspect
ratio field, but it's only able to indicate whether the aspect ratio is 16:9 or
4:3.
For now the test is only enabled for HDMI. I've tried to make it work on DP
too, but after reading the kernel code it seems like we don't support AVI
InfoFrames on DP.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
This commit adds an error message to connector status assertions.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
This test first checks that on normal hotplug, the link-status property is set
to GOOD. It then triggers a link failure, checks that the property is updated
to BAD. Checks are performed to make sure the new mode list is a subset of the
previous one. After that, a new modeset is performed if necessary and the
link-status property is set back to GOOD.
This whole dance is repeated until we reach fallback modes.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
|
|
This has several advantages:
* No more need to convert back and forth between these two (everybody should
use struct edid, the exception being lib/tests/igt_edid which performs sanity
checks)
* Makes it clearer that users can call edid_get_size on a returned EDID blob
* Improves type safety (it's more obvious is a random blob is used as an EDID)
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
If the DUT sends an InfoFrame, check that its values are correct. Per the HDMI
and DP specs, most of the fields can be set to "refer to stream header" because
some information is duplicated. The DP spec also says that InfoFrames are
optional if mono or stereo audio is used (because there's no channel speaker
allocation).
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This adds the infrastructure necessary to change EDIDs provided to
chamelium_new_edid, without actually doing it yet. This commit just updates the
API to make it possible, documents expectations and updates callers
accordingly. Mutating EDIDs is necessary to add an identifier to them (e.g. by
adding a serial number) and to be able to map Chamelium ports to DRM
connectors.
A new function chamelium_edid_get_raw allows callers to retrieve the exact EDID
used for a particular port.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
The idea is to check that the mode is correctly applied. We use the Chamelium's
GetVideoParams method to get and check mode parameters.
We need to start a capture of zero frames to trigger the FSM. Without it,
Chamelium's receiver doesn't get stable video input.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
The function was called, but the result was never used. Probably a remnant from
a previous refactoring.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
We now generate our own EDID for DP audio tests.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This returns the 3-letter manufacturer identifier of an EDID.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
streak isn't initialized, which makes the test fail in the case in which it's
not zero by chance. This bug has been seen in production™.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
There are two reasons for this:
* An opaque struct is more type-safe than an int
* In the future we'll want to tag EDIDs with the Chamelium port ID, to be able
to automagically infer the DRM connector <-> Chamelium port mapping. This is
necessary for DP MST (connector names are not stable).
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
We don't use the default Chamelium EDID anymore in Chamelium tests. We can drop
it.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
Set flatline test amplitude to 0.1 instead of 0.9. There have been concerns
about edge-cases where bad TV hardware is connected via HDMI/DP and breaks when
a DC offset is sent.
This is a first mitigation. A second mitigation to only send audio to the
Chamelium device instead of all HDMI/DP ports is planned, but requires changes
in ALSA and/or DRM.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This test enables a Chamelium port with an audio-friendly EDID, and then checks
that the EDID-Like Data exposed by ALSA matches our expectations.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This makes it clearer what happened when an assertion fails. It's also easier
to write CI bug log filters.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-By: Martin Peres <martin.peres@linux.intel.com>
|
|
Prior to this commit, we were using the Chamelium's default EDID for DP audio.
This relies on the fact that this EDID supports audio and has correct audio
paremeters for our testing.
Generating our own EDID is less error-prone and will allow us to test different
audio parameters.
v2:
- Replace {HDMI,DP}_AUDIO_EDID_LENGTH with AUDIO_EDID_LENGTH (Arek)
- Don't hardcode EDIDs array length (Arek)
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
This new function uses igt_edid to generate an EDID suitable for testing HDMI
audio. It's imported from kms_chamelium with minor edits, it's used there and
in kms_hdmi_inject. A (unexported for now) generate_hdmi_audio_edid function
enables generation of EDIDs with arbitrary SAD and speaker blocks.
This obsoletes kmstest_edid_add_audio.
The sanity check for the HDMI audio EDID has been moved from
lib/tests/igt_hdmi_inject.c to lib/tests/igt_edid.c.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
The previous pulse test only checked the signal amplitude.
This commit adds a new check to the flatline test: channel alignment. This check
makes sure there is no time shift between each channel.
This is achieved by first sending a positive signal and then a falling edge.
Edges in each channel should be aligned.
The index of each channel's falling edge is stored in number of samples. I
chose not to implement a per-page test because the edge could be right between
two pages.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This commit adds a flatline test alongside the existing frequencies test.
The test sends a constant value and checks that the amplitude is correct. A
window is used to check that each sample is within acceptable bounds. The test
is stopped as soon as 3 audio pages pass the test.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This identifies the audio test name. This is required for adding multiple
audio tests.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This function converts normalized doubles into an ALSA PCM format.
Instead of having per-format audio_signal_fill_* functions, we can only have
audio_signal_fill that outputs normalized doubles. Then in ALSA's playback
callback, we can simply use the new audio_convert_to function to fill the
buffer.
This makes the test code simpler and prevents code duplication when another
ALSA playback callback is implemented.
This adds a dependency of igt_audio over ALSA for the PCM format enum, but I
don't think this is a concern, since I don't see the point of using igt_audio
without igt_alsa. If this is an issue, it would always be possible to replace
ALSA's enum with our own in the future.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
Also add a reference to the relevant Chromium bug.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
- Rename do_test_display_audio to test_audio_frequencies to prepare for a
future amplitude/delay test
- Rename test_audio_configuration to check_audio_configuration because this
function doesn't execute any test, it just checks whether we can perform
audio tests using a particular configuration
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
This extracts the logic receiving audio pages in do_test_display_audio into a
new audio_state_receive function. The function takes care of updating the
current msec counter and dumping the received data in a file.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
