From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B89D02D5935 for ; Tue, 17 Mar 2026 06:41:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773729681; cv=none; b=r5TK47FXcfQGQ0TDcm1uDt6E5wx4iAcSQ24rlE5NUWWZesEkGDtGgGIL3iw5lIBXDrnYqrtPZok/19VDGiFSHzxpl6SAA+B2FSFyA2vDgRhzZPNwTR1ZsaPADGjm7HFWMq72bb8VXTEDVCUvPowU+hc52sb8KGhV/y2xM07y2CA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773729681; c=relaxed/simple; bh=o2Nnjp45J8XFW4OWyJILf4MjDxOL/y5fVrADgQA/aSQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=l2kNqXKemVYBwAJ2LMpHJHjF5kqbl66v8d/w3eEQyWBSU8R/8Uy2F14cWZX7fKoA7u48M7I4Ejocam9fbeD8OzI8m4YdP5h7cFgz+LonEHM2wXXxQ2/vfj9ublVRaGrbzYZn+nyjVCTf9HfdDrfaSF2LL+m7xPn8Rp3+f1BVxNs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=gUK14FzS; arc=none smtp.client-ip=209.85.215.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="gUK14FzS" Received: by mail-pg1-f181.google.com with SMTP id 41be03b00d2f7-c70bfef17a4so3548951a12.2 for ; Mon, 16 Mar 2026 23:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1773729679; x=1774334479; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=KlUueF1GSw5ohqS7H/vwWeUHzvF9pIfX9HHJ4AwXcpg=; b=gUK14FzSnvIP2ZQ6rJtuagfotP4XNE05x8ZQONd5mT5L61detikCymP9q609XwFzcd fjMo4SkMo5iOZoVf2WiFJ06SRHmMCq1fm0rqnzwhBR7DVuWLS2jMxSt7PDVp33EutOzn RfmHeXlM6qsMM9P+QmC2EU1/vk6fW1Y+Seqdg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773729679; x=1774334479; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KlUueF1GSw5ohqS7H/vwWeUHzvF9pIfX9HHJ4AwXcpg=; b=ofMkOrZXvp13YZCR/EPSvM2LrAmEVvFUvo9CwF7RA/Fx1Atj8yW81If8XHZIW22pht Uv5BmCFohvZr7Yi0V2lkbGLNdlMvGXkP8qq1cgFEM+q9qSUyXC+rX4NYn50yRGq4tjBt m3I+z7PbHK923c+QLucviZc45nOypRxA9303Z1KKuijhH3MIfUN35hIGFTCz48tyJsI8 JNO1fsVJ2nQDEpQbt4qjx2ay4Ab11jjjlG3c0RAlpRuDpSrAJpu+FUlBrYoRrZV0yAYt 1NhEDFDiYQwqixQ0MlNPW1NNLi6mlbOAJOhwh+6GnSb4p/rnfhrVy0NoYqc/HpEzeJRf GwTg== X-Forwarded-Encrypted: i=1; AJvYcCWyX3xt2XuNPlvwx8lBsrrn7pvNhyaWflOvx17dMK/b37o8bnUI3KsGjtdBj9AqBqGwhyjl6JTt9xlz8/Q=@vger.kernel.org X-Gm-Message-State: AOJu0YziMnRssQR1WHw6SCN0AY87rfcUf0PiqJhXuPv5iYdbaGvNQ/oB e0CyF/n616cvhsQFnkvfx1JALdJUltwNvPbIwp4/mFbUaTGTLwTxZ9vsAPPzMjQZxQ== X-Gm-Gg: ATEYQzxTZoFhENgWOBFcrv+a4a4kJOqWlX4gqq6Fbx2238hD7uOwi6IlN1lF8Qe2k2V zACgJQ7ETJyoyGmNjSG8NH2wghCw6rs2L+MZzCtcNe2KMOHipD/kczKdekwxsm1HaE6JhqcCPCg nPfM+eHXDN401zH5rEouKceiVlS1co/MQtnIVbUI8F/64Nb+uOC2U0rrAXLTc/Wt8R2htL8J1Hj ac/8FbZal+liRCWdrhlWJ4CFQp9IhBXxMVt2f8RCrCuwnACQXKa7xCRlLItRLzr8UlfW6jKUTVa +eAhth9u1oTQfmo/qEVGLyVfZYXi1Hc14WF9xofF7p7YWBuWYIqBvVK7yt+iiw/gHrZKH6srjiK draUNwurcfRMgLAj1Voz5+7th66620wN/o/FXpA5bYDv64JS3Rtwrk0OQDktWDq5HM9PxEeM4Ay 9ZeIMliQPiSnHcvN1Mt/GchHILAQPaSv0rCwhIp64xMSZpzoICDppTPdf4QPe2ZjLCt3z5gNYm+ aVUPV4G X-Received: by 2002:a17:902:cccb:b0:2b0:5903:140a with SMTP id d9443c01a7336-2b0590316d9mr69517575ad.10.1773729679022; Mon, 16 Mar 2026 23:41:19 -0700 (PDT) Received: from wenstp920.tpe.corp.google.com ([2a00:79e0:201d:8:a064:c65d:a199:5cb6]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2aece605231sm124269425ad.27.2026.03.16.23.41.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Mar 2026 23:41:18 -0700 (PDT) From: Chen-Yu Tsai To: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter Cc: Rob Herring , Laurent Pinchart , Chen-Yu Tsai , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, asahi@lists.linux.dev Subject: [PATCH v2 0/4] drm: Support DMA per allocation kernel mappings Date: Tue, 17 Mar 2026 14:40:42 +0800 Message-ID: <20260317064049.696795-1-wenst@chromium.org> X-Mailer: git-send-email 2.53.0.851.ga537e3e6e9-goog Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi everyone, This is an attempt to revive Rob Herring's "DMA per allocation kernel mappings" [1] series from 2019. This series stacks on top of my recent "drm/gem-dma: Support dedicated DMA device for allocation" series [2]. Many of the allocation paths are touched by both. The 3 driver conversions from the original series are not included, as the changes have landed in some other form. Patch 1 makes the rcar-du driver use one of the GEM DMA helpers to get a scatter gather table, instead of calling dma_get_sgtable() directly. This reduces one location where the DMA APIs are directly used with drm_gem_dma_object outside the helpers. Patch 2 adds the kernel internal DRM_MODE_DUMB_KERNEL_MAP flag. Patch 3 adds the dma_attr field to drm_gem_dma_object, and converts the GEM DMA helpers to use the dma_*_attrs() variant of the DMA API. Patch 4 adds support for DRM_MODE_DUMB_KERNEL_MAP to the GEM DMA helpers by setting the DMA_ATTR_NO_KERNEL_MAPING attribute for requests without the DRM_MODE_DUMB_KERNEL_MAP flag. Existing callers of drm_gem_dma_dumb_create_internal(), with the exception of adp, all use the DRM client API, and otherwise do not have any direct use of the kernel mapping. Thus only the adp driver gains setting DRM_MODE_DUMB_KERNEL_MAP before calling drm_gem_dma_dumb_create_internal(). I have also started to convert the exynos driver to use the GEM DMA helpers. I also plan on looking into the rockchip driver, but that one has a separate IOMMU path that needs to be handled. I might copy the approach used in the exynos driver to deal with it. Changes compared to the original version from Rob (v1): - Link to original v1: https://lore.kernel.org/dri-devel/20191021214550.1461-1-robh@kernel.org/ - Rebased onto renamed GEM DMA helpers - New patch for rcar-du - Patch 2 - Make drm_mode_create_dumb_ioctl() emit warning if args->flags is not zero - Patch 3 - Made vc4_bo_purge() use dma_free_attrs(); this is the other location of DMA API used with drm_gem_dma_object outside the helpers - Expanded commit message - Patch 4 - Added kernal mapping check in drm_fb_dma_get_scanout_buffer() and drm_gem_dma_vmap(). - Made drm_gem_dma_print_info() show "vaddr=(no mapping)" for objects allocated without kernel mapping - Dropped existing DRM_MODE_DUMB_KERNEL_MAP flag addition in various drivers - Added DRM_MODE_DUMB_KERNEL_MAP flag to adp_drm_gem_dumb_create() - Added flags field kerneldoc for drm_gem_dma_create_with_handle() I dropped all the original Reviewed-by tags, as it's been 5 years since the changes were first posted, and also because the code has changed a lot. Please have a look. Thanks ChenYu Original cover letter from Rob: This series adds support for CMA/DMA users to skip kernel mappings for GEM allocations. The DMA API only guarantees a kernel mapping at allocation time. Creating mappings with vmap() after allocation may or may not work as not all allocations have a struct page. As virtual memory space is limited on 32-bit systems some drivers will skip kernel mappings when possible. This prevents those drivers from using CMA helpers and the generic fbdev emulation which results in a lot of duplicated code. In order to distinguish between kernel and userspace allocations, a new flag, DRM_MODE_DUMB_KERNEL_MAP, for drm_mode_create_dumb() is introduced. This allows drivers to override the default behavior for CMA helpers of always creating a kernel mapping. Mediatek is converted to CMA helpers and Rockchip is converted to generic fbdev support. I also have patches to convert Rockchip to CMA and shmem helpers, but they need a bit more work. Exynos can also probably be converted to use CMA helpers. Compile tested only. I did test fbdev on Rockchip, but the h/w I have has an IOMMU, so the CMA code path doesn't get tested. - end quote - [1] https://lore.kernel.org/dri-devel/20191021214550.1461-1-robh@kernel.org/ [2] https://lore.kernel.org/all/20260311094929.3393338-1-wenst@chromium.org/ Chen-Yu Tsai (1): drm/rcar-du: Use drm_gem_dma_get_sg_table() helper to get scatter gather table Rob Herring (3): drm: Introduce DRM_MODE_DUMB_KERNEL_MAP flag drm/gem-dma: Use the dma_*_attr API variant drm/gem-dma: Support DRM_MODE_DUMB_KERNEL_MAP flag drivers/gpu/drm/adp/adp_drv.c | 1 + drivers/gpu/drm/drm_client.c | 1 + drivers/gpu/drm/drm_dumb_buffers.c | 4 + drivers/gpu/drm/drm_fb_dma_helper.c | 4 + drivers/gpu/drm/drm_gem_dma_helper.c | 93 ++++++++++++------- drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c | 12 ++- drivers/gpu/drm/vc4/vc4_bo.c | 2 +- include/drm/drm_gem_dma_helper.h | 3 + include/uapi/drm/drm_mode.h | 2 + 9 files changed, 82 insertions(+), 40 deletions(-) -- 2.53.0.851.ga537e3e6e9-goog