| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Depending on the default mode size, some tests will fail because it
will exceed the maximum size that hardware tracking can handle,
mostly because hardware tracking do not take in care the X and Y
offsets, so the plane size + offsets needs be smaller or equal to
hardware tracking limmits.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105680
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>
|
|
The kms_frontbuffer_tracking@*suspend subtests spend 20 seconds
sleeping around igt_system_suspend_autoresume. I find no other
igt test that require sleeping in relation to suspend-resume, so
it should be removed.
Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
get_sink_crc() wants the eDP panel enabled to collect a CRC, but this
is already required for opening the pipe CRC. This was broken in the
conversion to igt_display, because the call to setup_sink_crc was moved.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105503
Reported-by: Marta Löfstedt <marta.lofstedt@intel.com>
|
|
subtest, v3.
This is hidden behind the other kms_frontbuffer_tracking failures,
but is its own fail.
On gen9/gen10 we fail the scaledprimary tests because FBC refuses
to be enabled with "plane Y offset is misaligned".
Looking at the kernel, this is a workaround for FIFO underruns
which can be tested as well. Test that with the right alignment, FBC
is enabled and with misalignment FBC is disabled on <= gen10.
Changes since v1:
- Always check both alignments.
Changes since v2:
- Fix gen assignment.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105678
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>
|
|
Kernel does not expose the "Active: " flag in edp_psr_status anymore.
So test for "HW Enabled & Active bit: yes", although this isn't completely
accurate either for frontbuffer tests. Let's go with this for now until
the kernel exposes HW PSR status.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105519
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>
|
|
When FBC cannot be enabled in one of the tests, we get a lot of repeated
spam at DEBUG level, which overwrites any good debug level data that you
can hope to get out of the test.
When running at the debug level, output FBC info only if changed from last
time, so we don't get the repeated spam.
This makes the debug info from CI slightly more useful.
Changes since v1:
- Clear last_fbc_buf in fbc_wait_until_enabled.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
[mlankhorst: Remove stray from igt_core.c]
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #irc
|
|
Straight conversion, no behavioral changes yet.
Changes since v1:
- Handle 2x outputs correctly.
Changes since v2:
- Set correct parameters in set_mode_for_params, so atomic commit for
2x outputs doesn't scale.
- Fix accidental scaling in set_prim_plane_for_params.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Mark drrs_set as static to avoid a build warning.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
for chipset support
If the machine doesn't support PSR, it will return -ENODEV from
i915_edp_psr_status, which we want to interpret as unsupported.
This is in line with what Chris just fixed for FBC.
V2: Copy-pasted to the correct place
Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
PSR may not exit instantaneously, so while asserting that PSR is
disabled after an action, we may have to wait a short while. Currently
that wait is waiting for PSR to enabled and expecting to timeout; this
fails when we start the assertion with PSR already enabled. Fix the wait
to wait until PSR is disabled rather than timeout.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
|
|
Dynamic Refresh Rate Switch(DRRS) is used to switch the panel's
refresh rate to the lowest vrefresh supported by panel, when frame is
not flipped for more than a Sec.
In kernel, DRRS uses the front buffer tracking infrastructure.
Hence DRRS test coverage is added along with other frontbuffer tracking
based features such as FBC and PSR tests.
Here, we are testing DRRS with other features in all possible
combinations, in all required test cases, to capture any possible
regression.
v2: Addressed the comments and suggestions from Vlad, Marius.
The signoff details from the earlier work are also included.
v3: Modified vblank rate calculation by using reply-sequence,
provided by drmWaitVBlank, as suggested by Chris Wilson.
v4: As suggested from Chris Wilson and Daniel Vetter
1) Avoided using pthread for calculating vblank refresh rate,
instead used drmWaitVBlank reply sequence.
2) Avoided using kernel-specific info like transitional delays,
instead polling mechanism with timeout is used.
3) Included edp-DRRS as a subtest in kms_frontbuffer_tracking.c,
instead of having a separate test.
v5: This patch adds DRRS as a new feature in the
kms_frontbuffer_tracking IGT.
DRRS switch to lower vrefresh rate is tested at slow-draw subtest.
Note:
1) Currently kernel doesn't have support to enable and disable
the DRRS feature dynamically(as in case of PSR). Hence if the
panel supports DRRS it will be enabled by default.
This is in continuation of last patch
"https://patchwork.freedesktop.org/patch/162726/"
v6: This patch adds runtime enable and disable feature for testing DRRS
v7: This patch adds runtime enable and disable feature for testing DRRS
through debugfs entry "i915_drrs_ctl".
v8: Commit message is updated to reflect current implementation.
v9: Addressed Paulo Zanoni comments.
Check for DRRS_LOW at tests with OFFSCREEN + FBS_INDIVIDUAL.
v10: Corrected DRRS state expectation in suspend related subtests.
v11: Removing the global flag is_psr_drrs_combo [Rodrigo].
v12: Rewriting the DRRS inactive deduction [Rodrigo].
v13: En/Dis-able DRRS only when DRRS is capable on the setup.
v14: Handle the error states of drrs_enable only [Rodrigo].
v15: Resolved compiler warning and rebased.
Signed-off-by: Lohith BS <lohith.bs@intel.com>
Signed-off-by: aknautiy <ankit.k.nautiyal@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
bpp is only sufficient to calculate dimensions for packed formats, in
case of planar formats we need to pass the drm format fourcc, which
will give us better information.
This is required for supporting planar framebuffers.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
Currently, we have a sporadic failure in the multidraw tests where it
sometimes fails to start FBC in a timely fashion (and at other times
works fine). Try to get a little more information as wait it is waiting
for by showing the fbc status at each stage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
When reading CI failure reports seeing an "assertion false failed" is
confusing as you then have to look for the preceding explanation. Show
the actual condition that fails in the assert report. Note that this
gives the system a chance at a reprieve and avoids conflicting
information such as:
(kms_frontbuffer_tracking:1649) DEBUG: Test requirement passed: !fbc_not_enough_stolen()
(kms_frontbuffer_tracking:1649) DEBUG: Test requirement passed: !fbc_stride_not_supported()
(kms_frontbuffer_tracking:1649) INFO: FBC status:
FBC disabled: FBC enabled (active or scheduled)
(kms_frontbuffer_tracking:1649) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1714:
(kms_frontbuffer_tracking:1649) CRITICAL: Failed assertion: false
(kms_frontbuffer_tracking:1649) CRITICAL: FBC disabled
Where the fbc status tells us that it was indeed enabled, but the
assertion still failed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
As the system may use a partial vma for a GGTT mmap, access via the GGTT
mmap is not guaranteed to be tracked by FBC's fence. The rule expressed has
been that any access to the frontbuffer should be followed by a fb-dirty
ioctl, so always apply and expect the driver to ellide no-ops.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
In commit 3f6ae7b19 ("igt/kms_frontbuffer_tracking: Keep the debugfs
dir around") we introduced custom variant of __igt_debugfs_read function
that fires assert when debugfs returns an error. Replace that assert
with proper error handling to allow use of errors like -ENODEV.
v2: allow only -ENODEV (Chris)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Macros that should be C functions but aren't are really hard to
read and confusing. Convert them over.
v2: Clean up commit message and keep printing the line numbers (Paulo).
v3: Actually git add (silly me).
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Allow tests to create Y-tiled bufferes using a separate
argument to the test without increasing the number of
subtests.
v2: Changed tiling option to string (Paulo)
v3 (from Paulo): minor nitpicks.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Praveen Paneri <praveen.paneri@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
The multidraw subtest was not taking whether or not the GEM buffer had
ever been in write-combining mode when checking for PSR state, so fix
that.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
|
|
Commit 2804afc606f8 ("kms_frontbuffer_tracking: fix compression
checking") removes the check whether the kernel supports reporting the
compression status before asserting on it. This breaks the test for
no good reason on old CPUs (SNB and earlier) where the kernel can't
report the compression status. Instead, we can check if the cpu
doesn't support reporting and adopt the same behavior as if
--no-fbc-compression-check was used.
Changes since v1:
- Move verification to setup_fbc (Paulo)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100677
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
DRM_EVENT_CONTEXT_VERSION is the latest context version supported by
whatever version of libdrm is present. igt was blindly asserting it
supported whatever version that may be, even if it actually didn't.
With libdrm 2.4.78, setting a higher context version than 2 will attempt
to call the page_flip_handler2 vfunc if it was non-NULL, which being a
random chunk of stack memory, it might well have been.
Set the version as 2, which should be bumped only with the appropriate
version checks.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
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>
|
|
The pipe is of particular relevance when checking for FBC/PSR
compatibility, and easier to understand than its KMS object id.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In the new atomic reality, the page flip in the end of the badstride
test succeeds. That flip is to an fb which has a stride too large to
allow FBC to be enabled. Adjust the test expectations accordingly.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
Stride change through page flip is now allowed.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
On a 4k hdmi display the stride might be too high for fbc to be
enabled, in this case skip the test entirely.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
Don't forget to mark the CRC as not supported if there are no eDP
panels.
Regression introduced by:
commit 8aa7ea4f84b0e1384b78f4cc9b136ea5b641055a
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
kms_frontbuffer_tracking: refactor sink CRC reliability handling
v2 (from Paulo):
- Convert Petri's email patch to an actual git patch
- Add an extra assertion, just in case
- Add Petri's s-o-b tag (authorized via IRC)
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
Ever since Kernel's "drm/i915: don't report compression when fbc is
disabled" we've been wrongly assuming that the Kernel doesn't support
compression information due to the fact that it doesn't print that
specific line when FBC is not active. Fix this by just assuming that
the Kernel supports it, allowing us to kill some more code.
With this change, running a brand new kms_frontbuffer_tracking on
super old Kernels will result in failures, but I suppose that's fine
for IGT.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
Don't just destroy the ones from the default format.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
What I'm currently seeing is that sometimes the first check during
setup_sink_crc() returns valid sink CRC, but then the subsequent
checks return ETIMEDOUT. In these cases, we keep getting flooded by
messages saying that our sink CRC is unreliable and that the results
differ. This is annoying for the FBC tests where sink CRC is not
mandatory.
Since this case shows it's useless to try to check for sink CRC
reliability before the actual tests, refactor the code in a way that
if at any point we detect that sink CRC is unreliable we'll mark it as
such and stop flooding the logs. For the tests where it's mandatory
we'll still keep the same SKIP behavior.
This refactor also allows us to just call get_sink_crc() in the
setup_sink_crc() function instead of having to reimplement the same
logic.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
Make it check for the supported flag and decide what to do. This
change will make the next patches much easier, and it's probably
better to move more sink CRC logic to the sink CRC function.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
If we already detected an error, don't try to assert the size of what
we didn't read.
In machines where the sink CRC is unreliable, this was failing tests
where the sink CRC is not mandatory (FBC tests). With this change we
won't fail anymore, we'll just print error messages saying that the
sink CRC is unreliable.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
A raw pageflip is nonblocking and asynchronous, but
kms_frontbuffer_tracking persumed that it was synchronous and completed
before the funtion returns. It doesn't, so the CRC could be sampled
before the flip completed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Not all hw or kernels supply an overlay plane, so don't assert it's
presence and just skip the test instead in its absence.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
To have a more accurate idea about any suspend/resume issues we can
perform the s/r until various phases in the s/r sequence. This way we
can isolate the given problem as being a device driver, kernel core or
BIOS related issue. Actual subtests using these new s/r phases will be
added as follow-up.
While at it also add the freeze suspend target, it's something we also
would need to test.
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
The new Kernel behavior is that whenever a buffer has ever been WC
mmapped, the GTT mmaps will be treated as CPU operations. Because of
this, if we don't issue the dirty_fb IOCTL after doing frontbuffer
rendering with the GTT mmaps, FBC will remain disabled. Luckily, the
only subtest that does this sort of mix is the multidraw subtest.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
This patch was originally written because of a workaround we were
planning to merge. Later we improved the workaround so it wouldn't
need this patch anymore. Then later we gave up on the workaround, but
decided to go with a plan that would cause GTT mmap writes to
invalidate FBC in case the frontbuffer ever had a WC mmap. So now we
need the patch again because we don't want a subtest that involves an
WC mmap to change the behavior of other unrelated subtests that use
GTT mmaps.
Even if we don't go with the current planned Kernel patch, merging
this should be worth in order to avoid future related problems.
v2: New commit message.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
A recent Kernel fix changed the way GTT and WC mmaps behave during
frontbuffer drawing. This, added with the fact that GTT mmaps are
special cases for PSR, suggests that maybe we should move to BLT
drawing in places where we can, in order to simplify things a little
bit.
v2: New commit message.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
Use the pipe which is given from the possible_crcs for that connected port
instead.
On BSW there are constrains for the crtc<-->connector, this fix make this test
passing on BSW.
v2 (from Paulo): bikeshed the blank lines.
Signed-off-by: Gabriel Feceoru <gabriel.feceoru@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
Let's be good citizens and properly handle our garbage.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
All the tests I wrote always assumed that every connector supported
CRTC 0. This is not the case for BSW and possibly others, so fix the
tests before the CI reports more failures.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
Instead of just giving preference to an eDP primary connector, give
preference to one that's eDP and supports pipe A, then try lesser
optimal combinations later.
We could try to make our test suite use different sets of connectors
when testing FBC and PSR, but that would require some rework, and we
would still be helpless when testing the combination of FBC+PSR.
Also notice that we still hardcode pipe A for the primary connector,
regardless of whether it supports it. This will be solved in the next
commits.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
We're going to make our search for connnectors a little more
complicated, so extract the function since we're going to call it a
few more times.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
