Age | Commit message (Collapse) | Author |
|
[Why]
Mediatek devices have a HW issue with sending their vblank IRQ at the same time interval
everytime. The drift can be below or above the expected frame time, causing the
timestamp to drift with a relatively larger standard deviation over a large sample.
[How]
Filter out the flags TEST_CHECK_TS and TEST_VBLANK_EXPIRED_SEQ from the
tests flags, and restrict sequence and ts checks.
Tested on Jacuzzi (MT8183)
Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Add support for MSM drivers.
Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
Reviewed-by: Arkadiusz Hiler <arek@hiler.eu>
|
|
This introduces the igt_nouveau library, which enables support for tiling
formats on nouveau, along with accelerated clears for allocated bos in VRAM
using the dma-copy engine present on Nvidia hardware since Tesla. Typically
the latter would be handled by the kernel automatically, which is the
long-term plan for nouveau, but since the kernel doesn't yet support that
we implement this in igt in order to fulfill the expectation that most of
igt has in which newly allocated fbs are expected to be zero-filled by
default.
The dma-copy engine is capable of fast blitting, and is also able to
perform tiling/untiling at the same time. This is worth mentioning because
unlike many of the other drivers supported in igt, we go out of our way to
avoid using mmap() in order to perform CPU rendering wherever possible.
Instead of mmap()ing an fb that we want to draw to on the CPU (whether it
be for converting formats, or just normal rendering), we instead use
dma-copy to blit linear/tiled fbs over to linear system memory which we
mmap() instead. This is primarily because while mmap() is typically
painfully slow for vram, it's even slower on nouveau due to the current
lack of dynamic reclocking in our driver. Furthermore, using the dma-copy
engine for copying things over to system ram is also dramatically faster
than using igt's memcpy wc helpers even when no tiling is involved. Such
speed improvements are both quite nice, but also very necessary for certain
tests like kms_plane that are rather sensitive when it comes to slow
rendering with drivers.
This doesn't mean we won't want to provide a way of using mmap() for
rendering in the future however, as at least basic testing of mmap() is
certainly something we eventually want for nouveau. However, I think the
best way for us to do this in the future will be to adapt the igt_draw API
to work with nouveau so we can explicitly request using mmap() in tests
which need it.
Finally, this code also adds a hard dependency on libdrm support for
nouveau tests. The main reason for this is currently there are no real
applications that use nouveau's ioctls directly (mesa for instance, uses
libdrm as well) and also that nouveau's ioctls are currently a bit
complicated to use by hand. This will likely be temporary however, as Ben
Skeggs is planning on revamping a lot of nouveau's APIs to simplify them
and make libdrm support for nouveau obsolete in the future. Note that we
take care to make sure that users can still disable libdrm support for
nouveau if needed, with the only caveat being that any tests using
igt_nouveau will be disabled, along with any tiling support for
nvidia-specific tiling formats.
This should enable igt tests which test tiling formats to run on nouveau,
and fix some seemingly random test failures as a result of not having
zero-filled buffers in a few other tests like kms_cursor_crc.
Changes since v1:
* Remove leftover rebase detritus in drm_fourcc.h
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Jeremy Cline <jcline@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
The vgem device is used by several tests in conjunction to their HW
backend in order to supply external fences. Do not prevent these tests
from running by filtering out DRIVER_VGEM.
Suggested-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
We don't need to print out the filter the umpteen thousand times we try
and open the same device; it floods the test output with noise.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
|
|
Beneath drm_open_driver() we have a routine that tries to load a module
appropriate for the selected chipset. This can be useful for tests that
want to ensure the right module is loaded prior to starting, without
opening the device itself.
Suggested-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
We're finally getting CRC support in nouveau, so let's start testing
this in igt as well! While the normal CRC capture tests are nice,
there's a number of Nvidia-specific hardware characteristics that we
need to test as well.
The most important one is known as a "notifier context flip". Basically,
Nvidia GPUs store generated CRCs in an allocated memory region, referred
to as the notifier context, that the driver programs itself. Strangely,
this region can only hold a limited number of CRC entries, and once it
runs out of available entries the hardware simply sets an overrun bit
and stops writing any new CRC entries.
Since igt-gpu-tools doesn't really have an expectation of only being
able to grab a limited number of CRCs, we work around this in nouveau by
allocating two separate CRC notifier regions each time we start
capturing CRCs, and then flip between them whenever we get close to
filling our currently programmed notifier context. While this keeps the
number of CRC entries we lose to an absolute minimum, we are guaranteed
to lose exactly one CRC entry between context flips. Thus, we add some
tests to ensure that nouveau handles these flips correctly
(pipe-[A-F]-ctx-flip-detection), and that igt itself is also able to
handle them correctly (pipe-[A-F]-ctx-flip-skip-current-frame). Since
these tests use a debugfs interface to manually control the notifier
context flip threshold, we also add one test to ensure that any flip
thresholds we set are cleared after a single CRC capture
(ctx-flip-threshold-reset-after-capture).
In addition, we also add some simple tests to test Nvidia-specific CRC
sources.
Changes since v5:
* Fix typo
Changes since v4:
* Don't clear the currently set display pipe at the end of each iteration of
pipe tests, otherwise we'll accidentally leave ourselves with no configured
CRTCs when the test exits. Instead clear it at the start of each iteration of
pipe tests but only if we just finished testing a different pipe.
* Get rid of outdated comment about test_ctx_flip_detection() being limited to a
single pipe
* Clarify comments describing guarding against CRC collisions in
test_ctx_flip_detection()
* Make a small doc blurb for test_ctx_flip_detection(), it's a rather unusual
and nvidia-specific behavior
* Mention in test_ctx_flip_detection() that we also explicitly check that we've
skipped -exactly- one frame. tl;dr more then one frame is too slow, less then
one frame means a context flip just didn't happen when it should have.
* Also check that the flip threshold we set in
test_ctx_flip_threshold_reset_after_capture() isn't ignored by the driver
* s/(create|destroy)_colors()/\1_crc_colors/g
Changes since v3:
* Update .gitlab-ci.yml to make nouveau exempt from the test-list-diff
test, since all the cool kids are doing it and we don't care about
autotools for nouveau
Changes since v2:
* Fix missing include in tests/nouveau_crc.c, this should fix builds for
aarch64
Changes since v1:
* Fix copyright year in nouveau_crc.c
Reviewed-by: Jeremy Cline <jcline@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
|
|
__cancel_work_at_exit writes -1 to param "reset", with the intention
that it's "any available method". Hex values to numeric params should
be prefixed with 0x to be parsed as a number. Use the convention of %u
with -1 as is used elsewhere with the "reset" param.
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
igt_device_scan can now be used as a separate library which only depends
glib and libudev - some IGT internals are being stubbed in this case.
v2: (mostly) sort includes (Lucas)
Cc: Lucas De Marchi <lucas.de.marchi@gmail.com>
Signed-off-by: Ayaz A Siddiqui <ayaz.siddiqui@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
When opening a specific driver, open that driver. Once we have the
device fd, we can then do feature checks that the tests *actually*
require.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Petri Latvala <petri.latvala@intel.com>
|
|
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
igt_require_gem() is a pecularity of i915/, move it out of the core.
Similar opportunistic move of gem_reopen_driver() and
gem_quiescent_gpu().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
__drm_open_driver_another(int idx, ...) is a counterpart to
__drm_open_driver(..) with the following changes:
If device filters are provided the idx-th filter is used and the first
matching device is selected.
Consecutive calls to it, with increasing idx (starting from zero) are
guaranteed to return fd of a different /dev/dri/ node than the previous
calls or -1.
Counterparts to other existing drm_open_*() should be introduced in
similar fashion as the need arises.
v2: (Petri)
* try_modprobe if device is not found
* split kms_prime changes into a separate commit
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
This patch brings back support for multiple filters that was in the
original series by Zbyszek.
We can now take multiple, semicolon separated filters. Right now the
tests are using only the first filter.
v2: drop unnecessary check before for-loop (Petri)
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
New IGT command line argument --device, IGT_DEVICE enviroment and .igtrc
Common::Device were added to allow selecting device using device
selection API. See generated docs for device selection and lsgpu for
more details on filters.
NOTE: IGT_FORCE_DRIVER still works if no filter is selected. We may want
to deprecate it later.
NOTE2: This does not work with tests that open 2 or more devices (e.g.
kms_prime). The core is capable of doing multiple filtering
passes but we need to figure out how we want *open*() functions
to expose this capability.
v2 (Arek):
* remove functions acting on igt_device_card
* use only a single filter
v3 (Arek):
* typos, misspellings (Petri)
* add notes on IGT_FORCE_DRIVER and opening 2 or more devices
Cc: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
KMS is meant to be a (at least somewhat) generic userspace API. We do
not want nor need to add a special match function for every driver
ever written, that doesn't make sense, defeats the point of having
generic tests for a generic testsuite, and really doesn't scale.
Also add a comment so people don't try to add ever more of these.
Also, this means no autoloading for you, but really igt should
reinvent udev, and mostly this was needed for 2 reasons:
- CI configuration falling to pieces because tests unloaded a driver,
and then died before cleaning up.
- vgem, which is fake, and needs to be requested explictily.
We might want to throw that all out again, except for vgem.
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Deepak Rawat <drawat@vmware.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: "Ser, Simon" <simon.ser@intel.com>
Cc: Oleg Vasilev <oleg.vasilev@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Acked-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Simon Ser <simon.ser@intel.com>
Acked-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Petri Latvala <petri.latvala@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>
|
|
There is no guarantee that spinners are and will be implemented
using batches. As we have igt_spin_t, manipulate it through
igt_spin_* functions consistently and hide the batch nature.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
These helpers will be used to address amdgpu specific quirks and
features. They're implemented like the i915 and VC4 helpers.
In order for the string comparison to pick up "amdgpu" the buffer size
had to be expanded for __is_device. I've gone ahead and made it 12 bytes
to cover everything that's there right now.
v2: rebase
Cc: Leo Li <sunpeng.li@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
|
|
It's not operating on FD, and we've provided a nice reimplementation
that does. Let's use it instead.
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In order to add support for features specific to the VC4 driver, add
helpers for checking and requiring the driver like it's done for the
i915 driver.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
We force a reset on test exit so that we can rapidly cleanup after a
naughty test, it is not unknown for us to leave a queue of hanging
batches around. However, if we have also fiddled with the i915.reset
parameter in the meantime, this can leave the kernel unable to fulfil
our request (and those naughty batches continue to disrupt testing).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Acked-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
The only caller so far never passes NULL so no effects today.
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
|
|
The force option allows users to specify which driver they want that IGT
uses. Nonetheless, if the user has two or more loaded drivers in his
system, the force option will not work as expected because IGT will take
the first driver found at /dev/dri. This problem can be reproduced in a
QEMU VM that using Bochs and VKMS. This patch handles this scenario by
ensuring that IGT uses the forced module specified via IGT_FORCE_DRIVER.
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
This commit adds a new option for forcing the use of a specific driver
indicated via an environment variable.
v2 (Petri):
- Use an environment variable instead of command line
- Refactor the loop in __open_device
- Don't try to load kernel modules
v3 (Petri):
- Rebase and adjust to the driver loading changes
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: gustavo@padovan.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
|
|
Just a few little ioctl wrappers that v3d tests will use.
v2: Move the struct above the prototypes.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Petri Latvala <petri.latvala@intel.com> (v1)
|
|
Quite often on catastrophic failure the test leaves a long queue of
unterminated batches pending execution. Each runs until hangcheck fires
and skips onto the next, leaving us waiting for a very long time at test
exit.
On older kernels, this gracefully degrades into the existing mechanism.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
We only want to allow driver_open to match an unknown driver if asked for
DRIVER_ANY, so we need to double check.
Fixes: 9e5fa9112546 ("lib/drmtest: Move open device to separate function")
Reported-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
I fluked out as vgem was the initial mid value, hiding the worst of the
errors as i915 matched with DRIVER_ANY.
Fixes: 20087bf22698 ("lib: Use a bsearch to find the module name")
Reported-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Even with a small number of known drivers (6), a bsearch will take at
most 3 steps, whereas the linear search will take 3 steps on average. In
the future with more known drivers, the logN bsearch will be even more
advantageous.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Katarzyna Dec <katarzyna.dec@intel.com>
Reviewed-by: Katarzyna Dec <katarzyna.dec@intel.com>
|
|
While working on IGT code and during reviewes I've noticed that
it could be nice to have function that is opening particular device.
Let's move out conditions for opening device and rename __open_device
to __search_and_open() function.
v2: Refactored open_device even more by getting device name once and
returning fd for it. (Chris)
v3: Added name_size to __get_drm_device_name, removed unused is_X_device.
v4: Fixed cases with failing virtio_gpu
v5: Rebase, indent fixes
Signed-off-by: Katarzyna Dec <katarzyna.dec@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In a multi-device system there is no guarantee that the fd being probed
in intel_get_drm_devid() is the same as was opened earlier. Any cache
may outlive the fd, so is frought with lifetime issues. The primary
reason for caching the devid was to avoid extra ioctls in the
dmesg/strace, but hopefully all users now grab the id in their fixture
and not inside every function.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Katarzyna Dec <katarzyna.dec@intel.com>
Reviewed-by: Katarzyna Dec <katarzyna.dec@intel.com>
|
|
This is just a simple change to reflect the actual state. No rewording
yet, just a simple substitution in most visible places - docs, README
and paths.
There are probably some leftovers here and there, but we can let them be
for now, this is already well overdue.
v2: fixed couple of obvious leftovers pointed out by Petri
Cc: Petri Latvala <petri.latvala@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Since the introduction of debugfs/i915_drop_caches, we have offered the
ability to wait upon all outstanding batches. This is more efficient and
less error prone (one example is the use of context priorities, we have
to idle at the lowest in order not to jump over any low priority tasks
we want to wait upon) than trying to do it all in userspace. Though we
could if we wanted to, it's just easier to use the existing facility
designed for the purpose -- that we were already partially using!
Note that debugfs/i915_drop_caches has only existed since v4.2.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
It looks like there are some rogue processes running in CI that prevent
DRM_MASTER from being obtained. Dump the list of clients on failure to
make it more obvious what is being left behind.
v2: Fix up gtkdocs, meson build
References: https://bugs.freedesktop.org/show_bug.cgi?id=104157
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
If we asked to open a particular chipset and we find no matching device,
try again after attempting to load its module. Previously we only did
this for vgem, which is not automatically probed during boot, but if we
want to leave the module unloaded we have to try harder when we need the
device.
v2: DRIVER_* are already masks (and not shifts). Use a common
driver_open for both /dev/dri/cardX and /dev/dri/renderDX.
v3: Beware making local variables accidentally static scoped.
v4: Beware multiple threads trying and failing to open a device
v5: Fixed spelling of render (Petri)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
"other" was misspelled as "otehr". Fix it.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
As part of the general procedure for ensuring the GPU is idle, we also
want to ask the driver to flush its idle_worker. The idle_worker is
responsible for releasing both the driver's internal cache of buffers
and cache of state (such as the prolonged GT wakeref). By flushing the
idle_worker we ensure that each test (each caller needing an idle gpu)
has a clean slate; not carrying over caches from one test to the next.
Note this is a silent no-op for kernels that do not know about DROP_IDLE,
old bugs will remain.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
Also, we are _GNU_SOURCE, so simplify the conditions accordingly.
The next patch will remove _GNU_SOURCE everywhere else.
Reviewed-by: Eric Anholt <eric@anholt.net>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Acked-by: Petri Latvala <petri.latvala@intel.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
I spent too much time going wtf why does this test not run until
realizing that vgem is missing. This should help a lot for tests that
need multiple different drm drivers.
v2: Distinguish "any" and "other" (Chris).
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Simple copy and replace of the CUnit tests inside libdrm to form a basis
for further prime integration testing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
For an as of yet unknown reason, calling system("modprobe") from inside
igt/gem_wait causes kasan to spend 1-5 minutes copying the process
pagetables. This evaporates if we replace the fork-happy call to system
with a call to load the module using libkmod. So be it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
A lot of igt testcases need some GPU workload to make sure a race
window is big enough. Unfortunately having a fixed amount of
workload leads to spurious test failures or overly long runtimes
on some fast/slow platforms. This library contains functionality
to submit GPU workloads that should consume exactly a specific
amount of time.
Since v14: Since we are using multiple signals, walk list of batches
to terminate a batch to avoid using a single global batch. Cycle signals
between SIGRTMIN and SIGRTMAX properly.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: tomeu@tomeuvizoso.net
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
|
|
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: 9921aff583ac ("lib/drmtest: Take DRIVER_ANY into account when opening the DRM device")
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
|