user/sven/linux.git/drivers/gpu/drm/drm_gem_framebuffer_helper.c, branch v6.3.12

drm/fb-helper: Remove unnecessary include statements

2022-11-05T16:12:04Z

Remove include statements for where it is not required (i.e., most of them). In a few places include other header files that are required by the source code. v3: * fix amdgpu include statements * fix rockchip include statements Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-23-tzimmermann@suse.de

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

2022-10-17T22:21:38Z

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/gem-fb-helper: Use actual bpp for size calculations

2022-07-09T13:08:16Z

The AFBC helpers derive the number of bits per pixel from the deprecated drm_format_info.cpp[] field, which does not take into account block sizes. Fix this by using the actual number of bits per pixel instead. Signed-off-by: Geert Uytterhoeven Reviewed-by: Javier Martinez Canillas Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/b1d938d903157627c4ac101df92a1f3bf8ebe83d.1657294931.git.geert@linux-m68k.org

drm/gem: Warn on trying to use a non-existing framebuffer plane

2022-05-19T17:25:23Z

Warn if callers of drm_gem_fb_get_obj() try to use a GEM buffer for a non-existing or unset plane. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Tested-by: Noralf Trønnes Acked-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20220517113327.26919-6-tzimmermann@suse.de

drm/gem: Ignore color planes that are unused by framebuffer format

2022-05-19T17:25:02Z

Only handle color planes that exist in a framebuffer's color format. Ignore non-existing planes. So far, several helpers assumed that all 4 planes are available and silently ignored non-existing planes. This lead to subtil bugs with uninitialized data in instances of struct iosys_map. [1] Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Tested-by: Noralf Trønnes Acked-by: Christian König Link: https://lore.kernel.org/dri-devel/20210730183511.20080-1-tzimmermann@suse.de/T/#md0172b10bb588d8f20f4f456e304f08d2a4505f7 # 1 Link: https://patchwork.freedesktop.org/patch/msgid/20220517113327.26919-3-tzimmermann@suse.de

drm/gem: Share code between drm_gem_fb_{begin,end}_cpu_access()

2022-05-19T17:24:51Z

The error-recovery code in drm_gem_fb_begin() is of the same pattern as drm_gem_fb_end(). Implement both of them using an internal helper. No functional changes. v2: * print additional information in error message (Javier) * fix commit description (Javier) Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Tested-by: Noralf Trønnes Acked-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20220517113327.26919-2-tzimmermann@suse.de

dma-buf-map: Rename to iosys-map

2022-02-08T00:35:35Z

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

dma-buf: move dma-buf symbols into the DMA_BUF module namespace

2021-10-25T12:53:08Z

In order to better track where in the kernel the dma-buf code is used, put the symbols in the namespace DMA_BUF and modify all users of the symbols to properly import the namespace to not break the build at the same time. Now the output of modinfo shows the use of these symbols, making it easier to watch for users over time: $ modinfo drivers/misc/fastrpc.ko | grep import import_ns: DMA_BUF Cc: "Pan, Xinhui" Cc: David Airlie Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: Mauro Carvalho Chehab Cc: dri-devel@lists.freedesktop.org Acked-by: Daniel Vetter Acked-by: Christian König Acked-by: Arnd Bergmann Acked-by: Sumit Semwal Acked-by: Alex Deucher Link: https://lore.kernel.org/r/20211010124628.17691-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

drm/gem: Provide offset-adjusted framebuffer BO mappings

2021-08-08T18:26:16Z

Add an additional argument to drm_gem_fb_vmap() to return each BO's mapping adjusted by the respective offset. Update all callers. The newly returned values point to the first byite of the data stored in the framebuffer BOs. Drivers that access the BO data should use it. Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210803125928.27780-2-tzimmermann@suse.de

drm/gem: Clear mapping addresses for unused framebuffer planes

2021-08-02T14:41:20Z

Set the returned mapping address to NULL if a framebuffer plane does not have a BO associated with it. Likewise, ignore mappings of NULL during framebuffer unmap operations. Allows users of the functions to perform unmap operations of certain BOs by themselfes. Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210730183511.20080-4-tzimmermann@suse.de