Quoting Daniel Vetter (2020-10-12 14:55:07) > On Mon, Oct 12, 2020 at 12:49 PM Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > Quoting Daniel Vetter (2020-10-09 17:16:06) > > > On Fri, Oct 9, 2020 at 12:21 PM Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > vgem is a minimalistic driver that provides shmemfs objects to > > > > userspace that may then be used as an in-memory surface and transported > > > > across dma-buf to other drivers. Since it's introduction, > > > > drm_gem_shmem_helper now provides the same shmemfs facilities and so we > > > > can trim vgem to wrap the helper. > > > > > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > --- > > > > drivers/gpu/drm/Kconfig | 1 + > > > > drivers/gpu/drm/vgem/vgem_drv.c | 281 ++------------------------------ > > > > drivers/gpu/drm/vgem/vgem_drv.h | 11 -- > > > > 3 files changed, 13 insertions(+), 280 deletions(-) > > > > > > Nice diffstat :-) > > > > > > Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > > Unfortunately I had to drop the drm_gem_prime_mmap() since the existing > > expectation is that we hand the faulthandler off to shmemfs so we can > > release the module while the memory is exported. > > That sounds like a broken igt. Once we have refcounting for > outstanding dma_fence/buf or anything else we'll block unloading of > the module (not unbinding of the driver). Which one is that? The dma-buf is closed; all that remains is the mmap. Then from the perspective of the module, there is no reference back to the module since we delegate handling of the mmap back to the owner, the shmemfs builtin. That allows us to remove the module as its object code is no longer required. -Chris _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
