[Intel-gfx] [PATCH 40/59] drm/vram-helper: Drop drm_gem_prime_export/import
Gerd Hoffmann
kraxel at redhat.com
Tue Jun 18 04:49:25 UTC 2019
Hi,
> > While most callbacks are pretty straight forward (just hook the same
> > callbacks into the drm_gem_object_funcs. struct) the mmap bits are a
> > bit more obscure.
> >
> > First, there seem to be two ways to mmap a gem buffer:
> >
> > (1) drm_driver->fops->mmap, and
> > (2) drm_driver->gem_prime_mmap.
> >
> > drm_gem_object_funcs has just a single vm_ops ...
> >
> > Also it is not obvious how one would convert something which basically
> > calls ttm_bo_mmap() in drm_driver->fops->mmap to the new interface.
>
> Yeah the mmap side is still a mess, but my series here was getting a bit
> too long already. There's a bunch of problems here:
>
> drm_driver->gem_prime_mmap could be nuked and instead we use
> drm_gem_prime_mmap everywhere. Especially the various versions in helpers
> really don't add much.
Well, everything using ttm has the problem that we have another
duplication here: both gem and ttm have a vma_node ...
So (for example) drm_gem_vram_driver_gem_prime_mmap() is a thin wrapper
which does (a) copy vm_node.start from ttm to gem vma_node and (b) calls
drm_gem_prime_mmap().
> Second one is drm_driver->fops->mmap. That one we need to keep, but this
> isn't mmap on a buffer, but mmap on the entire drm_device. The one which
> should be replaced by drm_gem_object_funcs.vm_ops is
> drm_driver->gem_vm_ops.
Hmm, seems ttm hasn't something I can hook into drm_driver->gem_vm_ops ...
cheers,
Gerd
More information about the Intel-gfx
mailing list