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