3 Commits

Author SHA1 Message Date
Daniel Vetter
c644c55177 tests/kms_mmap_write_crc: Use the right fork helpers
For a background task the fork helpers are more appropriate, since we
can explicitly cancel children. Also, anything that does real work is
supposed to be in fixtures.

Cc: Tiago Vignatti <tiago.vignatti@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

--
Tiago, can you pls check that I haven't broken anythig?

Thanks, Daniel
2016-03-08 17:12:04 +01:00
Chris Wilson
aed69b56d4 lib: Add read/write direction support for dmabuf synchronisation
Allow read-only synchronisation on dmabuf mmaps, useful to allow
concurrent read-read testing between the CPU and GPU.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-03-01 13:25:07 +00:00
Tiago Vignatti
7c89c9d734 tests: Add kms_mmap_write_crc for cache coherency tests
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>
2016-02-11 18:16:20 +01:00