From nobody Mon Oct 6 13:35:40 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 42B34298CB5; Mon, 21 Jul 2025 11:17:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753096663; cv=none; b=GADagV8WfyYYSbYTv0oZDS/PaPGQStK5upr3G45w7jPmfACyN4w8sQA24gLSmMLW2dPYbvKPISX0RvJQLdMrhOtAjLvzavWCVVuCMeqhTDW4D56mUmMz7ClKDnSM37N0YjEgefPMXxrzInnjGA21wyxC7X8LItefk+Llm8NrSWQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753096663; c=relaxed/simple; bh=pkewGPjjFTsNcaE929R2dk9XfsEdn97c4Fm1Zzq1x+Q=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=DQasfn1IVrDLl3oKG8sRvGASZuXC4r/zGdMWrzM8ZZxk6lnhnPm9iytYw1Q0+0G+CiWiSsN24i13fj+7y+4bzRerQBDhqLPLO2Y1Z0dw+aWNmlvrdkdDvRHRXhG00tk/DExnqoKS7gCTQCNQ7eayxad/bzozijpEyAgKb+re6GU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GqV4pDpe; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GqV4pDpe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4DBEFC4CEF1; Mon, 21 Jul 2025 11:17:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1753096662; bh=pkewGPjjFTsNcaE929R2dk9XfsEdn97c4Fm1Zzq1x+Q=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=GqV4pDpem7xWd3kdcpmPqvV1GCbzoSWmbz48gxbnNSFR9tKsvgPOcEFjGr+ed191y lNUUyN1qWGANt+vd6COVjF7q1f5dwzaa6Uh7KcJCS8Q50dvVc/oPsSBy1Cp4pXQIAi GArxYtNjWLzh6iGG/8udiFM8jtJ0lPP6oc3btVI/H6MA+ARxAiaHxas9A8vTbszMuV WzdsAp5iipxa5I6P6lLmiHOUH55Q1ZntH8yYf4KrjWpvl4/OvlUENeC7vONjnit5mE H+xK/RXfwOTkRS03nGyS6i21irG26EXUYW4LiNCtfVm6aLyixAx4qG58ZTp3NEHp+S XL40SWpwYS+VA== From: Maxime Ripard Date: Mon, 21 Jul 2025 13:17:30 +0200 Subject: [PATCH v7 1/5] doc: dma-buf: List the heaps by name Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250721-dma-buf-ecc-heap-v7-1-031836e1a942@kernel.org> References: <20250721-dma-buf-ecc-heap-v7-0-031836e1a942@kernel.org> In-Reply-To: <20250721-dma-buf-ecc-heap-v7-0-031836e1a942@kernel.org> To: Rob Herring , Saravana Kannan , Sumit Semwal , Benjamin Gaignard , Brian Starkey , John Stultz , "T.J. Mercier" , =?utf-8?q?Christian_K=C3=B6nig?= , Krzysztof Kozlowski , Conor Dooley , Marek Szyprowski , Robin Murphy , Jonathan Corbet Cc: Andrew Davis , Jared Kangas , Mattijs Korpershoek , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, iommu@lists.linux.dev, linux-doc@vger.kernel.org, Maxime Ripard X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=2482; i=mripard@kernel.org; h=from:subject:message-id; bh=pkewGPjjFTsNcaE929R2dk9XfsEdn97c4Fm1Zzq1x+Q=; b=owGbwMvMwCmsHn9OcpHtvjLG02pJDBl1iudmqnneWB99U9twXZvdjSCWd0Ysmnx3UrJn6/z+H L+XLVajYyoLgzAng6yYIssTmbDTy9sXVznYr/wBM4eVCWQIAxenAExk+yvGSsbjJrP15C0e2ust TRFdkOwlN/G2d+fbU1aRvntKby4w/F51MG1/r9SjbJ3oH57c0vu3MdY7nBLcG79HtWifaepSdpM Dq+fc9WVQsomef+vuLx+VOdaVaU+Ye56Xeas23ChxO7xmHjMA X-Developer-Key: i=mripard@kernel.org; a=openpgp; fpr=BE5675C37E818C8B5764241C254BCFC56BF6CE8D Since we're going to introduce multiple instances of the CMA heap driver, there's no single CMA heap anymore. Let's use the heap name instead to differentiate between all the heaps available in the system. While we're at it, let's also rework the backward compatibility part to make it easier to amend later on. Signed-off-by: Maxime Ripard Reviewed-by: T.J. Mercier --- Documentation/userspace-api/dma-buf-heaps.rst | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/= userspace-api/dma-buf-heaps.rst index 1dfe5e7acd5a3c674323775176d81944147e40c0..17bf6829efd7963bc849765db54= d327644e8c395 100644 --- a/Documentation/userspace-api/dma-buf-heaps.rst +++ b/Documentation/userspace-api/dma-buf-heaps.rst @@ -14,15 +14,16 @@ Heaps A heap represents a specific allocator. The Linux kernel currently support= s the following heaps: =20 - The ``system`` heap allocates virtually contiguous, cacheable, buffers. =20 - - The ``cma`` heap allocates physically contiguous, cacheable, - buffers. Only present if a CMA region is present. Such a region is - usually created either through the kernel commandline through the - ``cma`` parameter, a memory region Device-Tree node with the - ``linux,cma-default`` property set, or through the ``CMA_SIZE_MBYTES`` = or - ``CMA_SIZE_PERCENTAGE`` Kconfig options. The heap's name in devtmpfs is - ``default_cma_region``. For backwards compatibility, when the - ``DMABUF_HEAPS_CMA_LEGACY`` Kconfig option is set, a duplicate node is - created following legacy naming conventions; the legacy name might be - ``reserved``, ``linux,cma``, or ``default-pool``. + - The ``default_cma_region`` heap allocates physically contiguous, + cacheable, buffers. Only present if a CMA region is present. Such a + region is usually created either through the kernel commandline + through the ``cma`` parameter, a memory region Device-Tree node with + the ``linux,cma-default`` property set, or through the + ``CMA_SIZE_MBYTES`` or ``CMA_SIZE_PERCENTAGE`` Kconfig options. Prior + to Linux 6.17, its name wasn't stable and could be called + ``reserved``, ``linux,cma``, or ``default-pool``, depending on the + platform. From Linux 6.17 onwards, the creation of these heaps is + controlled through the ``DMABUF_HEAPS_CMA_LEGACY`` Kconfig option for + backwards compatibility. --=20 2.50.1 From nobody Mon Oct 6 13:35:40 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 85F4B29B224; Mon, 21 Jul 2025 11:17:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753096666; cv=none; b=fFiVBBKz8vwq2BHSWDskIPwQgcHhBkX66UuRFusdK6JlGtlp7U1q3BOzueh70lEX9+mWuedb7ECjYYEMBS3Q6wVfCUHjenLmPRMGt1ttN0aD1cE7UHGpYuz2hOFVXTQDIouyvVP/kYdhOS2ebLpu3VBRKnnsfkvnNP5GFvbxXuw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753096666; c=relaxed/simple; bh=R7s2QbS4Azf34q7ntE4fERc43u45qADiAo0EY/vnlUc=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=AYi8QJdw3bYebdwpDKWPkfa0n0Xvl/84Vit/tOuC+ztT18bUabs0Epw6XI5FVMxNdZic00e421oIJTU7CHyhuKMj/3YKgyUphzeeS7/gIi4HZWyyYY6vaRUvXzOpt2kfu6RIb7wR2GQx+bB66RaJJ3h+6aYNiZ6YhjtJ4NAQ4LQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=M5c43dVK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="M5c43dVK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80451C4CEF4; Mon, 21 Jul 2025 11:17:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1753096666; bh=R7s2QbS4Azf34q7ntE4fERc43u45qADiAo0EY/vnlUc=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=M5c43dVKRdS8yfXBHGPXTHwZQdKOKbCFNZAm8Z1ZiQQWHUHcJOyxs3hDAi5nsNuzD 4pujLp02qa77Lh/iVo05aA1Vu1GKyEtzrh95kRaKCIe6EAcwwaq/3dg3a51sBoaY3C c9bLlqJ7ILNUpDzrI76xRnmXcWNOgKbwvS1KJTEVWJsdnS6e1ZJA628ust75UyxNDh FYnu1ASU1HGhnlVNhR+MRNaHxrC0bkFzeQKw3b6XPqcBxrS3NwYC2RqZk795s3A10d LUMAoYIj4a1fz36DOny0jMIymAHBUeFANuTR2jLPzRFAiwn/niBCtx2E4ewVtKu4Pb FCEFCt80FewQQ== From: Maxime Ripard Date: Mon, 21 Jul 2025 13:17:31 +0200 Subject: [PATCH v7 2/5] dma-buf: heaps: cma: Register list of CMA regions at boot Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250721-dma-buf-ecc-heap-v7-2-031836e1a942@kernel.org> References: <20250721-dma-buf-ecc-heap-v7-0-031836e1a942@kernel.org> In-Reply-To: <20250721-dma-buf-ecc-heap-v7-0-031836e1a942@kernel.org> To: Rob Herring , Saravana Kannan , Sumit Semwal , Benjamin Gaignard , Brian Starkey , John Stultz , "T.J. Mercier" , =?utf-8?q?Christian_K=C3=B6nig?= , Krzysztof Kozlowski , Conor Dooley , Marek Szyprowski , Robin Murphy , Jonathan Corbet Cc: Andrew Davis , Jared Kangas , Mattijs Korpershoek , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, iommu@lists.linux.dev, linux-doc@vger.kernel.org, Maxime Ripard X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=3200; i=mripard@kernel.org; h=from:subject:message-id; bh=R7s2QbS4Azf34q7ntE4fERc43u45qADiAo0EY/vnlUc=; b=owGbwMvMwCmsHn9OcpHtvjLG02pJDBl1iueFmubE8sh4cE/n37Og4euG4K4e28ZYp+65v194C m6zEJ3cMZWFQZiTQVZMkeWJTNjp5e2LqxzsV/6AmcPKBDKEgYtTACbSuJmxPq0019SlcuZa3cK4 VTzV+wK9zkf9OJWVNF/ty6yKjHk5HIzFz0zys/957zu3WO+hWw0bY8PkENvmvtg/TlxMfVU817w i+h3TDm3v9d3juIDfj/vSDZFz/P9/b7y+vmrvxbvnjVtnswIA X-Developer-Key: i=mripard@kernel.org; a=openpgp; fpr=BE5675C37E818C8B5764241C254BCFC56BF6CE8D In order to create a CMA heap instance for each CMA region found in the system, we need to register each of these instances. While it would appear trivial, the CMA regions are created super early in the kernel boot process, before most of the subsystems are initialized. Thus, we can't just create an exported function to create a heap from the CMA region being initialized. What we can do however is create a two-step process, where we collect all the CMA regions into an array early on, and then when we initialize the heaps we iterate over that array and create the heaps from the CMA regions we collected. Signed-off-by: Maxime Ripard Reviewed-by: T.J. Mercier --- MAINTAINERS | 1 + drivers/dma-buf/heaps/cma_heap.c | 14 ++++++++++++++ include/linux/dma-buf/heaps/cma.h | 16 ++++++++++++++++ 3 files changed, 31 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index fad6cb025a1918beec113b576cf28b76151745ef..deb6930f28c82a7257f1d4610b9= bc010de62a0c9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7095,10 +7095,11 @@ T: git https://gitlab.freedesktop.org/drm/misc/kern= el.git F: Documentation/driver-api/dma-buf.rst F: Documentation/userspace-api/dma-buf-alloc-exchange.rst F: drivers/dma-buf/ F: include/linux/*fence.h F: include/linux/dma-buf.h +F: include/linux/dma-buf/ F: include/linux/dma-resv.h K: \bdma_(?:buf|fence|resv)\b =20 DMA GENERIC OFFLOAD ENGINE SUBSYSTEM M: Vinod Koul diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_h= eap.c index 0df007111975447d555714d61ead9699287fd65a..2a901af635ed76cdb085915c032= 58c235e302792 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -12,10 +12,11 @@ =20 #define pr_fmt(fmt) "cma_heap: " fmt =20 #include #include +#include #include #include #include #include #include @@ -25,10 +26,23 @@ #include #include =20 #define DEFAULT_CMA_NAME "default_cma_region" =20 +static struct cma *dma_areas[MAX_CMA_AREAS] __initdata; +static unsigned int dma_areas_num __initdata; + +int __init dma_heap_cma_register_heap(struct cma *cma) +{ + if (dma_areas_num >=3D ARRAY_SIZE(dma_areas)) + return -EINVAL; + + dma_areas[dma_areas_num++] =3D cma; + + return 0; +} + struct cma_heap { struct dma_heap *heap; struct cma *cma; }; =20 diff --git a/include/linux/dma-buf/heaps/cma.h b/include/linux/dma-buf/heap= s/cma.h new file mode 100644 index 0000000000000000000000000000000000000000..e751479e21e703e24a5f799b4a7= fc8bd0df3c1c4 --- /dev/null +++ b/include/linux/dma-buf/heaps/cma.h @@ -0,0 +1,16 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef DMA_BUF_HEAP_CMA_H_ +#define DMA_BUF_HEAP_CMA_H_ + +struct cma; + +#ifdef CONFIG_DMABUF_HEAPS_CMA +int dma_heap_cma_register_heap(struct cma *cma); +#else +static inline int dma_heap_cma_register_heap(struct cma *cma) +{ + return 0; +} +#endif // CONFIG_DMABUF_HEAPS_CMA + +#endif // DMA_BUF_HEAP_CMA_H_ --=20 2.50.1 From nobody Mon Oct 6 13:35:40 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 13E6929C355; Mon, 21 Jul 2025 11:17:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753096669; cv=none; b=A1oXj3VNaeJJ4HoUDFAlJfjzKSDj3g+Haqh5PjfsHfl56RWeRRxu11g06Sv3a3ESoSEjp8VxiDgdwRDaQ5fv7Ho9o987yxArF6oJFtDkMvv8Ed2WMg8nkH4Yg4KNk1I7JodTYR4D/SkkmWjP9Ppmz/SL5PRfzL77x1UZCsSMZ2A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753096669; c=relaxed/simple; bh=JC2kgPKoyopfcstm3FBIUDMnngpOTv3PR1mdR6IDQVs=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Isv4v0MYAo0AeAphdwlLTdH2s1C6TVvF/GObfgyz6GEAJShtgTpPAK9UOSj3LKXvKN2kiKtT7o7HFrcPB49Ierf3a8SlIifdNMa7SvmtDVsFBctubUmYS42c3IgRoOPj8U5GNUvZGfVN8Eis4CvAOJjoqrM5NMzGpaoh4800bBE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Eau9nt4A; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Eau9nt4A" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 42FFEC4CEF1; Mon, 21 Jul 2025 11:17:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1753096668; bh=JC2kgPKoyopfcstm3FBIUDMnngpOTv3PR1mdR6IDQVs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=Eau9nt4AQV8tXUIP9uyzwmDBrWVu6v1xYLmnvytopjcWchfHjNFH8PZDJbI4ocH+m Ixp9nVAmCp+H4t1BOl3KFPPCswjSnM6Gb/Rrb+QsQoScDc32hJ/9gnHl6xuc0EEWaM bS3mM3nPP2MtG0ThHlc63yxPECmOGdldEahF6WTS8llEaQVwkKvN08U+cXI70ZspGu dnWXIiRACxcabd5G3EhDdWhjwyfJEYC7SGwPk0GyQLN2N/hV0EDheb2fQtxp9BeKIe SLwcIv9Kzgv0MJ4jGtXDEG80ep04wlWpUriFb7Zkxb6OmvyRyF5vWPyPHMmjW3e73q PvH0T3UaY6pTQ== From: Maxime Ripard Date: Mon, 21 Jul 2025 13:17:32 +0200 Subject: [PATCH v7 3/5] dma: contiguous: Register reusable CMA regions at boot Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250721-dma-buf-ecc-heap-v7-3-031836e1a942@kernel.org> References: <20250721-dma-buf-ecc-heap-v7-0-031836e1a942@kernel.org> In-Reply-To: <20250721-dma-buf-ecc-heap-v7-0-031836e1a942@kernel.org> To: Rob Herring , Saravana Kannan , Sumit Semwal , Benjamin Gaignard , Brian Starkey , John Stultz , "T.J. Mercier" , =?utf-8?q?Christian_K=C3=B6nig?= , Krzysztof Kozlowski , Conor Dooley , Marek Szyprowski , Robin Murphy , Jonathan Corbet Cc: Andrew Davis , Jared Kangas , Mattijs Korpershoek , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, iommu@lists.linux.dev, linux-doc@vger.kernel.org, Maxime Ripard X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1536; i=mripard@kernel.org; h=from:subject:message-id; bh=JC2kgPKoyopfcstm3FBIUDMnngpOTv3PR1mdR6IDQVs=; b=owGbwMvMwCmsHn9OcpHtvjLG02pJDBl1iucP++yv60//o8bzs84oo+zI+/+/Ldc802ZYuKft+ T6Gvx4BHVNZGIQ5GWTFFFmeyISdXt6+uMrBfuUPmDmsTCBDGLg4BWAiXX8YGxaZfZjdv/2HM2+6 Xf2L5KuCTzm5t6pH/5y3hyfzqMXBXfWTnFkfNP7k71lqwTV/deQuY8aGWRtcXty6WRr7M/nGp8j XGzycq7b6fv0SLGq1Q+BffNIiL6PZlgGu93eLnl+uub1mwh1xAA== X-Developer-Key: i=mripard@kernel.org; a=openpgp; fpr=BE5675C37E818C8B5764241C254BCFC56BF6CE8D In order to create a CMA dma-buf heap instance for each CMA heap region in the system, we need to collect all of them during boot. They are created from two main sources: the reserved-memory regions in the device tree, and the default CMA region created from the configuration or command line parameters, if no default region is provided in the device tree. Let's collect all the device-tree defined CMA regions flagged as reusable. Signed-off-by: Maxime Ripard Reviewed-by: T.J. Mercier --- kernel/dma/contiguous.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c index 8df0dfaaca18eeb0a20145512ba64425d2e7601e..e81982c0ee8f5c0654731adb611= df4bcc4637c7c 100644 --- a/kernel/dma/contiguous.c +++ b/kernel/dma/contiguous.c @@ -40,10 +40,11 @@ #include =20 #include #include #include +#include #include #include #include =20 #ifdef CONFIG_CMA_SIZE_MBYTES @@ -490,9 +491,13 @@ static int __init rmem_cma_setup(struct reserved_mem *= rmem) rmem->priv =3D cma; =20 pr_info("Reserved memory: created CMA memory pool at %pa, size %ld MiB\n", &rmem->base, (unsigned long)rmem->size / SZ_1M); =20 + err =3D dma_heap_cma_register_heap(cma); + if (err) + pr_warn("Couldn't register CMA heap."); + return 0; } RESERVEDMEM_OF_DECLARE(cma, "shared-dma-pool", rmem_cma_setup); #endif --=20 2.50.1 From nobody Mon Oct 6 13:35:40 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7FCE92BCF45; Mon, 21 Jul 2025 11:17:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753096671; cv=none; b=AI/7gYeL+n4qNUyyITTQU6QSvOHgzR+a4tKBg/T2lHTPWYS32A48c4PkhE2VM6fzFUByI3A8Wfrcwh+9rNpE0TWQqr2TR1QKlWfcbRdijF7Yj28aY4df7JmjOTvepNF8knLjDpoNb9gN72fH2RtCad3clWLfPER/+8C+eVYjKQ0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753096671; c=relaxed/simple; bh=ZzIQMj2Qi1QqJ5MVd3O/jzU3y2DI0Os/GobSPh/q4e0=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=mu7D8k4UIrrNGrfx0C6FMCw6MXqoUhLmLiV6dv27g0n11/mqQG24PnFIOA76DcgcFoze/KDRyu0OYciRRKYU5C1RLQjctSZg53kzfJnL8wvpfVn0UMJP93Llf+MJZYNvX6TMWMTPsEF/pnUhNq7ez6u3CFu/5BV3c2zCQkvRoBY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gUIi1Mjc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gUIi1Mjc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ECDBAC4CEF4; Mon, 21 Jul 2025 11:17:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1753096671; bh=ZzIQMj2Qi1QqJ5MVd3O/jzU3y2DI0Os/GobSPh/q4e0=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=gUIi1MjcCWbuCDNdOxoH5rN4rx4xBzEi4zWIucdoBrEq6oduafd5YMuf/TqV1JO6r D0LYbKlJF0SqRJ9PcU+c8Tnffy7lGwUF6zThZlDK+DOAGMiBWDgrzWf7W7bARt8v/f fJgtlsjhkpcQBM3ZKAfEKFSvs+UDaMWHpHigCAyh8eXdXC2OY3yzJT9dx5/dBGjfkH ciMlAzwpFZhnQCbTgV1eFG6KBCliTEN3j0CqFaZeVO2bQuoSi9at45V5hqmapVRNQL fVNOq2Nwvvf42gcINScoZirZDuMJVQxNa3dJrXUAcHe+CIuj9IJi1ubYFVhBqlRC4m ZUMFffImy6Tyw== From: Maxime Ripard Date: Mon, 21 Jul 2025 13:17:33 +0200 Subject: [PATCH v7 4/5] dma: contiguous: Reserve default CMA heap Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250721-dma-buf-ecc-heap-v7-4-031836e1a942@kernel.org> References: <20250721-dma-buf-ecc-heap-v7-0-031836e1a942@kernel.org> In-Reply-To: <20250721-dma-buf-ecc-heap-v7-0-031836e1a942@kernel.org> To: Rob Herring , Saravana Kannan , Sumit Semwal , Benjamin Gaignard , Brian Starkey , John Stultz , "T.J. Mercier" , =?utf-8?q?Christian_K=C3=B6nig?= , Krzysztof Kozlowski , Conor Dooley , Marek Szyprowski , Robin Murphy , Jonathan Corbet Cc: Andrew Davis , Jared Kangas , Mattijs Korpershoek , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, iommu@lists.linux.dev, linux-doc@vger.kernel.org, Maxime Ripard X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=1401; i=mripard@kernel.org; h=from:subject:message-id; bh=ZzIQMj2Qi1QqJ5MVd3O/jzU3y2DI0Os/GobSPh/q4e0=; b=owGbwMvMwCmsHn9OcpHtvjLG02pJDBl1iuelfs8VOPHLoe/KrNPHHM0Nm66V73jbeD5/01ejs 6tvWIgf7JjKwiDMySArpsjyRCbs9PL2xVUO9it/wMxhZQIZwsDFKQATyUxlrBXXkMldt8Le7dq6 TcnTZ27M++O6OmZDouq7jdf8zFcemXXWWljs0U3WN+dDc+RZpn6arc/Y8OZE+T+ODeFP9nZrRYk 9V473CFUocf5X1rPE4Ful3/8/1h9c2k7a8HyqV+6+vCx5q58jAA== X-Developer-Key: i=mripard@kernel.org; a=openpgp; fpr=BE5675C37E818C8B5764241C254BCFC56BF6CE8D The CMA code, in addition to the reserved-memory regions in the device tree, will also register a default CMA region if the device tree doesn't provide any, with its size and position coming from either the kernel command-line or configuration. Let's register that one for use to create a heap for it. Signed-off-by: Maxime Ripard Reviewed-by: T.J. Mercier --- kernel/dma/contiguous.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c index e81982c0ee8f5c0654731adb611df4bcc4637c7c..7aec2a559607b86e4d9df33ae2c= 004f7fb30fff1 100644 --- a/kernel/dma/contiguous.c +++ b/kernel/dma/contiguous.c @@ -237,17 +237,23 @@ void __init dma_contiguous_reserve(phys_addr_t limit) selected_size =3D max(size_bytes, cma_early_percent_memory()); #endif } =20 if (selected_size && !dma_contiguous_default_area) { + int ret; + pr_debug("%s: reserving %ld MiB for global area\n", __func__, (unsigned long)selected_size / SZ_1M); =20 dma_contiguous_reserve_area(selected_size, selected_base, selected_limit, &dma_contiguous_default_area, fixed); + + ret =3D dma_heap_cma_register_heap(dma_contiguous_default_area); + if (ret) + pr_warn("Couldn't register default CMA heap."); } } =20 void __weak dma_contiguous_early_fixup(phys_addr_t base, unsigned long size) --=20 2.50.1 From nobody Mon Oct 6 13:35:40 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 97AA4298248; Mon, 21 Jul 2025 11:17:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753096674; cv=none; b=muk/1D3dd30V1n72UhzZuZqiOhZ39QaLcDaqtRsa590/vDr6TqlwC7jNzHv+9Imjc4tCiySuezdj+/k2TAqlJkstphVFxv5iDZEB9vn2ZpMH8swKAFVA0vMJsjQHd7V5deI2xkaXBo8NCSQGTxh9sKGWzRgHFc1ijFv9xzqZRBk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753096674; c=relaxed/simple; bh=4T4b5ZbeftLTM3SsRon2K5QG8xDtblIGsfG23CADlSM=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=etswd9kBO0MkLeA064JIHrhROobNNKwW+gV1rSjdzFWxGZ6GeZKy5l8LW59qq4pllFA9CNFxM2AC7A3VzPxC1vr70AHyByyTQvc5IYicp9viF98fpm2HtEgWTJ9XiuEy8MNlil6IYEpYIB3q62Hg432cOuhj+wX3BY6lZBP/nDY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=j8uRdNR6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="j8uRdNR6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 87B00C4CEED; Mon, 21 Jul 2025 11:17:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1753096673; bh=4T4b5ZbeftLTM3SsRon2K5QG8xDtblIGsfG23CADlSM=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=j8uRdNR6aR8U6g8Ri5MWh9mk4cwJfet6aiu2HdwP4/QKIwasSYan9QORGc2/gZQ50 BumIi9ewUP6yZoZnfxGhtRXIQQcyEJbPwn+A0IrwNA5Laal3c/hk1Y43gBHGNVSLCM 9sFb9lTcVKjfyhkN2uI2qBjWFC2MQIcci+rMbwCUqrC2IAC3/dHSPbMMO5P3Uo3mwo FyQN2sLdAx+4YpbZig9rlrBn9Mi4pKKVLsZykcClGLrARxfG/RdVNSFLdFtGxdA9uO 9/yiv7nGJJIMtYtkKYOSQBSLenI3aiBAF9CnPz+XKB9H6JF6V/w0GfR3D3UtUHvuuh r1ffJsA2ZcsQA== From: Maxime Ripard Date: Mon, 21 Jul 2025 13:17:34 +0200 Subject: [PATCH v7 5/5] dma-buf: heaps: cma: Create CMA heap for each CMA reserved region Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20250721-dma-buf-ecc-heap-v7-5-031836e1a942@kernel.org> References: <20250721-dma-buf-ecc-heap-v7-0-031836e1a942@kernel.org> In-Reply-To: <20250721-dma-buf-ecc-heap-v7-0-031836e1a942@kernel.org> To: Rob Herring , Saravana Kannan , Sumit Semwal , Benjamin Gaignard , Brian Starkey , John Stultz , "T.J. Mercier" , =?utf-8?q?Christian_K=C3=B6nig?= , Krzysztof Kozlowski , Conor Dooley , Marek Szyprowski , Robin Murphy , Jonathan Corbet Cc: Andrew Davis , Jared Kangas , Mattijs Korpershoek , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, iommu@lists.linux.dev, linux-doc@vger.kernel.org, Maxime Ripard X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=5786; i=mripard@kernel.org; h=from:subject:message-id; bh=4T4b5ZbeftLTM3SsRon2K5QG8xDtblIGsfG23CADlSM=; b=owGbwMvMwCmsHn9OcpHtvjLG02pJDBl1ihcmWzFvfXJ31g6hiiVfFN/G/ZcPuvjx6RqG1L2Z6 6TY/Hbv75jKwiDMySArpsjyRCbs9PL2xVUO9it/wMxhZQIZwsDFKQAT+VDFWJ9gc8I3VT/vxme5 mKJNOUqzO6eVKL2OuH619yVbhWzFI+/wnLSbYVve2rZHHCxZcOjBGcaGyaufS3xeoZeq5W9XLal ecatbdeMLndCXTI7zap1yw5qd5gQVqE9q6etuYVY8Jd0cmw4A X-Developer-Key: i=mripard@kernel.org; a=openpgp; fpr=BE5675C37E818C8B5764241C254BCFC56BF6CE8D Aside from the main CMA region, it can be useful to allow userspace to allocate from the other CMA reserved regions. Indeed, those regions can have specific properties that can be useful to a specific us-case. For example, one of them platform I've been with has ECC enabled on the entire memory but for a specific region. Using that region to allocate framebuffers can be particular beneficial because enabling the ECC has a performance and memory footprint cost. Thus, exposing these regions as heaps user-space can allocate from and import wherever needed allows to cover that use-case. For now, only shared-dma-pools regions with the reusable property (ie, backed by CMA) are supported, but eventually we'll want to support other DMA pools types. Since we collected all the CMA regions created during boot, we can simply iterate over all of them to create the heaps. This has a weird interaction with the recent work on the CMA name, in particular the backward compatibility code created by commit 854acbe75ff4 ("dma-buf: heaps: Give default CMA heap a fixed name"). Indeed, the old name was either 'reserved', or the name of the reserved-memory region device tree node if the linux,cma-default property was set. In both these cases, we have now collected this region during boot, and we're using the same name. So we're now largely redundant with the code to handle backward compatibility code, and we can thus remove it and the associated Kconfig option. Signed-off-by: Maxime Ripard Reviewed-by: T.J. Mercier --- Documentation/userspace-api/dma-buf-heaps.rst | 9 +++++--- drivers/dma-buf/heaps/Kconfig | 10 -------- drivers/dma-buf/heaps/cma_heap.c | 33 +++++++++++++----------= ---- 3 files changed, 22 insertions(+), 30 deletions(-) diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/= userspace-api/dma-buf-heaps.rst index 17bf6829efd7963bc849765db54d327644e8c395..b78d2faeba62cda721a1f49d49e= 02bcb520ad429 100644 --- a/Documentation/userspace-api/dma-buf-heaps.rst +++ b/Documentation/userspace-api/dma-buf-heaps.rst @@ -22,8 +22,11 @@ following heaps: through the ``cma`` parameter, a memory region Device-Tree node with the ``linux,cma-default`` property set, or through the ``CMA_SIZE_MBYTES`` or ``CMA_SIZE_PERCENTAGE`` Kconfig options. Prior to Linux 6.17, its name wasn't stable and could be called ``reserved``, ``linux,cma``, or ``default-pool``, depending on the - platform. From Linux 6.17 onwards, the creation of these heaps is - controlled through the ``DMABUF_HEAPS_CMA_LEGACY`` Kconfig option for - backwards compatibility. + platform. + + - A heap will be created for each reusable region in the device tree + with the ``shared-dma-pool`` compatible, using the full device tree + node name as its name. The buffer semantics are identical to + ``default-cma-region``. diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig index bb369b38b001af51721b56e065df92825022f1f1..a5eef06c422644e8aadaf5aff2b= d9a33c49c1ba3 100644 --- a/drivers/dma-buf/heaps/Kconfig +++ b/drivers/dma-buf/heaps/Kconfig @@ -10,15 +10,5 @@ config DMABUF_HEAPS_CMA depends on DMABUF_HEAPS && DMA_CMA help Choose this option to enable dma-buf CMA heap. This heap is backed by the Contiguous Memory Allocator (CMA). If your system has these regions, you should say Y here. - -config DMABUF_HEAPS_CMA_LEGACY - bool "Legacy DMA-BUF CMA Heap" - default y - depends on DMABUF_HEAPS_CMA - help - Add a duplicate CMA-backed dma-buf heap with legacy naming derived - from the CMA area's devicetree node, or "reserved" if the area is not - defined in the devicetree. This uses the same underlying allocator as - CONFIG_DMABUF_HEAPS_CMA. diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_h= eap.c index 2a901af635ed76cdb085915c03258c235e302792..42f88193eab9f8f4571064c7b3b= 8a73bca20fdf4 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -20,10 +20,12 @@ #include #include #include #include #include +#include +#include #include #include #include =20 #define DEFAULT_CMA_NAME "default_cma_region" @@ -407,35 +409,32 @@ static int __init __add_cma_heap(struct cma *cma, con= st char *name) } =20 return 0; } =20 -static int __init add_default_cma_heap(void) +static int __init add_cma_heaps(void) { struct cma *default_cma =3D dev_get_cma_area(NULL); - const char *legacy_cma_name; + unsigned int i; int ret; =20 - if (!default_cma) - return 0; + if (default_cma) { + ret =3D __add_cma_heap(default_cma, DEFAULT_CMA_NAME); + if (ret) + return ret; + } =20 - ret =3D __add_cma_heap(default_cma, DEFAULT_CMA_NAME); - if (ret) - return ret; + for (i =3D 0; i < dma_areas_num; i++) { + struct cma *cma =3D dma_areas[i]; =20 - if (IS_ENABLED(CONFIG_DMABUF_HEAPS_CMA_LEGACY)) { - legacy_cma_name =3D cma_get_name(default_cma); - if (!strcmp(legacy_cma_name, DEFAULT_CMA_NAME)) { - pr_warn("legacy name and default name are the same, skipping legacy hea= p\n"); - return 0; + ret =3D __add_cma_heap(cma, cma_get_name(cma)); + if (ret) { + pr_warn("Failed to add CMA heap %s", cma_get_name(cma)); + continue; } =20 - ret =3D __add_cma_heap(default_cma, legacy_cma_name); - if (ret) - pr_warn("failed to add legacy heap: %pe\n", - ERR_PTR(ret)); } =20 return 0; } -module_init(add_default_cma_heap); +module_init(add_cma_heaps); MODULE_DESCRIPTION("DMA-BUF CMA Heap"); --=20 2.50.1