linux-stable.git/drivers/gpu/drm/drm_client.c, branch v6.2.2

drm/client: fix circular reference counting issue

2023-02-07T08:42:56+00:00

We reference dump buffers both by their handle as well as their
object. The problem is now that when anybody iterates over the DRM
framebuffers and exports the underlying GEM objects through DMA-buf
we run into a circular reference count situation.

The result is that the fbdev handling holds the GEM handle preventing
the DMA-buf in the GEM object to be released. This DMA-buf in turn
holds a reference to the driver module which on unload would release
the fbdev.

Break that loop by releasing the handle as soon as the DRM
framebuffer object is created. The DRM framebuffer and the DRM client
buffer structure still hold a reference to the underlying GEM object
preventing its destruction.

Signed-off-by: Christian König 
Fixes: c76f0f7cb546 ("drm: Begin an API for in-kernel clients")
Cc: 
Reviewed-by: Thomas Zimmermann 
Tested-by: Thomas Zimmermann 
Link: https://patchwork.freedesktop.org/patch/msgid/20230126102814.8722-1-christian.koenig@amd.com

drm/client: Prevent NULL dereference in drm_client_buffer_delete()

2022-11-02T10:53:57+00:00

The drm_gem_vunmap() will crash with a NULL dereference if the passed
object pointer is NULL. It wasn't a problem before we added the locking
support to drm_gem_vunmap function because the mapping argument was always
NULL together with the object. Make drm_client_buffer_delete() to check
whether GEM is NULL before trying to unmap the GEM, it will happen on
framebuffer creation error.

Reported-by: Dan Carpenter 
Reviewed-by: Christian König 
Link: https://lore.kernel.org/dri-devel/Y1kFEGxT8MVlf32V@kili/
Fixes: 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap operations")
Signed-off-by: Dmitry Osipenko 
Link: https://patchwork.freedesktop.org/patch/msgid/20221030154412.8320-3-dmitry.osipenko@collabora.com

drm/client: Switch drm_client_buffer_delete() to unlocked drm_gem_vunmap

2022-10-24T19:05:43+00:00

The drm_client_buffer_delete() wasn't switched to unlocked GEM vunmapping
by accident when rest of drm_client code transitioned to the unlocked
variants of the vmapping functions. Make drm_client_buffer_delete() use
the unlocked variant. This fixes lockdep warning splat about missing
reservation lock when framebuffer is released.

Reported-by: kernel test robot 
Link: https://lore.kernel.org/dri-devel/890f70db-68b0-8456-ca3c-c5496ef90517@collabora.com/T/
Fixes: 79e2cf2e7a19 ("drm/gem: Take reservation lock for vmap/vunmap operations")
Signed-off-by: Dmitry Osipenko 
Acked-by: Christian König 
Link: https://patchwork.freedesktop.org/patch/msgid/20221020213335.309092-1-dmitry.osipenko@collabora.com

drm/gem: Take reservation lock for vmap/vunmap operations

2022-10-17T22:21:38+00:00

The new common dma-buf locking convention will require buffer importers
to hold the reservation lock around mapping operations. Make DRM GEM core
to take the lock around the vmapping operations and update DRM drivers to
use the locked functions for the case where DRM core now holds the lock.
This patch prepares DRM core and drivers to the common dynamic dma-buf
locking convention.

Acked-by: Christian König 
Signed-off-by: Dmitry Osipenko 
Link: https://patchwork.freedesktop.org/patch/msgid/20221017172229.42269-4-dmitry.osipenko@collabora.com

drm/client: Use actual bpp when allocating frame buffers

2022-07-09T13:00:52+00:00

When allocating a frame buffer, the number of bits per pixel needed is
derived from the deprecated drm_format_info.cpp[] field.  While this may
work for formats using less than 8 bits per pixel, it does lead to a
large overallocation.

