| Age | Commit message (Collapse) | Author |
|---|
|
pthread_create() expects a void *(*start_routine) (void *). Fix warning
the following warning on gcc 8:
../tests/sw_sync.c:773:37: warning: cast between incompatible function types from ‘int (*)(void *)’ to ‘void * (*)(void *)’ [-Wcast-function-type]
pthread_create(&threads[i], NULL, (void * (*)(void *))
^
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
gem_render_copy requires a working GPU so check first.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Mark up gem_pwrite_pread's dependence on a functioning GPU, by calling
igt_require_gem in its setup fixture.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Distinguish between the latency required to switch away from the
pollable spinner into the target nops from the client wakeup of
synchronisation on the last nop.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
To further defeat any contemplated spin-optimisations to avoid the irq
latency for synchronous wakeups, increase the queue length.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
Apply a different sort of stress by timing how long it takes to sync a
second nop batch in the pipeline. We first start a spinner on the
engine, then when we know the GPU is active, we submit the second nop;
start timing as we then release the spinner and wait for the nop to
complete.
As with every other gem_sync test, it serves two roles. The first is
that it checks that we do not miss a wakeup under common stressful
conditions (the more conditions we check, the happier we will be that
they do not occur in practice). And the second role it fulfils, is that
it provides a very crude estimate for how long it takes for a nop to
execute from a running start (we already have a complimentary estimate
for an idle start).
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>
|
|
When using the pollable spinner, we often want to use it as a means of
ensuring the task is running on the GPU before switching to something
else. In which case we don't want to add extra delay inside the spinner,
but the current 1000 NOPs add on order of 5us, which is often larger
than the target latency.
v2: Don't change perf_pmu as that is sensitive to the extra CPU latency
from a tight GPU spinner.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com> #v1
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> #v1
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
In order to make adding more options easier, expose the full set of
options to the caller.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Add a new subtest that does renders the test pattern into a
compressed buffer. And we'll follow it up with another copy
back to an uncompressed buffer so that we also test the
capability to sampled from compressed buffers, and also so
that we can actually compare the results against the reference
image.
We'll also do a quick check of the aux surface to check that
it actually indicates that at least some parts of the buffer
were in fact compressed. Further visual verification can be
done via the dumped png.
v2: Test various tiling formats with CCS as well
Combine the ccs test into the same function as
the rest
Pass the correct thing to intel_gen()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Make sure our rendercopy implementations do the right thing with
tiled buffers.
For now we'll just do linear->linear, x-tiled->x-tiled, and
y-tiled->y-tiled. Not sure there's much point in adding tests
for different src vs. dst tiling modes?
v2: Test all tiling combos (Chris)
Allocate with drm_intel_bo_alloc_tiled() (Chris)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Store a bit of aux surface state in igt_buf. This will be needed
for rendercopy AUX_CCS_E color compression.
We also have to sprinkle memset()s and whatnot all over to make
sure the current igt_buf users don't leave the aux stuff full
of stack garbage.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As we want to compare a templated tiling pattern against the target_bo,
we need to know that the swizzling is compatible. Or else the two
tiling pattern may differ due to underlying page address that we cannot
know, and so the test may sporadically fail.
References: https://bugs.freedesktop.org/show_bug.cgi?id=102575
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
If the GPU is not usable, we will not be able to submit workloads to be
measured and so observing them will fail.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
Checking whether we can copy solid rectangles isn't particularly
robust. Eg. errors in texture coordinates/interpolation wouldn't
necessarily show up at all because all texels are identical.
Let's switch to a more elaborate pattern that should catch such
errors. And we'll also change the test to not start the copy
from position 0,0 in the texture.
We'll generate the reference image (against which the rendercopy
results are compared) by peforming an identical copy using the
cpu.
v2: Use gtt mmap instead of pread/pwrite (Chris)
Offset the dst coordinates by -1,-1 to make sure
the copy doesn't go past the intended region
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
If we allow 5s (+20% systematic error) to construct the fences, we may
reasonably assume that it will take equally as long to consume them. As
we only have 10s before the vgem fence times out, there is no margin of
safety. Err on the side of safety and reduce it down to 2s, we won't test
importing as many fences simultaneously, but after the first full pages
we should be good at spotting errors!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The goal of gem_exec_gttfill is to exercise execbuf under heavy GTT
pressure (by trying to execute more objects than may fit into the GTT).
We spread the same set of handles across different processes, with the
result that each would occasionally stall waiting for execution of an
unrelated batch, limiting the pressure we were applying. If we using a
steaming write via a WC pointer, we can avoid the serialisation penalty
and so submit faster.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
These tests exercise an obscure piece of libdrm_intel API to keep the
number of VMA opened in a process under a certain limit (only ever used
by UXA as once upon a time we ran into the limit with many, many 1x1
pixmaps or something like that). The tests are not exercising kernel API
(or ABI) and need to check their resource requirements first. However,
since they are only testing libdrm_intel, remove them from igt as they
would better belong in a libdrm_intel test suite.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106010
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
Distributions want explicit control over optional parts so they can
state runtime dependencies before building. Let's restore the
functionality autotools used to provide.
Where possible, the selection is done by choosing whether to build a
particular item and the option name is build_$item. Example:
build_overlay. Where not possible, the option name is
with_$item. Example: with_valgrind.
Array options require a bump of required meson version to 0.44. Debian
stable has meson 0.37 which is already too old, stable-backports has
0.45, CI uses 0.45. Mesa's meson requirement is 0.44.1, for a
perspective.
Note, the old hack for not building docs when cross-compiling is
gone, as doc building can be explicitly controlled now.
v2: glib not optional
v3: bump meson version to 0.44
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Eric Anholt <eric@anholt.net>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This make perf tests to run in Icelake.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
This patch fix the following gcc warnings:
warning: ISO C90 forbids mixed declarations and code
[-Wdeclaration-after-statement] [..]
igt_color_encoding.c:45:2: warning: ISO C90 forbids mixed declarations
and code [-Wdeclaration-after-statement] [..]
igt_color_encoding.c: In function ‘ycbcr_to_rgb_matrix’:
igt_color_encoding.c:72:2: warning: ISO C90 forbids mixed declarations
and code [-Wdeclaration-after-statement] [..]
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Katarzyna Dec <katarzyna.dec@intel.com>
|
|
We want to make sure RT tasks which use a lot of CPU times can submit
batch buffers with roughly the same latency (and certainly not worse)
compared to normal tasks.
v2: Add tests to run across all engines simultaneously to encourage
ksoftirqd to kick in even more often.
v3: More passes to improve measurement stability.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Wait until the previous nop batch is running before submitting the next.
This prevents the kernel from batching up sequential requests into a
a ringfull, more strenuous exercising the "lite-restore" execution path.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Katarzyna Dec <katarzyna.dec@intel.com>
|
|
As we hang ctx0 quite frequently, it needs to be harden against being
banned.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
During a review came across a line of commented code. No specific reason
for the line is given so remove it.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Antonio Argenziano <antonio.argenziano@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
sw_sync/sync_multi_consumer_producer was communicating between threads
using the sw_sync ioctl and manipulating a shared volatile counter.
However, the ioctl itself does not imply a memory barrier, and so
different CPUs may see different states of the counter (the volatile
making GCC perform the operation in stages making the race even more
likely). Instead of using volatile, use locked operations to make the
counter manipulation thread-safe.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106344
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
We're little bit too enthusiastic in our initial attempt to lock all
available memory. Let's use the mlock probe from lib rather than trying
to lock everything that sysinfo.freeram has to offer.
Note that we're only tweaking the initial step - it's still possible
that we're going to get killed later on.
v2: Just increment lock instead of modifying addr passed to mlock
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ewelina Musial <ewelina.musial@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ewelina Musial <ewelina.musial@intel.com>
|
|
We already have the routine we need in drv_suspend. Let's move it to lib
and use it in the mlocking tests. We can also make it a bit faster if we
tweak the initial step and initial amount.
(I think it's safe to assume that we should be able to lock 3/4
of RAM, this cuts the probe time on my 32G SKL - from ~530s to ~180s)
v2: Use available mem, amend step, also lock outside of fork,
early exit if the assumption is wrong (Chris)
Update the function name in doc (Ewelina)
v3: Total for pin, available for initial lock (Chris)
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ewelina Musial <ewelina.musial@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ewelina Musial <ewelina.musial@intel.com>
|
|
All subtests send a workload to the engines and then return without
waiting on it, while this is not a problem because the test targets the
API, it makes the hang detector pointless since the driver will declare
an hang long after the test has completed.
v2:
- Use common functions to create/terminate a batch. (Chris)
Signed-off-by: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
As the swizzling is baked into the tiling pattern, the swizzling has to
be consistent across the entire GTT mmap for our tests to work. However,
under L-shaped memory configurations on older architectures, the
swizzling varied depending on which region the page found itself in --
invalidating our assumptions and ability to predict the tiling pattern.
Reported-by: Adric Blake <promarbler14@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106848
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Recently we discovered that we have a race between swapping and
suspend in our resume path (we might be trying to page in an object
after disabling the block devices). Let's try to exercise that by
exhausting all of system memory before suspend.
v2: Explicitly share the large memory area on forking to avoid running
out of memory inside the suspend helpers (for they fork!)
References: https://bugs.freedesktop.org/show_bug.cgi?id=106640
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
Insted of just trying out each pixel format once, let's try each one
with a set of colors (RGB,CMY,white,black). We'll grab a reference CRC
for each using XRGB8888, and then compare that with the CRC we get
with any other format.
We have to use a solid color fb because chroma subsampling would
generally prevent us from getting a match if we had any color
transitions in the fb contents.
We also abuse the legacy LUT to drop the precision down to 6 bits
so that still errors causes by the RGB<->YCbCr conversion end up
being ignored.
v2: don't set Broadcast RGB prop if it's not there
v3: Drop the Broadcast RGB prop since igt_kms already does it (Maarten)
v4: Don't check ARGB8888 twice on cursors
Add vblank wait after the commit to make sure we grab the crc
for the new fb
Don't turn the plane off between every check
Fix the commit message to say we keep only 6 msbs, 7 is too much
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v3
|
|
Batches are constrained in their position within the GTT by the kernel,
and if they are in an invalid position will be unbound and rebound
before execution. In our test setup, we therefore need to place the
batch into a valid poistion within the GTT before we fill the ring with
busyspinners.
The problem entirely lies in how we are constructing our set of busy
spinning batches. We try to fill the ring with a chain of batches that
are all linked to one buffer, and then try to execute that buffer. This
gives us the most implicit fences on that one buffer we can trivially
construct; with the goal being that the kernel handles them all with
aplomb. However, what we failed to take into account was that we might
end up with that final buffer being at address 0, which is in an invalid
location to execute from (because reasons) and the kernel would be
forced to move it. However, since we have a ring full of busy spinners
all using that buffer, we can not move that buffer until we wait for the
queue to complete -- which it never will and so we declare a GPU hang,
failing the test.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Katarzyna Dec <katarzyna.dec@intel.com>
|
|
Add some various test suites relevant for the vc4 drm driver.
Acked-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
glk is failing gem_tiled_blits which is very odd as it doesn't use
fencing and so the tiling is all internal to the GPU. From the small
number of examples seen so far, it looks like just a single bit is being
flipped. Let's dump some values to see if it there is a larger pattern
here.
Furthermore since gem_linear_blits is also showing bitflips on glk, we
can rule out the impact of tiling altogether! It just becomes a question
of which piece of hw is broken...
References: https://bugs.freedesktop.org/show_bug.cgi?id=106608
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
|
There is a chance new kernel or new firmware fixed the CPU0 hotplug hang
issue. Remove the skip to check if that's true.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Jani Saarinen <jani.saarinen@intel.com>
|
|
We may not idle immediately after a hang, and indeed may send a pulse
down the pipeline periodically to become idle. Rather than make a flimsy
assumption about how long we need to sleep before the system idles,
wait for the system to declare itself idle; flushing it to idle in the
process!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>
|
|
Lionel pointed out that INSTPM was context saved, at least from gen6,
not from gen9. The only caveat is that INSTPM is a masked register (the
upper 16bits are a write-enable mask, the lower 16bits the value to
change) and also contains a read-only counter bit (which counts flushes,
and so flip flops between batches). Being a non-privileged register that
userspace wants to manipulate, it is writable and readable from a
userspace batch, so we can test whether or not a write from one context
is visible from a second.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
As the test notes, DRM_FORMAT_ARGB8888 is broken for CRC comparison,
and should not be used on gen9-gen10.
DRM_FORMAT_C8 failed on my glk, because it was running into the pitch
pixel limit when 4 * width is used. Track bpp correctly, and use it with
igt_get_fb_tile_size to get a more accurate size without reinventing
the wheel.
Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106641
|
|
The legacy test fails because it tries scaling on pipe C,
because the single scaler is already used for CRTC scaling.
On other pipes and newer gens we have 2 scalers, so special
case pipe C here.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105456
[mlankhorst: Add ickles comment.]
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Two tests uses the very same wait_for_pageflip() routine. These tests are
'kms_rotation_crc' and 'kms_flip_tiling'. In order to decrease code
repetition, let's move this function as part of kms function collection
in igt_kms.
No functional changes.
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
We can override the connector status/EDID just fine even if the
thing is already connected. So let's not skip in that case.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The 9x9 was maybe a workaround for the kernel's rounding behaviour?
The kernel was changed so that's no longer necessary. So let's go
for 8x8 since that actually works with YUV formats.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
|
|
YUV formats require the clipped src coordinates to be suitably aligned.
We'd need to very carefully compute the unclipped dst coordinates to
guarantee that. That's too much hassle so let's just accept failure in
case YUV formats are used.
v2: Actually remove the original igt_display_commit2() (Maarten)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
|
|
Clear the igt_fb struct to make sure no stack garbage is left in any
members we don't explicitly initialize.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
|
|
Ask from kernel about supported modes for each plane and try setting
them on display and verify functionality with crc.
DRM_FORMAT_ARGB8888 and DRM_FORMAT_ABGR8888 skip crc testing on
primary and overlay planes because they produce incorrect crcs from
hardware. DRM_FORMAT_ARGB8888 is tested on cursor plane.
v3: address review comments from Mika Kahola.
Stop crc at end of test before freeing it. Use libdrm instead
of mixing ioctl and libdrm.
v2: Address review comments from Mika Kahola.
Keep crc running for all tests while on same pipe, set tile height
to 16 and read only one crc per test.
Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
The test wrote to the same dwords from multiple contexts, assuming that
the writes would be ordered by its submission. However, as it was using
multiple contexts without a write hazard, those timelines are not
coupled and the requests may be emitted to hw in any order. So emit a
write hazard for each individual dword in the scratch (avoiding the
write hazard for the scratch as a whole) to ensure the writes do occur
in the expected order.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Consistent with other function signatures in the file.
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com>
|
|
After the initial plane setup, only the test plane is required. One
exception is clean_up where the primary is required, but a call to
igt_output_get_plane_type() can get us that.
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com>
|
