similar to: [PATCH 0/4] Merge VRAM MM and GEM VRAM source files

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

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

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

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

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

The VRAM MM memory manager is a helper library that manages dedicated video memory of simple framebuffer devices. It is supported to be used with struct drm_gem_vram_object, but does not depend on it. The implementation is based on the respective code from ast, bochs, and mgag200. These drivers share the exact same implementation except for type names. The helpers are currently build with TTM.

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 +++++++++++++++++++ >

The data structure |struct drm_vram_mm| and its helpers replace ast's TTM-based memory manager. It's the same implementation; except for the type names. v2: * implement ast_mmap() with drm_vram_mm_mmap() Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/ast/Kconfig | 1 + drivers/gpu/drm/ast/ast_drv.h | 12 +--- drivers/gpu/drm/ast/ast_main.c |

Rename the embedded struct vma_offset_manager, new name is _vma_manager. ttm_bo_device.vma_manager changed to a pointer. The ttm_bo_device_init() function gets an additional vma_manager argument which allows to initialize ttm with a different vma manager. When passing NULL the embedded _vma_manager is used. All callers are updated to pass NULL, so the behavior doesn't change. Signed-off-by:

Rename the embedded struct vma_offset_manager, new name is _vma_manager. ttm_bo_device.vma_manager changed to a pointer. The ttm_bo_device_init() function gets an additional vma_manager argument which allows to initialize ttm with a different vma manager. When passing NULL the embedded _vma_manager is used. All callers are updated to pass NULL, so the behavior doesn't change. Signed-off-by:

Rename the embedded struct vma_offset_manager, new name is _vma_manager. ttm_bo_device.vma_manager changed to a pointer. The ttm_bo_device_init() function gets an additional vma_manager argument which allows to initialize ttm with a different vma manager. When passing NULL the embedded _vma_manager is used. All callers are updated to pass NULL, so the behavior doesn't change. Signed-off-by:

Some graphics APIs differentiate between out-of-graphics-memory and out-of-host-memory (system memory). Add a device init flag to have -ENOSPC propagated from the resource managers instead of being converted to -ENOMEM, to aid driver stacks in determining what error code to return or whether corrective action can be taken at the driver level. The first patch deals with a ttm_device_init()

On Wed, 2024-10-02 at 14:54 +0200, Thomas Hellstr?m wrote: > On Wed, 2024-10-02 at 14:45 +0200, Christian K?nig wrote: > > Am 02.10.24 um 14:24 schrieb Thomas Hellstr?m: > > > The ttm_device_init funcition uses multiple bool arguments. That > > > means > > > readability in the caller becomes poor, and all callers need to > > > change if > > >

On Fri, Oct 04, 2024 at 04:28:29PM +0200, Thomas Hellstr?m wrote: > On Wed, 2024-10-02 at 14:54 +0200, Thomas Hellstr?m wrote: > > On Wed, 2024-10-02 at 14:45 +0200, Christian K?nig wrote: > > > Am 02.10.24 um 14:24 schrieb Thomas Hellstr?m: > > > > The ttm_device_init funcition uses multiple bool arguments. That > > > > means > > > >

> > + /** > > + * @max_segment: > > + * > > + * Max size for scatter list segments. When unset the default > > + * (SCATTERLIST_MAX_SEGMENT) is used. > > + */ > > + size_t max_segment; > > Is there no better place for this then "at the bottom"? drm_device is a > huge structure, piling stuff up randomly doesn't make it better

A kernel test bot reported a problem with the locktorture testcase that was triggered by the GEM VRAM helpers. ... [ 10.004734] RIP: 0010:ttm_bo_validate+0x41/0x141 [ttm] ... [ 10.015669] ? kvm_sched_clock_read+0x5/0xd [ 10.016157] ? get_lock_stats+0x11/0x3f [ 10.016607] drm_gem_vram_pin+0x77/0xa2 [drm_vram_helper] [ 10.017229]