[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