Quoting Janusz Krzysztofik (2019-11-20 15:49:33) > (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? But the query you make would be "what is the pwrite/pread ABI"? And we want that to tick independently of other ioctls. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