Reduce memory consumption by using the actual number of bits per pixel
instead.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Signed-off-by: Sam Ravnborg 
Link: https://patchwork.freedesktop.org/patch/msgid/eabcf4f298184dabe46823fcf5ceffa1da0ec7ef.1657294931.git.geert@linux-m68k.org

dma-buf-map: Rename to iosys-map

2022-02-08T00:35:35+00:00

Rename struct dma_buf_map to struct iosys_map and corresponding APIs.
Over time dma-buf-map grew up to more functionality than the one used by
dma-buf: in fact it's just a shim layer to abstract system memory, that
can be accessed via regular load and store, from IO memory that needs to
be acessed via arch helpers.

The idea is to extend this API so it can fulfill other needs, internal
to a single driver. Example: in the i915 driver it's desired to share
the implementation for integrated graphics, which uses mostly system
memory, with discrete graphics, which may need to access IO memory.

The conversion was mostly done with the following semantic patch:

	@r1@
	@@
	- struct dma_buf_map
	+ struct iosys_map

	@r2@
	@@
	(
	- DMA_BUF_MAP_INIT_VADDR
	+ IOSYS_MAP_INIT_VADDR
	|
	- dma_buf_map_set_vaddr
	+ iosys_map_set_vaddr
	|
	- dma_buf_map_set_vaddr_iomem
	+ iosys_map_set_vaddr_iomem
	|
	- dma_buf_map_is_equal
	+ iosys_map_is_equal
	|
	- dma_buf_map_is_null
	+ iosys_map_is_null
	|
	- dma_buf_map_is_set
	+ iosys_map_is_set
	|
	- dma_buf_map_clear
	+ iosys_map_clear
	|
	- dma_buf_map_memcpy_to
	+ iosys_map_memcpy_to
	|
	- dma_buf_map_incr
	+ iosys_map_incr
	)

	@@
	@@
	- #include 
	+ #include 

Then some files had their includes adjusted and some comments were
update to remove mentions to dma-buf-map.

Since this is not specific to dma-buf anymore, move the documentation to
the "Bus-Independent Device Accesses" section.

v2:
  - Squash patches

v3:
  - Fix wrong removal of dma-buf.h from MAINTAINERS
  - Move documentation from dma-buf.rst to device-io.rst

v4:
  - Change documentation title and level

Signed-off-by: Lucas De Marchi 
Acked-by: Christian König 
Acked-by: Sumit Semwal 
Acked-by: Thomas Zimmermann 
Link: https://patchwork.freedesktop.org/patch/msgid/20220204170541.829227-1-lucas.demarchi@intel.com

drm/client: Depend on GEM object kmap ref-counting

2020-11-24T08:27:54+00:00

DRM client's vmap/vunmap functions don't allow for multiple vmap
operations. Calling drm_client_buffer_vmap() twice returns the same
mapping, then calling drm_client_buffer_vunmap() twice already unmaps
on the first call. This leads to unbalanced vmap refcounts. Fix this
by calling drm_gem_vmap() unconditionally in drm_client_buffer_vmap().

All drivers that support DRM clients have to implement correct ref-
counting for their vmap operations, or not vunmap at all. This is the
case for drivers that use CMA, SHMEM and VRAM helpers, and QXL. Other
drivers are not affected.

Signed-off-by: Thomas Zimmermann 
Acked-by: Maxime Ripard 
Link: https://patchwork.freedesktop.org/patch/msgid/20201120102545.4047-4-tzimmermann@suse.de

drm/gem: Store client buffer mappings as struct dma_buf_map

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

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 I/O memory;
	  warn instead (Daniel)

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

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/client: Add drm_client_framebuffer_flush()

2020-05-26T11:31:01+00:00

Some drivers need explicit flushing of buffer changes, add a function
that does that.

v2:
- Put all clip rect stuff inside if statement (Sam)

Reviewed-by: Sam Ravnborg 
Signed-off-by: Noralf Trønnes 
Link: https://patchwork.freedesktop.org/patch/msgid/20200509141619.32970-4-noralf@tronnes.org