[PATCH 40/59] drm/vram-helper: Drop drm_gem_prime_export/import

[Daniel Vetter]

On Mon, Jun 17, 2019 at 10:24:38AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > Aside: Would be really nice to switch the others over to
> > drm_gem_object_funcs.
> 
> 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.

The trouble is that removing the hook outright isn't quite right, because
it also signals "is mmap allowed on this dma-buf". I'm kinda tempted to
just make that a hard requirement, and force people who can't support mmap
on the dma-buf (or who need begin/end_cpu_access hooks) to supply their
own set of dma_buf_ops.

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.

Hope that explains a bit better what's going on here. Step one here for
mmap is definitely to roll out drm_gem_prime_mmap as far as possible, so
it's easier to understand where the exceptions are.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch