Rename the current gem_mmap__{cpu,gtt,wc}() functions into
__gem_mmap__{cpu,gtt,wc}(), and add back wrappers with the original name
that assert that the pointer is valid. Most callers will expect a valid
pointer and shouldn't have to bother with failures.
To avoid changing anything (yet), sed 's/gem_mmap__/__gem_mmap__/g'
over the entire codebase.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Stochastically-reviwewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Do the following
ptr = gem_mmap__{cpu,gtt,wc}()
+igt_assert(ptr);
whenever the code doesn't handle the NULL ptr in any kind of
specific way.
Makes it easier to move the assert into gem_mmap__{cpu,gtt,wc}() itself.
Mostly done with coccinelle, with some manual cleanups:
@@
identifier I;
@@
<... when != igt_assert(I)
when != igt_require(I)
when != igt_require_f(I, ...)
when != I != NULL
when != I == NULL
(
I = gem_mmap__gtt(...);
+ igt_assert(I);
|
I = gem_mmap__cpu(...);
+ igt_assert(I);
|
I = gem_mmap__wc(...);
+ igt_assert(I);
)
...>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Stochastically-reviwewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Apply the new API to all call sites within the test suite using the following
semantic patch:
// Semantic patch for replacing drm_open_any* with arch-specific drm_open_driver* calls
@@
identifier i =~ "\bdrm_open_any\b";
@@
- i()
+ drm_open_driver(DRIVER_INTEL)
@@
identifier i =~ "\bdrm_open_any_master\b";
@@
- i()
+ drm_open_driver_master(DRIVER_INTEL)
@@
identifier i =~ "\bdrm_open_any_render\b";
@@
- i()
+ drm_open_driver_render(DRIVER_INTEL)
@@
identifier i =~ "\b__drm_open_any\b";
@@
- i()
+ __drm_open_driver(DRIVER_INTEL)
Signed-off-by: Micah Fedke <micah.fedke@collabora.co.uk>
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Add a header that includes all the headers for the library. This allows
reorganisation of the library without affecting programs using it and
also simplifies the headers that need to be included to use the library.
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
We should be able to create small and moderate sized objects quickly and
without errors.
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Daniel complained that all the tests in gem_mmap.c were too quick. This
one aims to rectify that by double checking that if we mmap a buffer
larger enough to force swapping, everything still works.
Also fix the test to exercise the different object sizes!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Move function CPU mmap test of large bo to gem_mmap, and include a
page-by-page copy between two huge objects (as we have had many bugs
triggering pagefault-of-doom for full apertures before).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
gem_mmap seg faults when all tests are run together. This occurs because
the new-object subtest closes the gem object, but short-mmap assumes
it still exists. Thus gem_mmap__cpu() returns nil for addr and memset()
seg faults. This patch makes new-object and short-mmap create and
close their own gem objects.
Signed-off-by: Mike Mason <michael.w.mason@intel.com>
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
All the cases that simply dump some debug information and couldn't be
converted to some of the fancier macros.
Some information output removed when it's redundant with the subtest
status.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the past new testcases with subtest often forgot to add the call to
igt_exit at the end of their main() function. That is now caught with
a bit more obnoxious asserts, but it's still a nuissance.
This little igt_main macro takes care of that (and also of calling the
subtest machinery initialization code correctly).
If no one objects I'll roll this out for all the simple cases (i.e.
those tests that don't have additional argv parsing on top of the
subtest machinery).
v2: Roll it out across the board.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I wanted to write a testcase for gtt mmap access restriction checking
and only noticed after conversion to subtests that this here is for
cpu mmaps ;-)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When looking at the pwrite/pread/wc performance, it is useful to judge
that against the performance of an ordinary CPU mmap.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After bf79cb914dbfe848add8bb76cbb8ff89110d29ff, drm uses ENOENT to
report unknown handles buffer objects, update the tests accordingly.
Fixes:
Bug 29794 - some intel_gpu_tools cases fail
https://bugs.freedesktop.org/show_bug.cgi?id=29794
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
