Move power management related code to a separate library.
Initially this is done only for workarounds that apply to external
components. Modify the users of such workarounds accordingly.
This currently involves HD audio and SATA link power management.
For SATA link PM there's also code to save the previous settings,
to allow for resetting the values after we've finished testing.
Signed-off-by: David Weinehall <david.weinehall@intel.com>
Reviewed-by: Marius Vlad <marius.c.vlad@intel.com>
Signed-off-by: Marius Vlad <marius.c.vlad@intel.com>
Missed an error whilst rebasing and trying to modify the previous patch
to keep this function intact... Instead, I now have to add this patch to
restore gem_available_aperture_size() and its one usage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For many tests, the relevant aperture is not the ppGTT but the internal
global GTT managed by the kernel. Use this limit appropriately.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Slightly increase the stress by doubling the number of contending
threads and the number of times we try and use each ctx/fd.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Following conversion to __gem_execbuf() we need to consider that it
returns -errno when checking the result.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94117
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Different than kms_mmap_write_crc that captures the coherency issues within the
scanout mapped buffer, this one is meant for test dma-buf mmap on !llc
platforms mostly and provoke coherency bugs so we know where we need the sync
ioctls.
I tested this with !llc and llc platforms, BTY and IVY respectively.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This program can be used to detect when CPU writes in the dma-buf mapped object
don't land in scanout due cache incoherency.
Although this seems a problem inherently of non-LCC machines ("Atom"), this
particular test catches a cache dirt on scanout on LLC machines as well. It's
inspired in Ville's kms_pwrite_crc.c and can be used also to test the
correctness of the driver's begin_cpu_access and end_cpu_access (which requires
i915 implementation.
To see the need for flush, one has to run using '-n' option to not call the
sync ioctls which, via a rather simple CPU hog the system will trashes the
caches, while the test will catch the coherency issue. If you now suppress
'-n', then things should just work like expected.
I tested this with !llc and llc platforms, BTY and IVY respectively.
v2: use prime_handle_to_fd_for_mmap instead.
v3: merge end_cpu_access() patch with this and provide options to disable sync.
v4: use library's prime_sync_{start,end} instead.
v7: use CPU hog instead and use testing rounds to catch the sync problems.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This patch adds dma-buf mmap synchronization ioctls that can be used by tests
for cache coherency management e.g. when CPU and GPU domains are being accessed
through dma-buf at the same time.
v7: add sync invalid flags test.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This patch adds test_correct_cpu_write, which maps the texture buffer through a
prime fd and then writes directly to it using the CPU. It stresses the driver
to guarantee cache synchronization among the different domains.
This test also adds test_forked_cpu_write, which creates the GEM bo in one
process and pass the prime handle of the it to another process, which in turn
uses the handle only to map and write. Roughly speaking this test simulates
Chrome OS architecture, where the Web content ("unpriviledged process") maps
and CPU-draws a buffer, which was previously allocated in the GPU process
("priviledged process").
This requires kernel modifications (Daniel Thompson's "drm: prime: Honour
O_RDWR during prime-handle-to-fd") and therefore prime_handle_to_fd_for_mmap is
added to fail in case these lack. Also, upcoming tests (e.g. next patch) are
going to use it as well, so make it public and available in the lib.
v2: adds prime_handle_to_fd_with_mmap for skipping test in older kernels and
test for invalid flags.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This test has the following subtests:
- test_correct for correctness of the data
- test_map_unmap checks for mapping idempotency
- test_reprime checks for dma-buf creation idempotency
- test_forked checks for multiprocess access
- test_refcounting checks for buffer reference counting
- test_dup checks that dup()ing the fd works
- test_userptr make sure it fails when mmaping due the lack of obj->base.filp
in a userptr.
- test_errors checks the error return values for failures
- test_aperture_limit tests multiple buffer creation at the gtt aperture
limit
v2 (Tiago): Removed pattern_check(), which was walking through a useless
iterator. Removed superfluous PROT_WRITE from gem_mmap, in test_correct().
Added binary file to .gitignore
v3 (Tiago): squash patch "prime_mmap: Test for userptr mmap" into this one.
v4 (Tiago): use synchronized userptr for testing. Add test for buffer
overlapping.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This patch moves userptr definitions and helpers implementation that were
locally in gem_userptr_benchmark and gem_userptr_blits to the library, so other
tests can make use of them as well. There's no functional changes.
v2: added __ function to differentiate when errors want to be handled back in
the caller; bring gem_userptr_sync back to gem_userptr_blits; added gtkdoc.
v8: remove local_i915_gem_userptr from gem_concurrent_all.c to use the global
helpers instead.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The control subtest has been extended to check the execution flags for
all the rings that are present in the HW.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Unbreaks compilation fail.
Also appease gcc in gem_exec_basic because.
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
These caught an unexpected bug with clear colors (we'd get the last
executed clear's color in our new BO), while failing to catch the bug
I'd been hoping to find all along.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
create-bo-0 fails on the current kernel, and it's something I want to
fix.
v2: Use do_ioctl_err().
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
The pad subtest fails currently.
v2: Use do_ioctl() and do_ioctl_err().
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
When reducing the buffer count to fit into the aperture whilst aligned,
remember to adjust the pointer so that the batch is the last object!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we completely fill the lower 4G of address space with our alignment
objects, then we also need to mark the batch as requiring high-address.
Though the kernel should be reordering in this case...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The goal of the test is to exercise what happens when we fill the Global
GTT with the contexts. To that end, we only need to allocate 2/4GiB of
context objects, and can forgo filling each context with buffers.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94005
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When testing surface eviction we don't need that many surfaces as we
mlock surplus memory. Reducing the number of surfaces speeds up the test
and prevents a couple of integer overflow bugs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94004
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
All the external viewer expects of the GPU error capture is to extract
the exact batch that triggered the hang. Everything else is internal
detail to aide in post-mortem debugging of the kernel driver (i.e.
subject to change) and not of the userspace portion (under control of
the test).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
ringfill generates a few very common errors when submitting requests,
and historically these have been where we have had many implementation
bugs, repeated over and over again.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Now that gem_require_ring() does the right thing with BSD1/BSD2 we can
use it to our advantage here.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
BSW does not allow CRTC 0 to be used on every connector, so we need to
write code to actually find a suitable CRTC.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93124
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Unused ever since we moved some code from pm_rpm.c to lib/. This is
currently defined inside igt_aux.c.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
I recently had this discussion with Daniel where I didn't want to use
igt_drm_format_to_bpp() because it uses the format_desc array, and
igt_fb currently assumes that all the format_desc formats have a
matching valid Cairo format, so I wouldn't be able to easily add
formats such as ARGB2101010.
The function that has the assumption mentioned above is
igt_get_all_formats: its current users call igt_get_all_formats, and
then call cairo-dependent functions, such as igt_get_cairo_ctx on the
returned formats.
In order to document the current behavior and prevent any problems in
case we start adding new formats without matching Cairo versions to
format_desc, rename igt_get_all_formats to igt_get_all_cairo_formats
and make it explicitly check for CAIRO_FORMAT_INVALID.
Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
A few other tests I have updated recently to use MI_STORE_DWORD also need
the magic bit for gen4/5.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
bit22 of MI_STORE_DWORD is confusing as the meaning changed between
physical/virtual addressing in early gen and GTT/ppGTT in later gen. It
looks like gen4 and gen5 still need the flag.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The first steps towards basic relocation handling. In today's edition,
we ask how well does the kernel fare if we pass it relocations via
mmappings of our buffer objects.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Missed from e3b68bb66683ad4cb4c80df904a3a21c98a2b6c2 due to rebasing
fun.
gem_reset_stats.c: In function 'inject_hang_ring':
gem_reset_stats.c:227:19: error: implicit declaration of function 'gem_exec' [-Werror=implicit-function-declaration]
gem_reset_stats.c:227:2: warning: nested extern declaration of 'gem_exec' [-Wnested-externs]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It just ends up with buffer leaks all over. On the flip side, it does
allow us to inherit the bufmgr directly without worry of stomping over
the aliased entries (and causing double closes).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order reduce the number of parameters being passed everywhere, whilst
simultaneously making more information available to the lower levels,
pass the struct buffers around.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since each engine has its own ring, each is subject to CS prefetching
and has its own layout that needs probing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I dropped this from the list of rings for some tests when refactoring to
a common array. Almost all of the tests should be run over the default
exec engine to ensure ABI backwards compatiblity.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
