similar to: [PATCH] drm: ttm: virtio-gpu: dma-buf: Constify ttm_place structures.

On Sun, 2017-07-02 at 13:11 +0530, Arvind Yadav wrote: > ttm_place are not supposed to change at runtime. All functions > working with ttm_place provided by <drm/ttm/ttm_placement.h> work > with const ttm_place. So mark the non-const structs as const. > > File size before: > ???text ???data ????bss ????dec ????hex > filename > ???2315 ????184 ??????0 ???2499 ????9c3

ttm_place are not supposed to change at runtime. All functions working with ttm_place provided by <drm/ttm/ttm_placement.h> work with const ttm_place. So mark the non-const structs as const. File size before: text data bss dec hex filename 3485 184 264 3933 f5d drivers/gpu/drm/qxl/qxl_ttm.o File size After adding 'const': text data bss

ttm_place are not supposed to change at runtime. All functions working with ttm_place provided by <drm/ttm/ttm_placement.h> work with const ttm_place. So mark the non-const structs as const. File size before: text data bss dec hex filename 3485 184 264 3933 f5d drivers/gpu/drm/qxl/qxl_ttm.o File size After adding 'const': text data bss

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4:

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4:

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4:

The ttm_backend_func structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall at lip6.fr> --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- drivers/gpu/drm/ast/ast_ttm.c | 2 +- drivers/gpu/drm/bochs/bochs_mm.c | 2 +- drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-

The ttm_backend_func structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall at lip6.fr> --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- drivers/gpu/drm/ast/ast_ttm.c | 2 +- drivers/gpu/drm/bochs/bochs_mm.c | 2 +- drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4:

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code.

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v5:

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code.

. On Wed, Jun 19, 2019 at 11:08 PM Gerd Hoffmann <kraxel at redhat.com> wrote: > > virtio-gpu basically needs a sg_table for the bo, to tell the host where > the backing pages for the object are. So the gem shmem helpers are a > perfect fit. Some drm_gem_object_funcs need thin wrappers to update the > host state, but otherwise the helpers handle everything just fine. >

Many Makefiles needed to add -Iinclude/drm as an include path, but the right thing to do is to include headers in the form #include <drm/.../*.h> This series fixes the source files, then rip off -Iinclude/drm flags. V3: rebased on commit bb2af9bda33 (drm-misc-next) Masahiro Yamada (16): drm/vc4: fix include notation and remove -Iinclude/drm flag drm/virtio: fix include notation and

Many Makefiles needed to add -Iinclude/drm as an include path, but the right thing to do is to include headers in the form #include <drm/.../*.h> This series fixes the source files, then rip off -Iinclude/drm flags. V3: rebased on commit bb2af9bda33 (drm-misc-next) Masahiro Yamada (16): drm/vc4: fix include notation and remove -Iinclude/drm flag drm/virtio: fix include notation and

Include <drm/*.h> instead of relative path from include/drm, then remove the -Iinclude/drm compiler flag. Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com> --- Changes in v3: None drivers/gpu/drm/virtio/Makefile | 2 -- drivers/gpu/drm/virtio/virtgpu_debugfs.c | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++-- drivers/gpu/drm/virtio/virtgpu_drv.h

The functions ttm_bo_global_init() and ttm_bo_global_release() do not receive an argument of type struct ttm_bo_global. Both take a struct drm_global_reference that contains points to a struct ttm_bo_global_ref. Renaming them reflects this. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- Documentation/gpu/drm-mm.rst | 4 ++--

> +/** > + * drm_gem_vram_unpin() - Unpins a GEM VRAM object > + * @gbo: the GEM VRAM object > + * > + * Returns: > + * 0 on success, or > + * a negative error code otherwise. > + */ > +int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo) > +{ > + int i, ret; > + struct ttm_operation_ctx ctx = { false, false }; > + > + if (!gbo->pin_count) > +

> +/** > + * drm_gem_vram_unpin() - Unpins a GEM VRAM object > + * @gbo: the GEM VRAM object > + * > + * Returns: > + * 0 on success, or > + * a negative error code otherwise. > + */ > +int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo) > +{ > + int i, ret; > + struct ttm_operation_ctx ctx = { false, false }; > + > + if (!gbo->pin_count) > +

Ah ok. Sorry. :) I think that argument "-femit-all-decls" will help you. Olivier. On Mon, Dec 14, 2009 at 9:18 PM, Arvind Sudarsanam < arvind.sudarsanam at aggiemail.usu.edu> wrote: > Hi, > > Sorry for not being specific. I just wanted to know if there is any > way at all to force clang to generate intermediate code for static > functions when they are not being