kernel.git/drivers/gpu/drm/msm/msm_drv.h, branch linux-rolling-stable

Merge tag 'drm-msm-next-2025-09-12' of https://gitlab.freedesktop.org/drm/msm into drm-next

2025-09-16T00:21:38Z

Changes for v6.18 GPU and Core: - in DT bindings describe clocks per GPU type - GMU bandwidth voting for x1-85 - a663 speedbins - a623 speedbins - cleanup some remaining no-iommu leftovers after VM_BIND conversion - fix GEM obj 32b size truncation - add missing VM_BIND param validation - various fixes - IFPC for x1-85 and a750 - register xml and gen_header.py sync from mesa Display: - add missing bindings for display on SC8180X - added DisplayPort MST bindings - conversion from round_rate() to determine_rate() - DSI PHY fixes, correcting programming glitches - misc small fixes Signed-off-by: Dave Airlie From: Rob Clark Link: https://lore.kernel.org/r/CACSVV01FgXN+fD6U1Hi6Tj4WCf=V-+NO8BXi+80iS4qOZwpaGg@mail.gmail.com

drm/msm/mdp4: use msm_kms_init_vm() instead of duplicating it

2025-09-08T14:24:58Z

Use the msm_kms_init_vm() function to allocate memory manager instead of hand-coding a copy of it. Although MDP4 platforms don't have MDSS device, it's still safe to use the function as all MDP4 devices have IOMMU and the parent of the MDP4 is the root SoC device. Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/672563/ Signed-off-by: Rob Clark

drm: Pass the format info to .fb_create()

2025-07-16T17:03:14Z

Pass along the format information from the top to .fb_create() so that we can avoid redundant (and somewhat expensive) lookups in the drivers. Done with cocci (with some manual fixups): @@ identifier func =~ ".*create.*"; identifier dev, file, mode_cmd; @@ struct drm_framebuffer *func( struct drm_device *dev, struct drm_file *file, + const struct drm_format_info *info, const struct drm_mode_fb_cmd2 *mode_cmd) { ... ( - const struct drm_format_info *info = drm_get_format_info(...); | - const struct drm_format_info *info; ... - info = drm_get_format_info(...); ) <... - if (!info) - return ...; ...> } @@ identifier func =~ ".*create.*"; identifier dev, file, mode_cmd; @@ struct drm_framebuffer *func( struct drm_device *dev, struct drm_file *file, + const struct drm_format_info *info, const struct drm_mode_fb_cmd2 *mode_cmd) { ... } @find@ identifier fb_create_func =~ ".*create.*"; identifier dev, file, mode_cmd; @@ struct drm_framebuffer *fb_create_func( struct drm_device *dev, struct drm_file *file, + const struct drm_format_info *info, const struct drm_mode_fb_cmd2 *mode_cmd); @@ identifier find.fb_create_func; expression dev, file, mode_cmd; @@ fb_create_func(dev, file + ,info ,mode_cmd) @@ expression dev, file, mode_cmd; @@ drm_gem_fb_create(dev, file + ,info ,mode_cmd) @@ expression dev, file, mode_cmd; @@ drm_gem_fb_create_with_dirty(dev, file + ,info ,mode_cmd) @@ expression dev, file_priv, mode_cmd; identifier info, fb; @@ info = drm_get_format_info(...); ... fb = dev->mode_config.funcs->fb_create(dev, file_priv + ,info ,mode_cmd); @@ identifier dev, file_priv, mode_cmd; @@ struct drm_mode_config_funcs { ... struct drm_framebuffer *(*fb_create)(struct drm_device *dev, struct drm_file *file_priv, + const struct drm_format_info *info, const struct drm_mode_fb_cmd2 *mode_cmd); ... }; v2: Fix kernel docs (Laurent) Fix commit msg (Geert) Cc: Alex Deucher Cc: Liviu Dudau Cc: Maxime Ripard Cc: Russell King Cc: Inki Dae Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: Patrik Jakobsson Cc: Chun-Kuang Hu Cc: Philipp Zabel Cc: Rob Clark Cc: Abhinav Kumar Cc: Dmitry Baryshkov Cc: Sean Paul Cc: Marijn Suijten Cc: Marek Vasut Cc: Stefan Agner Cc: Lyude Paul Cc: Danilo Krummrich Cc: Tomi Valkeinen Cc: Dave Airlie Cc: Gerd Hoffmann Cc: Kieran Bingham Cc: Biju Das Cc: Sandy Huang Cc: "Heiko Stübner" Cc: Andy Yan Cc: Thierry Reding Cc: Mikko Perttunen Cc: Dave Stevenson Cc: "Maíra Canal" Cc: Raspberry Pi Kernel Maintenance Cc: Dmitry Osipenko Cc: Gurchetan Singh Cc: Chia-I Wu Cc: Zack Rusin Cc: Broadcom internal kernel review list Cc: Oleksandr Andrushchenko Cc: amd-gfx@lists.freedesktop.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: virtualization@lists.linux.dev Cc: spice-devel@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-tegra@vger.kernel.org Cc: Laurent Pinchart Reviewed-by: Geert Uytterhoeven Reviewed-by: Thomas Zimmermann Reviewed-by: Dmitry Baryshkov Acked-by: Liviu Dudau Reviewed-by: Laurent Pinchart Acked-by: Alex Deucher Acked-by: Rodrigo Vivi Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20250701090722.13645-5-ville.syrjala@linux.intel.com

