devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Dufresne <nicolas@ndufresne.ca>
To: Florent Tomasin <florent.tomasin@arm.com>,
	Maxime Ripard <mripard@kernel.org>
Cc: "Vinod Koul" <vkoul@kernel.org>, "Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Boris Brezillon" <boris.brezillon@collabora.com>,
	"Steven Price" <steven.price@arm.com>,
	"Liviu Dudau" <liviu.dudau@arm.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
	"Brian Starkey" <Brian.Starkey@arm.com>,
	"John Stultz" <jstultz@google.com>,
	"T . J . Mercier" <tjmercier@google.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"AngeloGioacchino Del Regno"
	<angelogioacchino.delregno@collabora.com>,
	"Yong Wu" <yong.wu@mediatek.com>,
	dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, nd@arm.com,
	"Akash Goel" <akash.goel@arm.com>
Subject: Re: [RFC PATCH 1/5] dt-bindings: dma: Add CMA Heap bindings
Date: Tue, 04 Feb 2025 13:12:44 -0500	[thread overview]
Message-ID: <b02711c901e8acf2bc47926919de7673a0cb0b98.camel@ndufresne.ca> (raw)
In-Reply-To: <be8e6b9f-c3c6-41d1-af9c-3dcd102f0fe3@arm.com>

Hi Florent,

Le lundi 03 février 2025 à 13:36 +0000, Florent Tomasin a écrit :
> 
> On 30/01/2025 13:28, Maxime Ripard wrote:
> > Hi,
> > 
> > On Thu, Jan 30, 2025 at 01:08:57PM +0000, Florent Tomasin wrote:
> > > Introduce a CMA Heap dt-binding allowing custom
> > > CMA heap registrations.
> > > 
> > > * Note to the reviewers:
> > > The patch was used for the development of the protected mode

Just to avoid divergence in nomenclature, and because this is not a new subject,
perhaps you should also adhere to the name "restricted". Both Linaro and
Mediatek have moved from "secure" to that name in their proposal. As you are the
third proposing this (at least for the proposal that are CCed on linux-media), I
would have expected in your cover letter a summary of how the other requirement
have been blended in your proposal.

regards,
Nicolas

