From nobody Fri Dec 19 15:16:29 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 277192F9D89; Mon, 13 Oct 2025 08:35:24 +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=1760344524; cv=none; b=GKTcSZBpzXr7zvQMewQZAouII5B1+fBbSFYJkrdld8i1d15xYTT+jws7ylTDuJYssDZG0wNigUR3Fhok/d0m78ObEtfzo1xn51OlUk6dCXJxYwvE2V4Voku2lB2JAxEyop5aT2nwP4qkCT2iTukRN+AlQMRV3ZmXpf1ehv38nMc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760344524; c=relaxed/simple; bh=LajQOzk5GurvfMLYf/AkXrRyTeYx/Rv5O6zLtZAh0eM=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=o0p7eDXgWrkBiSAr+K46ZyoxFfaLmHtgA3dyC7wDhDYESDTGyaBTyVyhwotRbqHqzjbGVvyJcr89lnSV3vCrOLZL/v4E1Fq99vN3hd2xgJk9m0xJWKJO6YINcy4EU4hFxXSCs0gEQtMeKjsWJkZsb1LQoZxmIyJb25WgkEA6gEc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PoKMEbD7; 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="PoKMEbD7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8B2A3C4CEFE; Mon, 13 Oct 2025 08:35:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1760344523; bh=LajQOzk5GurvfMLYf/AkXrRyTeYx/Rv5O6zLtZAh0eM=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=PoKMEbD7W7BvsFwuUR4NZOpmLGVqH3UTQkCAWknoduVynmpAKzMHMwUWeyKxWahzb x09EBSmy88L4bwEun0kHl+ctSTqkbW2jCEA+nusK/xSke2aerDalu063VBP0Ic7OKR O0ryxoWQ9gUHfI9uRrQ40KcRHD1KsXfQayvlXHpmPwiIQHfCD0KhzzgtMXs8Jr9YTn pS2xw3/MRz+Xvd2GQiCsOup591MTBB4UDDAMxh6WCFbVYnfK7Oik9PQRcZQOUFuO0R CJ/E+mK3zQ+jWuBLwJHtsyGESV8nYXJWUDhP7KZwX+97oP8XCHDTyJ+ithGbwrCU9k y1ffjnDqAhDRA== From: Maxime Ripard Date: Mon, 13 Oct 2025 10:35:16 +0200 Subject: [PATCH v8 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: <20251013-dma-buf-ecc-heap-v8-1-04ce150ea3d9@kernel.org> References: <20251013-dma-buf-ecc-heap-v8-0-04ce150ea3d9@kernel.org> In-Reply-To: <20251013-dma-buf-ecc-heap-v8-0-04ce150ea3d9@kernel.org> To: Sumit Semwal , Benjamin Gaignard , Brian Starkey , John Stultz , "T.J. Mercier" , Jonathan Corbet , =?utf-8?q?Christian_K=C3=B6nig?= , Marek Szyprowski , Robin Murphy Cc: Andrew Davis , Jared Kangas , Mattijs Korpershoek , linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, Maxime Ripard X-Mailer: b4 0.14.2 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. Reviewed-by: T.J. Mercier Signed-off-by: Maxime Ripard --- 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.51.0