Quoting Janusz Krzysztofik (2019-11-26 14:25:48) > As we've agreed that using GEM_MMAP* IOCTLs on dma-buf objects without > a CPU accessible GART is very questionable, we are probably not going > to extend our MMAP_OFFSET handler with an extra processing path > required for it to work correctly on dma-buf objects. As a > consequence, on future hardware with no mappable aperture we won't be > able to use MMAP_OFFSET as a replacement of MMAP_GTT in tests which > examine PRIME import interface. When running on that kind of hardware, > just skip subtests which depend on gem_mmap__gtt(). > > Cc: Daniel Vetter <daniel@xxxxxxxx> > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > --- > tests/prime_vgem.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/tests/prime_vgem.c b/tests/prime_vgem.c > index 04cc913d..b92cf4f7 100644 > --- a/tests/prime_vgem.c > +++ b/tests/prime_vgem.c > @@ -126,6 +126,8 @@ static void test_fence_mmap(int i915, int vgem) > int dmabuf, i; > int master[2], slave[2]; > > + gem_require_mappable_ggtt(i915); > + > igt_assert(pipe(master) == 0); > igt_assert(pipe(slave) == 0); > > @@ -210,6 +212,8 @@ static void test_gtt(int vgem, int i915) > uint32_t *ptr; > int dmabuf, i; > > + gem_require_mappable_ggtt(i915); > + > scratch.width = 1024; > scratch.height = 1024; > scratch.bpp = 32; > @@ -285,6 +289,7 @@ static void test_gtt_interleaved(int vgem, int i915) > uint32_t *ptr, *gtt; > int dmabuf, i; > > + gem_require_mappable_ggtt(i915); > igt_require(is_coherent(i915)); Ok, but these (fence_mmap, gtt_interleaved) want WC coherency as an alternative. test_gtt probably wants a basic test_wc alternative. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
