From nobody Tue Oct 7 13:10:18 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 8F4802DC32D; Wed, 9 Jul 2025 12:45:07 +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=1752065107; cv=none; b=T36fQU4abiHgg+7uxdqwOsUihIKGYZjzdft+fT1bEGPU1aSAa52DEvKq58T9Ffm33W6eSvBBWReyuxkKQ+/jlK6DEKv6LrUvyA4u2bkingKt7SZX3C2qZOXG6iLgAU+ND+9bQXo1nMAgIl108z9sBuR89mWKxRePXG9oxuSuGs0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752065107; c=relaxed/simple; bh=j+rGaVFrKh/wTsIEN6Y/GVKJC3e6Fd+LYTBCSBZnuHw=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=VpihggiKU/4HfBdKee6kNpt3mSo5L4meLRulxsyCqYwnI7HWs0oMjAf2CryUpxdkFZ2HBXJxn8SUTYLLGyCKOIL9MQPIDv3FD5RubDrTCXTGluNnKhP5nMh9u+tJSaK1K6XoiTbxYT9Ujc+hp2OJEgnIQsQRyNv7Fo6j/36za8Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sL1zhxns; 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="sL1zhxns" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A4D9AC4CEF5; Wed, 9 Jul 2025 12:45:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752065107; bh=j+rGaVFrKh/wTsIEN6Y/GVKJC3e6Fd+LYTBCSBZnuHw=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=sL1zhxnslztVR22EPFjnTP6BdUV5LwKMHzA3KxXOgOvl/b6YkoPfXPm8aysatlzru NrY5V62cE/KFyEZBYQnKluajc/VbrV6xEfVN50Rr+THqg0a1rk+P3M+yiEMnrLJnXt egMjis+tIKukv4U4z/7sDF9mQUteQGv2JvkLC66LiP8ggXOMMy3pY8vbkItOviitPC Ge4SbRIx0xV886Gqcl7Dr0DshooNtOPMQij6rs1pWCWQkLISbJ9SDWpL23XRXsJufg ie0FdGcuWkV6/JoCrlU1bo6BLlaG2KHTBSmEj2KaDLzCPV3y+Z3SxB0OcTEMqjrPnn KQ8Gc/GBZgatQ== From: Maxime Ripard Date: Wed, 09 Jul 2025 14:44:51 +0200 Subject: [PATCH v6 1/2] dma/contiguous: Add helper to test reserved memory type 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: <20250709-dma-buf-ecc-heap-v6-1-dac9bf80f35d@kernel.org> References: <20250709-dma-buf-ecc-heap-v6-0-dac9bf80f35d@kernel.org> In-Reply-To: <20250709-dma-buf-ecc-heap-v6-0-dac9bf80f35d@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 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, Maxime Ripard X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=2383; i=mripard@kernel.org; h=from:subject:message-id; bh=j+rGaVFrKh/wTsIEN6Y/GVKJC3e6Fd+LYTBCSBZnuHw=; b=owGbwMvMwCmsHn9OcpHtvjLG02pJDBl5KT4HohnkJMt+6Nb9K714wOrC4+ebL4qcKzJMCZN74 LfVMXVCx1QWBmFOBlkxRZYnMmGnl7cvrnKwX/kDZg4rE8gQBi5OAZiI1zTGhgNi7EItlyQL2mL0 7Lf8smE4lOX7Zur/3KVHN06+vqJ8Qez8gnvzXlqo1a9apzT/1Ju4uYz1wUmqAZsvSvFpcXVNVL+ 3wov5hs/EfbmNuwVuVjJ9+q4575hJFs+NYz9Wls1wcjwdknIQAA== X-Developer-Key: i=mripard@kernel.org; a=openpgp; fpr=BE5675C37E818C8B5764241C254BCFC56BF6CE8D A given reserved-memory region can be of multiple types. We have currently four types defined in the tree: contiguous, backed by CMA, coherent and swiotlb, backed by their respective allocators, and a platform-specific one for tegra. However, some users, like dma-buf heaps, might be interested in the exact type of a reserved memory region they are getting. It would thus be useful to have helpers to test if a given region is of a given type. Since we only care about CMA for now though, let's create one for CMA only. Signed-off-by: Maxime Ripard --- include/linux/dma-map-ops.h | 13 +++++++++++++ kernel/dma/contiguous.c | 7 +++++++ 2 files changed, 20 insertions(+) diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h index f48e5fb88bd5dd346094bbf2ce1b79e5f5bfe1a6..ea646acb6367bd062619b337013= db221749f85ab 100644 --- a/include/linux/dma-map-ops.h +++ b/include/linux/dma-map-ops.h @@ -153,10 +153,23 @@ static inline void dma_free_contiguous(struct device = *dev, struct page *page, { __free_pages(page, get_order(size)); } #endif /* CONFIG_DMA_CMA*/ =20 +#if defined(CONFIG_DMA_CMA) && defined(CONFIG_OF_RESERVED_MEM) +struct reserved_mem; + +bool of_reserved_mem_is_contiguous(const struct reserved_mem *rmem); +#else +struct reserved_mem; + +static inline bool of_reserved_mem_is_contiguous(const struct reserved_mem= *rmem) +{ + return false; +} +#endif + #ifdef CONFIG_DMA_DECLARE_COHERENT int dma_declare_coherent_memory(struct device *dev, phys_addr_t phys_addr, dma_addr_t device_addr, size_t size); void dma_release_coherent_memory(struct device *dev); int dma_alloc_from_dev_coherent(struct device *dev, ssize_t size, diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c index 8df0dfaaca18eeb0a20145512ba64425d2e7601e..ace4982e928e404315cf38551e1= 596f7ed445156 100644 --- a/kernel/dma/contiguous.c +++ b/kernel/dma/contiguous.c @@ -493,6 +493,13 @@ static int __init rmem_cma_setup(struct reserved_mem *= rmem) &rmem->base, (unsigned long)rmem->size / SZ_1M); =20 return 0; } RESERVEDMEM_OF_DECLARE(cma, "shared-dma-pool", rmem_cma_setup); + +bool of_reserved_mem_is_contiguous(const struct reserved_mem *rmem) +{ + return rmem->ops =3D=3D &rmem_cma_ops; +} +EXPORT_SYMBOL_GPL(of_reserved_mem_is_contiguous); + #endif --=20 2.50.0 From nobody Tue Oct 7 13:10:18 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 68F912E03FE; Wed, 9 Jul 2025 12:45:10 +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=1752065110; cv=none; b=rLrSiSERM0q6cYro6b1PT2M/5u2a5M5bxiqMm6395iK8AJGstnUQEIn6g7sgCj55DFHMEjp3XCz2Cnm/5AHl8XHCdt56Ih5JeFa0x4P4abjEjYdnY3mSVUvxOy82L6BjEe5A9nYJ51AwUqZBUoD33hUjETs5GecIRSXq3pNy/7o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752065110; c=relaxed/simple; bh=eJM6k+wK6WHbWepDDkp+m8Pi3rWX7uz+aZzRQGLbdr0=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=F8quMMM7729+KVfpu8kDXXOhNna/dkj46HguXQThh9d4eUfe4nU9viZ+kEqTD9gakn4z9FQZpnyQpxTlthgiBN6WHoq0YGPFZs4EyNc7fjb8sVXmMgpFh3afyxnuqKfvcejd0k7iczkErm6UxICSfTltrkSUeRKS0amvZ5xTK3w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=t7lqxg3v; 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="t7lqxg3v" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F0BBC4CEF4; Wed, 9 Jul 2025 12:45:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752065110; bh=eJM6k+wK6WHbWepDDkp+m8Pi3rWX7uz+aZzRQGLbdr0=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=t7lqxg3v75ueilutziXZ8q3HmM8ibFJjZ8kMTAKtLoqvfMQ5upnVSdynjlTROiT99 pkCUyFLOQa7ZC8bS1P5TcgrnFST6yIy32hz2W3A+EGw2FBwuzpB/PgIiFtDo2J9uin WXuIgVV7fY63PsK1+aDioMdyWHGAuVYiC4El7gUQu3Jn246rzTB2fgLUlFKeWdzJxT Hx3bB6UM34Z4hjPw+xyLmFVNbjwjD9KYpR4c35MTXcfNnDTwglbm+Hl4I107JH2JOI hDTTYCxEkr+ya7CozRR+unhFeDRva2CV/OMYkZaIMc4upU10450ZGB7YM2XESV+sQS QRZE0elBx+XYA== From: Maxime Ripard Date: Wed, 09 Jul 2025 14:44:52 +0200 Subject: [PATCH v6 2/2] 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: <20250709-dma-buf-ecc-heap-v6-2-dac9bf80f35d@kernel.org> References: <20250709-dma-buf-ecc-heap-v6-0-dac9bf80f35d@kernel.org> In-Reply-To: <20250709-dma-buf-ecc-heap-v6-0-dac9bf80f35d@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 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, Maxime Ripard X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=2674; i=mripard@kernel.org; h=from:subject:message-id; bh=eJM6k+wK6WHbWepDDkp+m8Pi3rWX7uz+aZzRQGLbdr0=; b=owGbwMvMwCmsHn9OcpHtvjLG02pJDBl5Kb4af/N4FRS+60947CdqJvGl78DS8IxFGZOsD3eUb /FdVyXWMZWFQZiTQVZMkeWJTNjp5e2LqxzsV/6AmcPKBDKEgYtTACZSVMtYZ/LxzQ27uTXcRt4t e3bofj0kpsaf/DNL6QV/Ayevu8BT3o3Ppyef/Wm1pX3ysetRD16ZM9aHCHxpLWaPC3j0Jz73oo/ oraatxzr1ch6r7VqU+q/+qMHmNS5di78+CX1ZtWtZ/YVpqnkA 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. Signed-off-by: Maxime Ripard --- drivers/dma-buf/heaps/cma_heap.c | 52 ++++++++++++++++++++++++++++++++++++= +++- 1 file changed, 51 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_h= eap.c index 0df007111975447d555714d61ead9699287fd65a..31a18683ee25788a800f3f878fd= 958718a930ff7 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -19,10 +19,12 @@ #include #include #include #include #include +#include +#include #include #include #include =20 #define DEFAULT_CMA_NAME "default_cma_region" @@ -421,7 +423,55 @@ static int __init add_default_cma_heap(void) ERR_PTR(ret)); } =20 return 0; } -module_init(add_default_cma_heap); + +static int __init add_cma_heaps(void) +{ + struct device_node *rmem_node; + struct device_node *node; + int ret; + + ret =3D add_default_cma_heap(); + if (ret) + return ret; + + rmem_node =3D of_find_node_by_path("/reserved-memory"); + if (!rmem_node) + goto out; + + for_each_child_of_node(rmem_node, node) { + struct reserved_mem *rmem; + struct cma *cma; + + rmem =3D of_reserved_mem_lookup(node); + if (!rmem) { + ret =3D -EINVAL; + goto err_put_node; + } + + if (!of_reserved_mem_is_contiguous(rmem)) + continue; + + cma =3D rmem->priv; + if (!cma) { + ret =3D -EINVAL; + goto err_put_node; + } + + ret =3D __add_cma_heap(cma, of_node_full_name(node)); + if (ret) + goto err_put_node; + } + +out: + of_node_put(rmem_node); + return 0; + +err_put_node: + of_node_put(rmem_node); + return ret; +} + +module_init(add_cma_heaps); MODULE_DESCRIPTION("DMA-BUF CMA Heap"); --=20 2.50.0