similar to: [PATCH 2/2] drm/mediatek: Use struct dma_buf_map in GEM vmap ops

GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in mediatek. The only exception is gem_prime_mmap, which is non-trivial to convert. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 -----

Fixes a build failure with msm. This change was supposed to be part of commit 49a3f51dfeee ("drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends"), but msm was forgotten. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Fixes: 49a3f51dfeee ("drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends") Cc: Thomas Zimmermann

On 18/05/16 18:07, Arnd Bergmann wrote: > The drm_gem_object_lookup() function prototype changed while this > driver was added, so it fails to build now: > > drivers/gpu/drm/mediatek/mtk_drm_gem.c: In function 'mtk_drm_gem_dumb_map_offset': > drivers/gpu/drm/mediatek/mtk_drm_gem.c:142:30: error: passing argument 1 of 'drm_gem_object_lookup' from incompatible pointer

The drm_gem_object_lookup() function prototype changed while this driver was added, so it fails to build now: drivers/gpu/drm/mediatek/mtk_drm_gem.c: In function 'mtk_drm_gem_dumb_map_offset': drivers/gpu/drm/mediatek/mtk_drm_gem.c:142:30: error: passing argument 1 of 'drm_gem_object_lookup' from incompatible pointer type [-Werror=incompatible-pointer-types] obj =

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Patches #1 to #16 and #18 to #19 convert DRM drivers to GEM object functions, one by one. Each patch moves existing callbacks from struct drm_driver to

Hi, This is third approach (complete this time) for replacing struct dma_attrs with unsigned long. The main patch (2/45) doing the change is split into many subpatches for easier review (3-43). They should be squashed together when applying. *Important:* Patchset is *only* build tested on allyesconfigs: ARM, ARM64, i386, x86_64 and powerpc. Please provide reviewes and tests for other

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Version 3 of this patchset mostly fixes drm_gem_prime_handle_to_fd and updates i.MX's dcss driver. The driver was missing from earlier versions and

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Patches #1 to #18 convert DRM drivers to GEM object functions, one by one. Each patch moves existing callbacks from struct drm_driver to an instance of

A couple of new warnings and build errors appeared through the DRM tree in linux-next after the merge window opened. The first patch here is for scripts/headers_check.pl, but as the bug is only present in drm-next at the moment, it would be good to add all five patches to that tree before they make it into mainline. It's likely that some of these have already been fixed since this

Instances of struct dma_buf_map should be useful throughout DRM's memory management code. Furthermore, several drivers can now use generic fbdev emulation. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- Documentation/gpu/todo.rst | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/todo.rst

GEM's vmap and vunmap interfaces now wrap memory pointers in struct dma_buf_map. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/drm_client.c | 18 +++++++++++------- drivers/gpu/drm/drm_gem.c | 28 ++++++++++++++-------------- drivers/gpu/drm/drm_internal.h | 5 +++-- drivers/gpu/drm/drm_prime.c | 14 ++++---------- 4 files changed, 32

A couple of new warnings and build errors appeared through the DRM tree in linux-next after the merge window opened. The first patch here is for scripts/headers_check.pl, but as the bug is only present in drm-next at the moment, it would be good to add all five patches to that tree before they make it into mainline. It's likely that some of these have already been fixed since this

Kernel DRM clients now store their framebuffer address in an instance of struct dma_buf_map. Depending on the buffer's location, the address refers to system or I/O memory. Callers of drm_client_buffer_vmap() receive a copy of the value in the call's supplied arguments. It can be accessed and modified with dma_buf_map interfaces. Signed-off-by: Thomas Zimmermann <tzimmermann at

Kernel DRM clients now store their framebuffer address in an instance of struct dma_buf_map. Depending on the buffer's location, the address refers to system or I/O memory. Callers of drm_client_buffer_vmap() receive a copy of the value in the call's supplied arguments. It can be accessed and modified with dma_buf_map interfaces. Signed-off-by: Thomas Zimmermann <tzimmermann at

Kernel DRM clients now store their framebuffer address in an instance of struct dma_buf_map. Depending on the buffer's location, the address refers to system or I/O memory. Callers of drm_client_buffer_vmap() receive a copy of the value in the call's supplied arguments. It can be accessed and modified with dma_buf_map interfaces. v6: * don't call page_to_phys() on framebuffers in

Hi On 22.10.20 10:49, Daniel Vetter wrote: > On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote: >> Kernel DRM clients now store their framebuffer address in an instance >> of struct dma_buf_map. Depending on the buffer's location, the address >> refers to system or I/O memory. >> >> Callers of drm_client_buffer_vmap() receive a copy of the

This patch replaces the vmap/vunmap's use of raw pointers in GEM object functions with instances of struct dma_buf_map. GEM backends are converted as well. For most GEM backends, this simply change the returned type. GEM VRAM helpers are also updated to indicate whether the returned framebuffer address is in system or I/O memory. Signed-off-by: Thomas Zimmermann <tzimmermann at

Am 15.10.20 um 14:38 schrieb Thomas Zimmermann: > This patch replaces the vmap/vunmap's use of raw pointers in GEM object > functions with instances of struct dma_buf_map. GEM backends are > converted as well. For most of them, this simply changes the returned type. > > TTM-based drivers now return information about the location of the memory, > either system or I/O memory.

Hi, This is fifth approach for replacing struct dma_attrs with unsigned long. The main patch (1/44) doing the change is split into many subpatches for easier review (2-42). They should be squashed together when applying. Rebased on v4.7-rc5. For easier testing the patchset is available here: repo: https://github.com/krzk/linux branch: for-next/dma-attrs-const-v5 Changes since v4

On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote: > Kernel DRM clients now store their framebuffer address in an instance > of struct dma_buf_map. Depending on the buffer's location, the address > refers to system or I/O memory. > > Callers of drm_client_buffer_vmap() receive a copy of the value in > the call's supplied arguments. It can be accessed and