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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
