linux-stable.git/drivers/gpu/drm/drm_gem.c, branch linux-5.14.y

dma-buf: drop the _rcu postfix on function names v3

2021-06-06T09:19:51+00:00

The functions can be called both in _rcu context as well
as while holding the lock.

v2: add some kerneldoc as suggested by Daniel
v3: fix indentation

Signed-off-by: Christian König 
Reviewed-by: Jason Ekstrand 
Acked-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20210602111714.212426-7-christian.koenig@amd.com

dma-buf: rename dma_resv_get_excl_rcu to _unlocked

2021-06-06T09:19:30+00:00

That describes much better what the function is doing here.

Signed-off-by: Christian König 
Reviewed-by: Jason Ekstrand 
Acked-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20210602111714.212426-6-christian.koenig@amd.com

drm/gem: Export drm_gem_vmap() and drm_gem_vunmap()

2021-02-08T12:00:06+00:00

The symbols will be required by the upcoming helpers for shadow-buffered
planes.

Signed-off-by: Thomas Zimmermann 
Tested-by: Gerd Hoffmann 
Acked-by: Gerd Hoffmann 
Reported-by: kernel test robot 
Link: https://patchwork.freedesktop.org/patch/msgid/20210208115538.6430-3-tzimmermann@suse.de

drm: Set vm_ops to GEM object's values during mmap

2021-01-18T09:37:26+00:00

The GEM mmap code relies on the GEM object's mmap callback to set the
VMA's vm_ops field. This is easily forgotten and already led to a memory
leak in the CMA helpers. Instead set the vm_ops field in the DRM core
code to the GEM object's value. Drivers with different needs can override
this in their mmap callback.

v2:
	* support (vm_ops == NULL) if mmap is given; required by VRAM
	  helpers

Signed-off-by: Thomas Zimmermann 
Fixes: f5ca8eb6f9bd ("drm/cma-helper: Implement mmap as GEM CMA object functions")
Reviewed-by: Daniel Vetter 
Reported-by: Kieran Bingham 
Tested-by: Kieran Bingham 
Cc: Maxime Ripard 
Cc: Maarten Lankhorst 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Eric Anholt 
Cc: dri-devel@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20210115093038.10345-1-tzimmermann@suse.de

drm: Don't export the drm_gem_dumb_destroy() function

2021-01-05T05:20:25+00:00

The drm_gem_dumb_destroy() isn't used in drivers, don't export it.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Daniel Vetter

drm: fix some kernel-doc markups

2020-11-16T19:48:20+00:00

Some identifiers have different names between their prototypes
and the kernel-doc markup.

Others need to be fixed, as kernel-doc markups should use this format:
        identifier - description

Signed-off-by: Mauro Carvalho Chehab 
Acked-by: Jani Nikula 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/12d4ca26f6843618200529ce5445063734d38c04.1605521731.git.mchehab+huawei@kernel.org

drm/gem: Update internal GEM vmap/vunmap interfaces to use struct dma_buf_map

2020-11-09T08:19:36+00:00

GEM's vmap and vunmap interfaces now wrap memory pointers in struct
dma_buf_map.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Daniel Vetter 
Tested-by: Sam Ravnborg 
Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-8-tzimmermann@suse.de

drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends

2020-11-09T08:19:24+00:00

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. GEM VRAM helpers and qxl now use ttm_bo_vmap()
et al. Amdgpu, nouveau and radeon use drm_gem_ttm_vmap() et al instead of
implementing their own vmap callbacks.

v7:
	* init QXL cursor to mapped BO buffer (kernel test robot)
v5:
	* update vkms after switch to shmem
v4:
	* use ttm_bo_vmap(), drm_gem_ttm_vmap(), et al. (Daniel, Christian)
	* fix a trailing { in drm_gem_vmap()
	* remove several empty functions instead of converting them (Daniel)
	* comment uses of raw pointers with a TODO (Daniel)
	* TODO list: convert more helpers to use struct dma_buf_map

Signed-off-by: Thomas Zimmermann 
Acked-by: Christian König 
Tested-by: Sam Ravnborg 
Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-7-tzimmermann@suse.de

Merge drm/drm-next into drm-misc-next

2020-11-02T10:17:54+00:00

Daniel needs -rc2 in drm-misc-next to merge some patches

Signed-off-by: Maxime Ripard

drm/shme-helpers: Fix dma_buf_mmap forwarding bug

2020-10-28T11:27:41+00:00

When we forward an mmap to the dma_buf exporter, they get to own
everything. Unfortunately drm_gem_mmap_obj() overwrote
vma->vm_private_data after the driver callback, wreaking the
exporter complete. This was noticed because vb2_common_vm_close blew
up on mali gpu with panfrost after commit 26d3ac3cb04d
("drm/shmem-helpers: Redirect mmap for imported dma-buf").

Unfortunately drm_gem_mmap_obj also acquires a surplus reference that
we need to drop in shmem helpers, which is a bit of a mislayer
situation. Maybe the entire dma_buf_mmap forwarding should be pulled
into core gem code.

Note that the only two other drivers which forward mmap in their own
code (etnaviv and exynos) get this somewhat right by overwriting the
gem mmap code. But they seem to still have the leak. This might be a
good excuse to move these drivers over to shmem helpers completely.

Reviewed-by: Boris Brezillon 
Acked-by: Christian König 
Cc: Christian König 
Cc: Sumit Semwal 
Cc: Lucas Stach 
Cc: Russell King 
Cc: Christian Gmeiner 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Fixes: 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf")
Cc: Boris Brezillon 
Cc: Thomas Zimmermann 
Cc: Gerd Hoffmann 
Cc: Rob Herring 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
Cc:  # v5.9+
Reported-and-tested-by: piotr.oniszczuk@gmail.com
Cc: piotr.oniszczuk@gmail.com
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20201027214922.3566743-1-daniel.vetter@ffwll.ch