| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
We already pass the crtc id, so use the id to retrieve the index.
We'll change the way we pass the crtc id in the next commits, so we'll
have to call a function to calculate the index based on the id at that
point. Do the change now in order to avoid big commits later.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
Move it from pm_rpm.c to lib/igt_kms and remove the hardcoded version
from kms_frontbuffer_tracking. I'm also planning to add other callers.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
This test executes one of each of the very basic operations with
whatever features are enabled by default in the Kernel, without
checking their statuses: we only care about the CRCs. Although it's
completely redundant, it will be ran by the CI so we can spot
regressions both in the specific features and in the frontbuffer
tracking subsystem.
We're not checking sink CRCs since they're still unreliable and we
don't want false negatives in the CI.
It takes 5 seconds to run this test on my machines.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
SKL doesn't do the same dspaddr_offset magic as the older gens, so FBC
may not be enabled on fbc-farfromfence. This is not a bug since FBC is
just disabled, and this is the expected case of the current Kernel, so
let's not fail the test.
If/once we land the proper infrastructure to fix this in the Kernel we
may revert this commit.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
We want to make sure that both tiled and untiled buffers have the same
size for the same width/height/format. This will allow better control
over the failure paths exercised by our tests: when we try to flip
from tiled to untiled, we'll be sure that we won't execute the error
path that checks for buffer sizes.
v2: Use the new igt_calc_fb_size() instead of implementing our own
size calculation (Daniel).
v3: We can now use igt_drm_format_to_bpp() (Daniel).
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
The only format from fb_get_bpp() not supported by
igt_drm_format_to_bpp() is ARGB2101010, but we don't really use it in
kms_frontbuffer_tracking, so we can do the switch.
Adding ARGB2101010 to igt_fb won't be that simple since there's no
equivalent Cairo format, and igt_fb users assume that all formats
known by igt_fb have equivalent Cairo formats.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
igt_kms.c: In function ‘igt_crtc_set_background’:
igt_kms.c:1940:2: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘uint64_t’ [-Wformat=]
LOG(display, "%s.%d: crtc_set_background(%lu)\n",
^
intel_firmware_decode.c: In function ‘csr_open’:
intel_firmware_decode.c:169:2: warning: format ‘%zd’ expects argument of type ‘signed size_t’, but argument 3 has type ‘__off_t’ [-Wformat=]
printf("Firmware: %s (%zd bytes)\n", filename, st.st_size);
^
intel_gpu_top.c: In function ‘main’:
intel_gpu_top.c:683:10: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’ [-Wformat=]
stats[i] - last_stats[i]);
^
hsw_compute_wrpll.c: In function ‘main’:
hsw_compute_wrpll.c:644:3: warning: format ‘%li’ expects argument of type ‘long int’, but argument 7 has type ‘long long int’ [-Wformat=]
igt_fail_on_f(ref->r2 != r2 || ref->n2 != n2 || ref->p != p,
^
gem_gtt_hog.c: In function ‘__real_main155’:
gem_gtt_hog.c:177:2: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘unsigned int’ [-Wformat=]
igt_info("Time to execute %lu children: %7.3fms\n",
^
kms_flip.c: In function ‘run_test_step’:
kms_flip.c:985:3: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 10 has type ‘__time_t’ [-Wformat=]
igt_assert_f(end - start > 0.9 * frame_time(o) &&
^
kms_flip.c:985:3: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 11 has type ‘__suseconds_t’ [-Wformat=]
kms_frontbuffer_tracking.c: In function ‘setup_sink_crc’:
kms_frontbuffer_tracking.c:1364:3: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘ssize_t’ [-Wformat=]
igt_info("Unexpected sink CRC error, rc=:%ld errno:%d %s\n",
^
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Even with all sink crc re-works we still have platforms
where after 6 vblanks it is unable to calculate the
sink crc. But if we don't get the sink crc it isn't true
that test failed, but that we have no ways to say test
passed or failed.
So let's print a message and move forward in case sink crc
cannot help us to know if the screen has been updated.
v2: Also include a message on setup_sink_crc and also
only skip when it is mandatory, i.e. when running for PSR.
Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Unfortunately Sink CRC is not 100% reliable for all platforms.
So we cannot block FBC tests nor skip them when we are getting
unreliable Sink CRC results, or not getting them at all.
Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
With commit (drm/i915: Delay first PSR activation.) in kernel
PSR might take a bit longer to really activate after the modeset.
The first PSR activation after modeset is taking 5 times the panel
power cycle delay time, which is 600ms for our machines here.
So timeout here needs to be a minimum of 3s. However let's use
5s as the safe value in case we find machines with higher power
cycle delay.
Since we do a lot of assert(psr_disabled), this commit is increasing
the time it takes to run the whole set of PSR tests by a few minutes,
which had been reduced by commit f4db3b18841
("kms_frontbuffer_tracking: reduce the PSR wait timeout to 2s").
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Speeds up testcases except for those where we want to exercise the
probing itself. The only exceptions left where we do a full probe are
- pm_rpm: We use it to make sure the kernel doesn't get things wrong
with power domains, so we really want to exercise the full probe
paths. And there the only place really is the specific validation
done with the data gathered by get_drm_info.
- kmstest_force_ functions: Newer kernels should be better at
re-probing state when the force sysfs fields change, but better safe
than sorry.
v2: I also consolidated the start_n_modes and start_connectors while
at it - move one of the fixup hunks to this patch that accidentally
got misplaced (Thomas).
Cc: Thomas Wood <thomas.wood@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
During the review of a recent FBC patch, Ville pointed a problem that
happens when we use the page flip IOCTL to switch between buffers that
have different tiling formats. This test should catch the problem
introduced by that patch - which was not merged, by the way, so the
test should be passing.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
We use igt_create_fb(), which decides the stride by itself: there's no
guarantee that making a buffer 512 pixels bigger is going to make its
stride change.
I had a fix for this problem that was supposed to be applied before
this patch, but due to a rework request I'm changing the order of the
patches, so we should expect to hit this assertion for now. At least
the root cause of the problem is clear now.
v2: Update the commit message due to the patch order changing.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
Make those subtests try to change the stride using multiple APIs so we
can catch errors that affect full modesets, fast modesets and page
flips.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
Handle it just like we handle t->format. IMHO, it's better.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
Add a new FLIP_PLANES enum so we can do "page flips" using it too. The
goal is to exercise the fast modeset paths on the Kernel.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
|
|
Signed-off-by: Daniel Stone <daniels@collabora.com>
|
|
That option is not needed anymore since:
commit 982934625ac67234c6d85c6cf29a5a487e54d4f0
Author: Thomas Wood <thomas.wood@intel.com>
Date: Wed Sep 16 14:36:24 2015 +0100
lib: allow wildcard matching when specifying subtests
In fact, using "--run-subtest 'fbc-*'" is better than using --fbc-only
due to how SKIPs are handled. In the former, only the tests matching
the expression are tried, so the number of SKIPs only contains the
number of tests on the specified pattern that were skipped. If you
used --fbc-only, all the non-fbc tests would count as SKIPs, so it
would be harder to know which of the tests marked as skipped were
actual FBC tests.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
This is a corner case not exercised by the other subtests. The test is
expected to pass both with the current Kernel tree and with the
patches that are on the mailing list.
The patches currently on the mailing list change how the CFB is
allocated, and this subtest is designed to make sure everything still
works as expected.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
This will be used by the stridechange subtest.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
This fixes the failures for cases where you use --run-subtest to run
single subtests that don't use any drawing patterns.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
The current upstream Kernel code stops and then restarts FBC at every
page flip. I am working on patches to keep FBC enabled all the time,
so this brings the possibility of having the hardware tracking
mechanism looking at the old buffer instead of the new one. This test
should catch this problem.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
There's no reason to do a mode unset since we don't care about whether
FBC or PSR are enabled or disabled. This should save about a second
for each time you invoke the program.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
It's not testing a lot since we lack the Kernel Stolen Memory Checker,
but some day this will be useful.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
