From: Maxime Ripard <mripard@kernel.org>
To: Jared Kangas <jkangas@redhat.com>
Cc: sumit.semwal@linaro.org, benjamin.gaignard@collabora.com,
Brian.Starkey@arm.com, jstultz@google.com, tjmercier@google.com,
christian.koenig@amd.com, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] dma-buf: heaps: Give default CMA heap a fixed name
Date: Thu, 24 Apr 2025 10:33:58 +0200 [thread overview]
Message-ID: <20250424-sassy-cunning-pillbug-ffde51@houat> (raw)
In-Reply-To: <20250422191939.555963-3-jkangas@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4628 bytes --]
Hi Jared,
Thanks for working on this
On Tue, Apr 22, 2025 at 12:19:39PM -0700, Jared Kangas wrote:
> The CMA heap's name in devtmpfs can vary depending on how the heap is
> defined. Its name defaults to "reserved", but if a CMA area is defined
> in the devicetree, the heap takes on the devicetree node's name, such as
> "default-pool" or "linux,cma". To simplify naming, just name it
> "default_cma", and keep a legacy node in place backed by the same
> underlying structure for backwards compatibility.
>
> Signed-off-by: Jared Kangas <jkangas@redhat.com>
> ---
> Documentation/userspace-api/dma-buf-heaps.rst | 11 +++++++----
> drivers/dma-buf/heaps/Kconfig | 10 ++++++++++
> drivers/dma-buf/heaps/cma_heap.c | 14 +++++++++++++-
> 3 files changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst
> index 535f49047ce64..577de813ba461 100644
> --- a/Documentation/userspace-api/dma-buf-heaps.rst
> +++ b/Documentation/userspace-api/dma-buf-heaps.rst
> @@ -19,7 +19,10 @@ following heaps:
> - 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. Depending on the platform, it
> - might be called ``reserved``, ``linux,cma``, or ``default-pool``.
> + ``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``. 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``.
It looks like, in addition to documenting the new naming, you also
changed all the backticks to double backticks. Why did you do so? It
seems mostly unrelated to that patch, so it would be better in a
separate patch.
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index a5eef06c42264..83f3770fa820a 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -12,3 +12,13 @@ config DMABUF_HEAPS_CMA
> 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 "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_heap.c
> index e998d8ccd1dc6..cd742c961190d 100644
> --- a/drivers/dma-buf/heaps/cma_heap.c
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -22,6 +22,7 @@
> #include <linux/slab.h>
> #include <linux/vmalloc.h>
>
> +#define DEFAULT_CMA_NAME "default_cma"
I appreciate this is kind of bikeshed-color territory, but I think "cma"
would be a better option here. There's nothing "default" about it.
> struct cma_heap {
> struct dma_heap *heap;
> @@ -394,15 +395,26 @@ static int __init __add_cma_heap(struct cma *cma, const char *name)
> static int __init add_default_cma_heap(void)
> {
> struct cma *default_cma = dev_get_cma_area(NULL);
> + const char *legacy_cma_name;
> int ret;
>
> if (!default_cma)
> return 0;
>
> - ret = __add_cma_heap(default_cma, cma_get_name(default_cma));
> + ret = __add_cma_heap(default_cma, DEFAULT_CMA_NAME);
> if (ret)
> return ret;
>
> + legacy_cma_name = cma_get_name(default_cma);
> +
> + if (IS_ENABLED(CONFIG_DMABUF_HEAPS_CMA_LEGACY) &&
> + strcmp(legacy_cma_name, DEFAULT_CMA_NAME)) {
> + ret = __add_cma_heap(default_cma, legacy_cma_name);
> + if (ret)
> + pr_warn("cma_heap: failed to add legacy heap: %pe\n",
> + ERR_PTR(-ret));
> + }
> +
It would also simplify this part, since you would always create the legacy heap.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2025-04-24 8:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-22 19:19 [PATCH v2 0/2] dma-buf: heaps: Use constant name for CMA heap Jared Kangas
2025-04-22 19:19 ` [PATCH v2 1/2] dma-buf: heaps: Parameterize heap name in __add_cma_heap() Jared Kangas
2025-04-22 22:22 ` John Stultz
2025-04-22 19:19 ` [PATCH v2 2/2] dma-buf: heaps: Give default CMA heap a fixed name Jared Kangas
2025-04-22 22:36 ` John Stultz
2025-04-24 8:33 ` Maxime Ripard [this message]
2025-04-24 16:11 ` Jared Kangas
2025-05-21 15:29 ` Maxime Ripard
2025-04-25 0:13 ` John Stultz
2025-04-25 6:58 ` Maxime Ripard
2025-04-25 19:39 ` John Stultz
2025-04-28 14:51 ` Maxime Ripard
2025-04-29 16:25 ` John Stultz
2025-05-06 13:33 ` Maxime Ripard
2025-04-23 15:23 ` [PATCH v2 0/2] dma-buf: heaps: Use constant name for CMA heap Sumit Semwal
2025-04-23 15:57 ` Jared Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250424-sassy-cunning-pillbug-ffde51@houat \
--to=mripard@kernel.org \
--cc=Brian.Starkey@arm.com \
--cc=benjamin.gaignard@collabora.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jkangas@redhat.com \
--cc=jstultz@google.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=tjmercier@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®