Age | Commit message (Collapse) | Author |
|
Replace the legacy for_each_engine* defines with the ones
implemented in the gem_engine_topology library.
Use whenever possible gem_engine_can_store_dword() that checks
class instead of flags.
Now the __for_each_engine_class_instance and
for_each_engine_class_instance are unused, remove them.
Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
With the new getparam/setparam api, engines are mapped to
context. Use for_each_context_engine() to loop through existing
engines.
Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Engines referred by class and instance are getting more popular,
gem_engine_can_store_dword() should handle the situation.
Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
we have a "class/instance to eb flags" helper but not the
opposite, add it.
Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
The gem_engine_topology library is a set of functions that
interface with the query and getparam/setparam ioctls.
The library's access point is the 'intel_init_engine_list()'
function that, everytime is called, generates the list of active
engines and returns them in a 'struct intel_engine_data'. The
structure contains only the engines that are actively present in
the GPU.
The function can work in both the cases that the query and
getparam ioctls are implemented or not by the running kernel. In
case they are implemented, a query is made to the driver to fetch
the list of active engines. In case they are not implemented, the
list is taken from the 'intel_execution_engines2' array and
stored only after checking their presence.
The gem_engine_topology library provides some iteration helpers:
- intel_get_current_engine(): provides the current engine in the
iteration.
- intel_get_current_physical_engine(): provides the current
physical engine, if the current engine is a virtual engine,
it moves forward until it finds a physical engine.
- intel_next_engine() it just increments the counter so that it
points to the next engine.
Extend the 'for_each_engine_class_instance' so that it can loop
using the new 'intel_init_engine_list()' and rename it to
'for_each_context_engine'.
Move '__for_each_engine_class_instance' to gem_engine_topology.h
and rename it to '__for_each_static_engine'.
Update accordingly tests/perf_pmu.c to use correctly the new
for_each loops.
Signed-off-by: Andi Shyti <andi.shyti@intel.com>
|
|
This header file is imported in order to include the two new
ioctls DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM,
DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM and DRM_IOCTL_I915_QUERY.
Signed-off-by: Andi Shyti <andi.shyti@intel.com>
|
|
POSIX ERE, while pretty standard is also very old and severely limited.
In fact, it's so limited that Intel CI's own test blacklist,
tests/intel-ci/blacklist.txt, doesn't even work with it due to the lack
of support for backreferences.
Since we're already using glib in other parts of igt, let's just start
using glib's regular expression matching instead of the POSIX regex API.
This gives us full perl compatible regular expressions and in turn, also
gives us python compatible regular expressions to match piglit.
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110248
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Some distribution enable _FORTIFY_SOURCE implicitly if user sets of -O1
greater in the CFLAGS, which may cause surprise compile failures.
Let's fortify explicitly and for everyone with default build, since the
checks provided are good.
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Similar as we had with autotools, enables some more compile checks.
Cc: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Quoting lib/igt_core.c:
* - Code blocks with magic control flow are implemented with setjmp() and
* longjmp(). This applies to #igt_fixture and #igt_subtest blocks and all the
* three variants to finish test: igt_success(), igt_skip() and igt_fail().
* Mostly this is of no concern, except when such a control block changes
* stack variables defined in the same function as the control block resides.
* Any store/load behaviour after a longjmp() is ill-defined for these
* variables. Avoid such code.
*
* Quoting the man page for longjmp():
*
* "The values of automatic variables are unspecified after a call to
* longjmp() if they meet all the following criteria:"
* - "they are local to the function that made the corresponding setjmp() call;
* - "their values are changed between the calls to setjmp() and longjmp(); and
* - "they are not declared as volatile."
We have quite a few igt_subtest_group that define local variables to
share the state between subtest and fixture (e.g. set open() in subtest,
close() in the following fixture), causing the contents to be undefined.
We can allocate some of them using malloc and make the others volatile
to be back on the defined grounds.
Cc: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Quoting lib/igt_core.c:
* - Code blocks with magic control flow are implemented with setjmp() and
* longjmp(). This applies to #igt_fixture and #igt_subtest blocks and all the
* three variants to finish test: igt_success(), igt_skip() and igt_fail().
* Mostly this is of no concern, except when such a control block changes
* stack variables defined in the same function as the control block resides.
* Any store/load behaviour after a longjmp() is ill-defined for these
* variables. Avoid such code.
*
* Quoting the man page for longjmp():
*
* "The values of automatic variables are unspecified after a call to
* longjmp() if they meet all the following criteria:"
* - "they are local to the function that made the corresponding setjmp() call;
* - "their values are changed between the calls to setjmp() and longjmp(); and
* - "they are not declared as volatile."
igt_subtest_group test uses two local variables for tracking the state
of execution, making sure that skips are working correctly.
We can just make them volatile to be back on the defined grounds.
v2: comment on the volatiles as suggested by Simon Ser
Cc: Simon Ser <simon.ser@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Simon Ser <simon.ser@intel.com>
|
|
Disable the memory allocating builtins as they may cause unexpected behavior
with our framework. They *may* get optimized out in favor of a register or
stack variable, making them effectively local.
Local variables do not play well with longjmp, which we use for fixtures
and subtests.
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Yes-we did just update to F29 very recently, but I made the mistake of
doing that two weeks before F30 was scheduled for release. So, update
again to the latest stable release of Fedora.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
While igt isn't really security sensitive, forgetting to call
setgroups() before calling setgid() causes rpmlint on Fedora to
complain:
igt-gpu-tools.x86_64: E: missing-call-to-setgroups-before-setuid
/usr/lib64/libigt.so.0
...
missing-call-to-setgroups-before-setuid:
This executable is calling setuid and setgid without setgroups or
initgroups. There is a high probability this means it didn't relinquish
all groups, and this would be a potential security issue to be fixed.
Seek POS36-C on the web for details about the problem.
Since it's likely other package maintainers for other distros will have
to deal with similar issues eventually, and I can't see any harm in it,
let's do the right thing and call setgroups() first.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Lyude Paul <lyude@redhat.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>
|
|
Some displays might not support hardcoded 1024x768.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109294
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
Instead of listing virtio-gpu with both spellings in the modules
array, properly use its driver name for opening and module name for
loading.
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Audio tests have been removed and replaced by Chamelium tests.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Chamelium uses xmlrpc client which:
$ xmlrpc-c-config client --libs
-L/usr/lib/x86_64-linux-gnu -lxmlrpc_client -lxmlrpc -lxmlrpc_xmlparse -lxmlrpc_xmltok -lxmlrpc_util -lcurl
Debian/Ubuntu (and perhaps others) lack dependency on libcurl-dev:
$ apt depends libxmlrpc-core-c3-dev
Depends: libxmlrpc-core-c3 (= 1.33.14-4)
Suggests: xmlrpc-api-utils
$ apt depends libxmlrpc-core-c3
libxmlrpc-core-c3
Depends: libc6 (>= 2.14)
Depends: libcurl3 (>= 7.16.2)
Which causes:
/usr/bin/ld: cannot find -lcurl
collect2: error: ld returned 1 exit status
[14/711] Compiling C object 'tests/59830eb@@kms_atomic@exe/kms_atomic.c.o'.
ninja: build stopped: subcommand failed.
Debian's `reportbug` was used to report this issue.
Meanwhile we can explicitly ask for libcurl.
Cc: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
The generated EDIDs were wrongly indicating that they support analog sync.
Fixup the detailed timings flags to advertise digital sync instead.
Currently the Linux kernel seems to ignore this completely. However I'd prefer
to fix this anyway to make sure we don't run into issues if an EDID consumer
actually cares about it.
The header definitions for EDID_PT_* values has been re-organized to make it
clearer in which situations the flags are relevant.
Changes from v1 to v2:
- Fix misleading commit message
- Revert the "misc" → "features" rename
- Re-organize EDID_PT_* definitions to make them clearer
Changes from v2 to v3:
- Include review changelog in commit message
- Fix "Fixes:" tag to conform to the kernel style
- Re-order EDID_PT_* definitions to sort by descending bitshift
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: a2fd0489c87a ("lib/igt_edid: new library for generating EDIDs")
|
|
Latest stable release of Fedora
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
dnf supports installing packages by their pkgconfig names using the
pkgconfig() RPM macro. Since these more closely match the dependencies
that meson uses and don't have a chance of changing in the future like
Fedora package name do, let's use these with dnf instead.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
That's what it's there for.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
Following some discussion and confusion around whether or not assert()
should be used, it seems the decision has come to "yes, sometimes". To
quote Petri Latvala on the appropriate points to use assert() in lib/:
However, it's the thought that matters, and this is slightly going off
on a tangent. Those uses of assert in lib/ are for places where
1) something is fatally wrong and we need to drop everything and stop
executing
2) cannot use igt_assert for it. That's for places where we can say
"you tried testing your kernel but it has a bug". The lib/ asserts
are for "IGT has a bug", or in a couple of cases, "your IGT setup
has a bug".
While we did come to the conclusion that we should possibly consider
introducing a new API to check for bugs with igt (and prevent further
testing if any are found), until then let's at least make sure that
assert() always works where we expect it.
So, accomplish this by raising an error if b_ndebug isn't set to
'false'. Additionally, run the compile check in lib/check-ndebug.h to
make sure that the user does not have -DNDEBUG set in their CFLAGS,
c_args options, etc.
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
While I'm pretty confident that no one cares to use libigt.so or
lib_aubdump.so anywhere outside of igt, many distributions including
Fedora and Debian strongly suggest that packages have some sort of so
versioning, even if it's just '0'. So, let's fulfill that minimum
requirement to make this easier to package.
Acked-by: Petri Latvala <petri.latvala@intel.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
glibc 2.30+ will actually include a definition for gettid() that makes
it so that users don't have to manually define a wrapper for it
themselves with syscall(). We don't currently check for this, and as a
result will end up redefining gettid() on the latest versions of glibc,
causing the build to fail:
FAILED: lib/76b5a35@@igt-igt_kmod_c@sta/igt_kmod.c.o
In file included from /usr/include/unistd.h:1170,
from ../../mnt/vol/lib/igt_core.h:43,
from ../../mnt/vol/lib/igt_kmod.c:28:
/usr/include/bits/unistd_ext.h:34:28: error: macro "gettid" passed 1 arguments, but takes just 0
34 | extern __pid_t gettid (void) __THROW;
| ^
In file included from ../../mnt/vol/lib/igt_kmod.c:27:
../../mnt/vol/lib/igt_aux.h:40: note: macro "gettid" defined here
40 | #define gettid() syscall(__NR_gettid)
|
[36/771] Compiling C object 'lib/76b5a35@@igt-igt_kms_c@sta/igt_kms.c.o'.
ninja: build stopped: subcommand failed.
So, fix this by by adding some meson checks to define HAVE_GETTID whenever the
host defines its own gettid(), and avoid redefining gettid() when HAVE_GETTID is
defined.
This fixes build igt-gpu-tools for me on Fedora Rawhide
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
Partly, for correctness. But mostly because not typecasting properly
causes the gettid() macro provided by newer glibc to be typed as pid_t
(aka int), while ours is typed as long. Causing annoying warnings:
[158/846] Compiling C object 'tests/59830eb@@drm_import_export@exe/drm_import_export.c.o'.
In file included from ../../mnt/vol/lib/drmtest.h:39,
from ../../mnt/vol/lib/igt.h:27,
from ../../mnt/vol/tests/drm_import_export.c:27:
../../mnt/vol/tests/drm_import_export.c: In function ‘test_thread’:
../../mnt/vol/tests/drm_import_export.c:123:12: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘__pid_t’ {aka ‘int’} [-Wformat=]
123 | igt_debug("start %ld\n", gettid());
| ^~~~~~~~~~~~~ ~~~~~~~~
| |
| __pid_t {aka int}
../../mnt/vol/lib/igt_core.h:875:64: note: in definition of macro ‘igt_debug’
875 | #define igt_debug(f...) igt_log(IGT_LOG_DOMAIN, IGT_LOG_DEBUG, f)
| ^
../../mnt/vol/tests/drm_import_export.c:123:21: note: format string is defined here
123 | igt_debug("start %ld\n", gettid());
| ~~^
| |
| long int
| %d
So, typecast gettid() as pid_t and update all of our callers accordingly
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
Currently we have multiple different parts of IGT that define their own
wrapper around the gettid() syscall (or just call it directly with no
wrapper).
Additionally, add the appropriate #includes for igt_aux.h to make sure
syscall() is available.
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
Since meson 0.50.0, unit tests which return the GNU standard return code
99 will fail, regardless of whether or not should_fail:true is passed to
test(). Unfortunately, our standard error code (IGT_EXIT_FAILURE) is
also 99.
So, fix this by changing our standard error code to 98.
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
This adds a build and test step with Clang on Fedora. Hopefully this can
help keeping Clang builds healthy.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Acked-by: Petri Latvala <petri.latvala@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
To stop sending those pesky failure emails, that condition people to
ignore anything sent from gitlab-ci.
Now we will have to click the button manually, whenever we want to bump
the docs.
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Bugzilla: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/46
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The test is doing multiple iterations (50). Each iteration tries to
squeeze target number of cursor updates in half a second worth of flips.
If we don't hit the target in any given iteration we bail out early.
Because of that we don't have the data on the number of iterations that
have failed and/or succeeded any given run, which makes hunting down
this elusive issue hard.
Let's change that so we always go through all the iterations and fail at
the end printing out the number of iterations we haven't met the target.
Each failed iteration also logs how many cursor updates it has managed
to do.
Since our target is generated run-time and is also load sensitive, let's
bump the log level of message containing our target to "info" so we can
compare those values across both passes and failures.
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
open(3) takes va_args after the flags and O_CREAT will read the first one. If
we don't provide one, this is undefined behaviour.
(Someone reported it broke the build for them)
Signed-off-by: Simon Ser <simon.ser@intel.com>
Fixes: 311baff151f9 ("tests/kms_chamelium: add dp-audio test")
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Unify the MOCS to be more consistently across the platforms.
Currently gen8+ are specifyig UC whereas earlier platforms
generally use PTE. Let's make everyone more or less specify
L3+PTE.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Allow copying between fp16 surfaces. We'll use the FLOAT
surface format since that's all the display supports currently.
Hopefully the hardware gives us a 1:1 copy, at least if
the input doesn't contain crazy infs/nans etc. We could
choose UNORM instead but that won't work for eventually
exposing fp16+ccs. Although we do need to replace the
simple bpp value with a more specific format type to get
10bpc+ccs working as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
16k*16k*16 == 1<<32, so 32bits isn't enough for the result when
we start to have big framebuffers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We're currently overallocating the shadow buffer stride by a
factor of 8. This didn't go down so well when I tried to use
a 16kx16k float framebuffer.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: b0033d9310c1 ("lib/color_encoding: Prepare support for HDR modes, v2.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we can't match the devid to a chipset, we do not have a reference for
the tiling strides. Instead of randomly failing, skip with a
semi-informative message.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110523
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Remove it from intel_os.c and gem_exec_reuse.c and globally
define in igt_aux.c.
v3: update comment in the code and commit message.
Signed-off-by: Caz Yokoyama <caz.yokoyama@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Commit a794f28f01f2 ("lib: sync with the newer i915_pciids.h from the
Kernel") added CML PCI IDs but did not update intel_device_info.c
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110514
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
Given an implicit semaphore from one engine to the next, check that if
we skip the wait on that semaphore the following batch although
submitted early (as it depends along the single engine timeline) is not
executed ahead of its dependency.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
|
|
Check that we can reorder batches around userspace semaphore waits by
injecting a semaphore that is only released by a later context.
NB: This is expected to fail with the current execlists implementation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
The commit introducing Chamelium audio tests and removing old audio tests
doesn't update autotools files. This patch fixes it.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Fixes: 311baff151f90c1db6f57ee9515216b4f9da5db7
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.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>
|
|
Most people don't have "remember what the last two parameters of
snd_pcm_set_params are" in their lifegoals list. Use variables so that it's
clearer what those are.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
- Print matched audio devices
- Print min/max values when alsa_test_configuration fails
- Print debug log line when skipping a frequency
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|