similar to: [PATCH v4 11/11] drm/vram: drop DRM_VRAM_MM_FILE_OPERATIONS

Not needed any more because we don't have vram specific fops any more. DEFINE_DRM_GEM_FOPS() can be used instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann at suse.de> --- include/drm/drm_gem_vram_helper.h | 18 ------------------ drivers/gpu/drm/ast/ast_drv.c | 5 +----

Not needed any more because we don't have vram specific fops any more. DEFINE_DRM_GEM_FOPS() can be used instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann at suse.de> --- include/drm/drm_gem_vram_helper.h | 18 ------------------ drivers/gpu/drm/ast/ast_drv.c | 5 +----

Am 13.09.19 um 14:29 schrieb Gerd Hoffmann: > Not needed any more because we don't have vram specific fops > any more. DEFINE_DRM_GEM_FOPS() can be used instead. > > Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> > --- > include/drm/drm_gem_vram_helper.h | 18 ---- > include/drm/drm_vram_mm_helper.h | 82 +++++++++++++++++++ >

Not needed any more because we don't have vram specific functions any more. DEFINE_DRM_GEM_FOPS() can be used instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- include/drm/drm_vram_mm_helper.h | 17 ----------------- drivers/gpu/drm/ast/ast_drv.c | 5 +---- drivers/gpu/drm/bochs/bochs_drv.c | 5 +----

Not needed any more because we don't have vram specific fops any more. DEFINE_DRM_GEM_FOPS() can be used instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- include/drm/drm_gem_vram_helper.h | 18 ---- include/drm/drm_vram_mm_helper.h | 82 +++++++++++++++++++ drivers/gpu/drm/ast/ast_drv.c | 5 +- drivers/gpu/drm/bochs/bochs_drv.c

Not needed any more because we don't have vram specific fops any more. DEFINE_DRM_GEM_FOPS() can be used instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- include/drm/drm_gem_vram_helper.h | 18 ---- include/drm/drm_vram_mm_helper.h | 82 +++++++++++++++++++ drivers/gpu/drm/ast/ast_drv.c | 5 +- drivers/gpu/drm/bochs/bochs_drv.c

Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else and moving that is maybe a bit too

Hi Am 23.10.20 um 14:28 schrieb Daniel Vetter: > Only the following drivers aren't converted: > - amdgpu, because of the driver_feature mangling due to virt support > - nouveau, because DRIVER_ATOMIC uapi is still not the default on the > platforms where it's supported (i.e. again driver_feature mangling) > - vc4, again because of driver_feature mangling > - qxl,

Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support. Subsequent patch will address this. - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else

Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else and moving that is maybe a bit too

Hi Daniel. On Fri, Oct 23, 2020 at 06:04:44PM +0200, Daniel Vetter wrote: > Only the following drivers aren't converted: > - amdgpu, because of the driver_feature mangling due to virt support > - nouveau, because DRIVER_ATOMIC uapi is still not the default on the > platforms where it's supported (i.e. again driver_feature mangling) > - vc4, again because of driver_feature

Only the following drivers aren't converted: - amdgpu, because of the driver_feature mangling due to virt support - nouveau, because DRIVER_ATOMIC uapi is still not the default on the platforms where it's supported (i.e. again driver_feature mangling) - vc4, again because of driver_feature mangling - qxl, because the ioctl table is somewhere else and moving that is maybe a bit too

VRAM MM and GEM VRAM are only used with each other. This patch set moves VRAM MM into GEM VRAM source files and cleans up the helper's public interface. Thomas Zimmermann (4): drm/vram: Move VRAM memory manager to GEM VRAM implementation drm/vram: Have VRAM MM call GEM VRAM functions directly drm/vram: Unexport internal functions of VRAM MM drm/vram: Unconditonally set BO call-back

VRAM MM and GEM VRAM are only used with each other. This patch set moves VRAM MM into GEM VRAM source files and cleans up the helper's public interface. Version 2 of the patch set doesn't contain functional changes. I'm reposting due to the rebasing onto the debugfs patches. v2: * updated for debugfs support * fixed typos in comments Thomas Zimmermann (4): drm/vram: Move VRAM

Hi, > static const struct file_operations bochs_fops = { > .owner = THIS_MODULE, > - .open = drm_open, > - .release = drm_release, > - .unlocked_ioctl = drm_ioctl, > - .compat_ioctl = drm_compat_ioctl, > - .poll = drm_poll, > - .read = drm_read, > .llseek = no_llseek, > - .mmap = bochs_mmap, > + DRM_VRAM_MM_FILE_OPERATIONS > }; What about

Well first problem is I'm not sure if that is a good idea. Essentially we want to get rid of TTM in the long run. On the other hand this work might aid with that goal, so it might be worth a try. Second is that this might actually not work of hand. The problem is here: > + /* TODO: This test used to be performed by drivers, but can > + * this actually happen? If so, should we put

Hi, most of this patch set still needs reviews. If it's too large for merging or reviewing at once, I could move the driver changes into separate patch sets. The vbox driver's changes have been accepted by Hans already. So only keeping the core changes plus vbox would be an option. Best regards Thomas Am 08.05.19 um 10:26 schrieb Thomas Zimmermann: > Several simple framebuffer

The data structure |struct drm_vram_mm| and its helpers replace bochs' TTM-based memory manager. It's the same implementation; except for the type names. v4: * don't select DRM_TTM or DRM_VRAM_MM_HELPER v3: * use drm_gem_vram_mm_funcs * convert driver to drm_device-based instance v2: * implement bochs_mmap() with drm_vram_mm_mmap() Signed-off-by: Thomas Zimmermann <tzimmermann

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same