On 3/5/2026 6:14 AM, Dmitry Baryshkov wrote:
On Wed, Mar 04, 2026 at 07:57:34AM -0800, Rob Clark wrote:On Wed, Mar 4, 2026 at 5:34 AM Dmitry Baryshkov <[email protected]> wrote:The MSM GBM backend uses MSM_GEM_NEW to allocate GEM buffers from the KMS driver, imports them into the GPU driver (msm or kgsl) and then uses them for rendering / blending. Commit 98f11fd1cf92 ("drm/msm: Take the ioctls away from the KMS-only driver") dropped all IOCTLs from the MSM KMS devices, pointing out the need to use dumb buffers, however dumb buffers should not be used by the GPU for rendering. Restore GEM-related IOCTLs for the KMS devices.We shouldn't be exposing DRIVER_RENDER on KMS-only nodes. If msm gbm is allocating from a primary node, that is problematic, since there is no guarantee that anything but the compositor has access to the primary node.We are not exposing DRIVER_RENDER for KMS-only nodes. I'll check with the correponding colleagues, what exactly is their use case, if the allocation is happening in the compositor or in the app. In the latter case, I agree, the buffers should be allocated from the GPU.
Hi Rob,In combination of msm-kms with kgsl, wayland clients allocate their own dma-bufs (typically through EGL/GLES on KGSL) and pass the fd to Weston, which imports them. Weston is therefore not allocating client buffers. GBM is mainly used for Weston-owned allocations such as render targets, composition buffers, and scanout/framebuffers. It can also be used by applications that allocate through EGL (GBM-based path).
One additional consideration is that KGSL is not a DRM driver and does not expose a DRM render node. Since |gbm_create_device()| operates on DRM devices and relies on DRM interfaces such as |drmGetVersion()|, a KGSL device cannot be used as a GBM device. As a result, the MSM DRM/KMS node remains the natural GBM allocation point in this configuration. Thus we need to add render support in msm-kms driver.
Thanks, Mahadevan
BR, -RFixes: 98f11fd1cf92 ("drm/msm: Take the ioctls away from the KMS-only driver") Signed-off-by: Dmitry Baryshkov <[email protected]> --- Note, here I assume that dumb buffers generally should not be used for rendering. That doesn't seem to be complete truth as Mesa kmsro on MSM devices uses DRM_IOCTL_MODE_CREATE_DUMB to create buffers for resources. --- drivers/gpu/drm/msm/msm_drv.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index ed2a61c66ac9..f82c9a36a166 100644 --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -799,6 +799,14 @@ static const struct drm_ioctl_desc msm_ioctls[] = { DRM_IOCTL_DEF_DRV(MSM_VM_BIND, msm_ioctl_vm_bind, DRM_RENDER_ALLOW), }; +static const struct drm_ioctl_desc msm_kms_ioctls[] = { + DRM_IOCTL_DEF_DRV(MSM_GEM_NEW, msm_ioctl_gem_new, DRM_RENDER_ALLOW), + DRM_IOCTL_DEF_DRV(MSM_GEM_INFO, msm_ioctl_gem_info, DRM_RENDER_ALLOW), + DRM_IOCTL_DEF_DRV(MSM_GEM_CPU_PREP, msm_ioctl_gem_cpu_prep, DRM_RENDER_ALLOW), + DRM_IOCTL_DEF_DRV(MSM_GEM_CPU_FINI, msm_ioctl_gem_cpu_fini, DRM_RENDER_ALLOW), + DRM_IOCTL_DEF_DRV(MSM_GEM_MADVISE, msm_ioctl_gem_madvise, DRM_RENDER_ALLOW), +}; + static void msm_show_fdinfo(struct drm_printer *p, struct drm_file *file) { struct drm_device *dev = file->minor->dev; @@ -868,6 +876,8 @@ static const struct drm_driver msm_kms_driver = { #endif MSM_FBDEV_DRIVER_OPS, .show_fdinfo = msm_show_fdinfo, + .ioctls = msm_kms_ioctls, + .num_ioctls = ARRAY_SIZE(msm_kms_ioctls), .fops = &fops, .name = "msm-kms", .desc = "MSM Snapdragon DRM", --- base-commit: ac47870fd795549f03d57e0879fc730c79119f4b change-id: 20260304-msm-restore-ioctls-2a1792311a09 Best regards, -- With best wishes Dmitry