drm/msm: enable separate binding of GPU and display devices

2025-07-05T14:37:21Z

There are cases when we want to have separate DRM devices for GPU and display pipelines. One example is development, when it is beneficial to be able to bind the GPU driver separately, without the display pipeline (and without the hacks adding "amd,imageon" to the compatible string). Another example is some of Qualcomm platforms, which have two MDSS units, but only one GPU. With current approach it is next to impossible to support this usecase properly, while separate binding allows users to have three DRM devices: two for MDSS units and a single headless GPU. Add kernel param msm.separate_gpu_kms, which if set to true forces creation of separate display and GPU DRM devices. Mesa supports this setup by using the kmsro wrapper. The param is disabled by default, in order to be able to test userspace for the compatibility issues. Simple clients are able to handle this setup automatically. Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/662590/ [Rob: renamed the modparam to separate_gpu_kms, and add missing DRIVER_GEM_GPUVA] Signed-off-by: Rob Clark

drm/msm: rework binding of Imageon GPUs

2025-07-05T14:13:35Z

Currently the msm driver creates an extra interim platform device for Imageon GPUs. This is not ideal, as the device doesn't have corresponding OF node. If the headless mode is used for newer GPUs, then the msm_use_mmu() function can not detect corresponding IOMMU devices. Also the DRM device (although it's headless) is created with modesetting flags being set. To solve all these issues, rework the way the Imageon devices are bound. Remove the interim device, don't register a component and instead use a cut-down version of the normal functions to probe or remove the driver. Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/662584/ Signed-off-by: Rob Clark

drm/msm: make it possible to disable KMS-related code.

2025-07-05T14:13:35Z

If the Adreno device is used in a headless mode, there is no need to build all KMS components. Build corresponding parts conditionally, only selecting them if modeset support is actually required. Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/662581/ Signed-off-by: Rob Clark

drm/msm: move KMS driver data to msm_kms

2025-07-05T14:13:35Z

Data for HDMI, DSI and DP blocks only makes sense for the KMS parts of the driver. Move corresponding data pointers from struct msm_drm_private to struct msm_kms. Suggested-by: Abhinav Kumar Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/662580/ Signed-off-by: Rob Clark

drm/msm: get rid of msm_drm_private::num_crtcs

2025-07-05T14:13:35Z

Drop superfluous msm_drm_private::num_crtcs in favour of using drm_mode_config::num_crtc or MAX_CRCS as appropriate. Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/662578/ Signed-off-by: Rob Clark

drm/msm: move wq handling to KMS code

2025-07-05T14:13:35Z

The global workqueue is only used for vblanks inside KMS code. Move allocation / flushing / deallcation of it to msm_kms.c Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/662573/ Signed-off-by: Rob Clark

drm/msm: Defer VMA unmap for fb unpins

2025-07-05T00:48:38Z

With the conversion to drm_gpuvm, we lost the lazy VMA cleanup, which means that fb cleanup/unpin when pageflipping to new scanout buffers immediately unmaps the scanout buffer. This is costly (with tlbinv, it can be 4-6ms for a 1080p scanout buffer, and more for higher resolutions)! To avoid this, introduce a vma_ref, which is incremented whenever userspace has a GEM handle or dma-buf fd. When unpinning if the vm is the kms->vm we defer tearing down the VMA until the vma_ref drops to zero. If the buffer is still part of a flip-chain then userspace will be holding some sort of reference to the BO, either via a GEM handle and/or dma-buf fd. So this avoids unmapping the VMA when there is a strong possibility that it will be needed again. Signed-off-by: Rob Clark Tested-by: Antonino Maniscalco Reviewed-by: Antonino Maniscalco Patchwork: https://patchwork.freedesktop.org/patch/661538/