diff mbox series

[RESUBMIT,v2] tests/prime_vgem: Skip basic-read/write subtests if no mappable GGTT

Message ID 20191126123103.20157-1-janusz.krzysztofik@linux.intel.com (mailing list archive)
State New, archived
Headers show
Series [RESUBMIT,v2] tests/prime_vgem: Skip basic-read/write subtests if no mappable GGTT | expand

Commit Message

Janusz Krzysztofik Nov. 26, 2019, 12:31 p.m. UTC
As we've agreed that using I915_GEM_PREAD/PWRITE IOCTLs on dma-buf
objects doesn't make much sense, we are not going to extend their
handlers in the i915 driver with new processing paths required for them
to work correctly with dma-buf objects on future hardware with no
mappable aperture.  When running on that kind of hardware, just skip
subtests which use those IOCTLs.

v2: Examine pread/pwrite ABI, not mmap ABI (Chris)

Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
Resubmitting with Joonas' email address in Cc: tag corrected, as well
as changelog added on having Chris' comment addressed, Cc: Chris.

 lib/ioctl_wrappers.c | 2 +-
 lib/ioctl_wrappers.h | 1 +
 tests/prime_vgem.c   | 6 ++++++
 3 files changed, 8 insertions(+), 1 deletion(-)

Comments

Chris Wilson Nov. 26, 2019, 12:41 p.m. UTC | #1
Just s/no mappable GGTT/not supported/

Quoting Janusz Krzysztofik (2019-11-26 12:31:03)
> As we've agreed that using I915_GEM_PREAD/PWRITE IOCTLs on dma-buf
> objects doesn't make much sense, we are not going to extend their
> handlers in the i915 driver with new processing paths required for them
> to work correctly with dma-buf objects on future hardware with no
> mappable aperture.  When running on that kind of hardware, just skip
> subtests which use those IOCTLs.
> 
> v2: Examine pread/pwrite ABI, not mmap ABI (Chris)
> 
> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>

I like this. We are not here to prove gem_read/gem_write
themselves work (if we haven't done that already, we've lost), but
whether they work in conjunction with the dmabuf.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

I still have a bad feeling about any API change not accompanied by a
separate parameter to indicate the change (just from the discoverability
aspect of the API), but as proven, an introspection API is not required
here.
-Chris
diff mbox series

Patch

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 628f8b83..78b92bd2 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -356,7 +356,7 @@  void gem_write(int fd, uint32_t handle, uint64_t offset, const void *buf, uint64
 	igt_assert_eq(__gem_write(fd, handle, offset, buf, length), 0);
 }
 
-static int __gem_read(int fd, uint32_t handle, uint64_t offset, void *buf, uint64_t length)
+int __gem_read(int fd, uint32_t handle, uint64_t offset, void *buf, uint64_t length)
 {
 	struct drm_i915_gem_pread gem_pread;
 	int err;
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index f2412d78..97f278ed 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -69,6 +69,7 @@  uint32_t gem_open(int fd, uint32_t name);
 void gem_close(int fd, uint32_t handle);
 int __gem_write(int fd, uint32_t handle, uint64_t offset, const void *buf, uint64_t length);
 void gem_write(int fd, uint32_t handle, uint64_t offset,  const void *buf, uint64_t length);
+int __gem_read(int fd, uint32_t handle, uint64_t offset, void *buf, uint64_t length);
 void gem_read(int fd, uint32_t handle, uint64_t offset, void *buf, uint64_t length);
 int __gem_set_domain(int fd, uint32_t handle, uint32_t read, uint32_t write);
 void gem_set_domain(int fd, uint32_t handle, uint32_t read, uint32_t write);
diff --git a/tests/prime_vgem.c b/tests/prime_vgem.c
index 04cc913d..6595818c 100644
--- a/tests/prime_vgem.c
+++ b/tests/prime_vgem.c
@@ -46,6 +46,8 @@  static void test_read(int vgem, int i915)
 	handle = prime_fd_to_handle(i915, dmabuf);
 	close(dmabuf);
 
+	igt_skip_on(__gem_read(i915, handle, 0, &i, sizeof(i)));
+
 	ptr = vgem_mmap(vgem, &scratch, PROT_WRITE);
 	for (i = 0; i < 1024; i++)
 		ptr[1024*i] = i;
@@ -81,6 +83,8 @@  static void test_fence_read(int i915, int vgem)
 	handle = prime_fd_to_handle(i915, dmabuf);
 	close(dmabuf);
 
+	igt_skip_on(__gem_read(i915, handle, 0, &i, sizeof(i)));
+
 	igt_fork(child, 1) {
 		close(master[0]);
 		close(slave[1]);
@@ -191,6 +195,8 @@  static void test_write(int vgem, int i915)
 	handle = prime_fd_to_handle(i915, dmabuf);
 	close(dmabuf);
 
+	igt_skip_on(__gem_write(i915, handle, 0, &i, sizeof(i)));
+
 	ptr = vgem_mmap(vgem, &scratch, PROT_READ);
 	gem_close(vgem, scratch.handle);