(fixing malformed intel-gfx list address in Cc:) On Wednesday, November 20, 2019 4:36:41 PM CET Chris Wilson wrote: > Quoting Janusz Krzysztofik (2019-11-20 15:32:19) > > 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. > > > > Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@xxxxxxxxxxxxxxx> > > Cc: Daniel Vetter <daniel@xxxxxxxx> > > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxx> > > --- > > tests/prime_vgem.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/tests/prime_vgem.c b/tests/prime_vgem.c > > index 2b21ff41..b7bbd989 100644 > > --- a/tests/prime_vgem.c > > +++ b/tests/prime_vgem.c > > @@ -37,6 +37,8 @@ static void test_read(int vgem, int i915) > > uint32_t *ptr; > > int dmabuf, i; > > > > + gem_require_mappable_ggtt(i915); > > If that were the case, the change in ABI would not be tied to the mmap > ABI. SInce dma-buf objects have no stuct page, the pwrite ioctl handler tries to use i915_gem_gtt_pwrite_fast(). There, both i915_gem_object_ggtt_pin() and insert_mappable_node() fail. Isn't that because of missing mappable aperture? Thanks, Janusz > -Chris > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