> > > feature in Panthor CSF kernel driver and is not initially thought
> > > to land in the Linux kernel. It is mostly relevant if someone
> > > wants to reproduce the environment of testing. Please, raise
> > > interest if you think the patch has value in the Linux kernel.
> > > 
> > > Signed-off-by: Florent Tomasin <florent.tomasin@arm.com>
> > > ---
> > >  .../devicetree/bindings/dma/linux,cma.yml     | 43 +++++++++++++++++++
> > >  1 file changed, 43 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/dma/linux,cma.yml
> > > 
> > > diff --git a/Documentation/devicetree/bindings/dma/linux,cma.yml b/Documentation/devicetree/bindings/dma/linux,cma.yml
> > > new file mode 100644
> > > index 000000000000..c532e016bbe5
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/dma/linux,cma.yml
> > > @@ -0,0 +1,43 @@
> > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/dma/linux-cma.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Custom Linux CMA heap
> > > +
> > > +description:
> > > +  The custom Linux CMA heap device tree node allows registering
> > > +  of multiple CMA heaps.
> > > +
> > > +  The CMA heap name will match the node name of the "memory-region".
> > > +
> > > +properties:
> > > +  compatible:
> > > +    enum:
> > > +      - linux,cma
> > > +
> > > +  memory-region:
> > > +    maxItems: 1
> > > +    description: |
> > > +      Phandle to the reserved memory node associated with the CMA Heap.
> > > +      The reserved memory node must follow this binding convention:
> > > +       - Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> > > +
> > > +examples:
> > > +  - |
> > > +    reserved-memory {
> > > +      #address-cells = <2>;
> > > +      #size-cells = <2>;
> > > +
> > > +      custom_cma_heap: custom-cma-heap {
> > > +        compatible = "shared-dma-pool";
> > > +        reg = <0x0 0x90600000 0x0 0x1000000>;
> > > +        reusable;
> > > +      };
> > > +    };
> > > +
> > > +    device_cma_heap: device-cma-heap {
> > > +      compatible = "linux,cma";
> > > +      memory-region = <&custom_cma_heap>;
> > > +    };
> > 
> > Isn't it redundant with the linux,cma-default shared-dma-pool property
> > already?
> > 
> > Maxime
> 
> Hi Maxime,
> 
> Please correct me if my understanding is wrong,
> 
> The existing properties: linux,cma-default and shared-dma-pool, do not
> allow the creations of multiple standalone CMA heaps, those will create
> a single CMA heap: `dma_contiguous_default_area`? Other CMA heaps will
> be bound to a driver.
> 
> I introduced the "linux,cma" to allow creating multiple standalone CMA
> heaps, with the intention of validating the protected mode support on
> Mali CSG GPUs. It was included in the RFC in there are interests in
> this approach.
> 
> Since the Panthor CSF kernel driver does not own or manage a heap,
> I needed a way to create a standalone heap. The idea here is for the
> kernel driver to be an importer. I relied on a patch series to retrieve
> the heap and allocate a DMA buffer from it:
> - dma_heap_find()
> - dma_heap_buffer_alloc()
> - dma_heap_put()
> 
> Ref:
> https://lore.kernel.org/lkml/20230911023038.30649-1-yong.wu@mediatek.com/#t
> 
> 
> Since the protected/secure memory management is integration specific,
> I needed a generic way for Panthor to allocate from such heap.
> 
> In some scenarios it might be a carved-out memory, in others a FW will
> reside in the system (TEE) and require a secure heap driver to allocate
> memory (e.g: a similar approach is followd by MTK). Such driver would
> implement the allocation and free logic.
> 
> Florent
> 
> 
> 


  reply	other threads:[~2025-02-04 18:12 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-30 13:08 [RFC PATCH 0/5] drm/panthor: Protected mode support for Mali CSF GPUs Florent Tomasin
2025-01-30 13:08 ` [RFC PATCH 1/5] dt-bindings: dma: Add CMA Heap bindings Florent Tomasin
2025-01-30 13:28   ` Maxime Ripard
2025-02-03 13:36     ` Florent Tomasin
2025-02-04 18:12       ` Nicolas Dufresne [this message]
2025-02-12  9:49         ` Florent Tomasin
2025-02-12 10:01           ` Maxime Ripard
2025-02-12 10:29             ` Florent Tomasin
2025-02-12 10:49               ` Maxime Ripard
2025-02-12 11:02                 ` Florent Tomasin
2025-02-12 10:37             ` Boris Brezillon
2025-01-30 23:20   ` Rob Herring
2025-02-03 16:18     ` Florent Tomasin
2025-01-30 13:08 ` [RFC PATCH 2/5] cma-heap: Allow registration of custom cma heaps Florent Tomasin
2025-01-30 13:34   ` Maxime Ripard
2025-02-03 13:52     ` Florent Tomasin
2025-01-30 13:08 ` [RFC PATCH 3/5] dt-bindings: gpu: Add protected heap name to Mali Valhall CSF binding Florent Tomasin
2025-01-30 13:25   ` Krzysztof Kozlowski
2025-02-03 15:31     ` Florent Tomasin
2025-02-05  9:13       ` Krzysztof Kozlowski
2025-02-06 21:21         ` Nicolas Dufresne
2025-02-09 11:56           ` Krzysztof Kozlowski
2025-02-12  9:25             ` Florent Tomasin
2025-01-30 13:09 ` [RFC PATCH 4/5] drm/panthor: Add support for protected memory allocation in panthor Florent Tomasin
2025-02-11 11:04   ` Boris Brezillon
2025-02-11 11:20     ` Boris Brezillon
2025-03-12 20:05   ` Adrian Larumbe
2025-01-30 13:09 ` [RFC PATCH 5/5] drm/panthor: Add support for entering and exiting protected mode Florent Tomasin
2025-02-10 14:01   ` Boris Brezillon
2025-01-30 13:46 ` [RFC PATCH 0/5] drm/panthor: Protected mode support for Mali CSF GPUs Maxime Ripard
2025-01-30 15:59   ` Nicolas Dufresne
2025-01-30 16:38     ` Maxime Ripard
2025-01-30 17:47       ` Nicolas Dufresne
2025-02-03 16:43         ` Florent Tomasin
2025-02-04 18:22           ` Nicolas Dufresne
2025-02-05 14:53             ` Maxime Ripard
2025-02-05 18:07               ` Nicolas Dufresne
2025-02-05 14:52           ` Maxime Ripard
2025-02-05 18:14             ` Nicolas Dufresne
2025-02-07 15:02               ` Boris Brezillon
2025-02-07 16:32                 ` Nicolas Dufresne
2025-02-07 16:42                   ` Boris Brezillon
2025-02-11 13:46                 ` Maxime Ripard
2025-02-11 14:32                   ` Boris Brezillon
2025-02-20 13:32                     ` Maxime Ripard
2025-02-24 11:36                       ` Boris Brezillon
2025-01-30 16:15 ` Simona Vetter
2025-02-03  9:25   ` Boris Brezillon

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=b02711c901e8acf2bc47926919de7673a0cb0b98.camel@ndufresne.ca \
    --to=nicolas@ndufresne.ca \
    --cc=Brian.Starkey@arm.com \
    --cc=airlied@gmail.com \
    --cc=akash.goel@arm.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=benjamin.gaignard@collabora.com \
    --cc=boris.brezillon@collabora.com \
    --cc=christian.koenig@amd.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=florent.tomasin@arm.com \
    --cc=jstultz@google.com \
    --cc=krzk+dt@kernel.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=liviu.dudau@arm.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthias.bgg@gmail.com \
    --cc=mripard@kernel.org \
    --cc=nd@arm.com \
    --cc=robh@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=steven.price@arm.com \
    --cc=sumit.semwal@linaro.org \
    --cc=tjmercier@google.com \
    --cc=tzimmermann@suse.de \
    --cc=vkoul@kernel.org \
    --cc=yong.wu@mediatek.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;
as well as URLs for NNTP newsgroup(s).