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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 19, 2019 at 1:21 PM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote:
>
>   Hi,
>
> > > > 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 ...
> >
> > ttm_bo_vm_ops seems to be the thing you want.
>
> Wouldn't work as-is, but when ttm bo are a subclass of gem bos should
> be possible to create something usable based on it.

You'd need to create driver-specific wrappers, but that's somewhat
defeating the point.

> Related question: why there is no drm_gem_object_funcs.mmap() callback?
> I think it would make sense to have a callback where the bo-specific
> setup can be done, i.e. what ttm_bo_mmap() or drm_gem_shmem_mmap() are
> doing, and have some generic function which basically does the lookup,
> then dispatches.

Maybe. Atm all we have around mmap is a sprawling number of different
solutions. Atm I'm not really sure which direction we really should
head into ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux