dmaengine.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: "Florent Tomasin" <florent.tomasin@arm.com>,
	"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>,
	"Maxime Ripard" <mripard@kernel.org>,
	"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>
Cc: 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 3/5] dt-bindings: gpu: Add protected heap name to Mali Valhall CSF binding
Date: Wed, 5 Feb 2025 10:13:52 +0100	[thread overview]
Message-ID: <c0aad911-ecc4-4b04-a453-6da226f76ed2@kernel.org> (raw)
In-Reply-To: <4b9deab1-e330-4c93-8260-75276c2bc9ff@arm.com>

On 03/02/2025 16:31, Florent Tomasin wrote:
> Hi Krzysztof
> 
> On 30/01/2025 13:25, Krzysztof Kozlowski wrote:
>> On 30/01/2025 14:08, Florent Tomasin wrote:
>>> Allow mali-valhall-csf driver to retrieve a protected
>>> heap at probe time by passing the name of the heap
>>> as attribute to the device tree GPU node.
>>
>> Please wrap commit message according to Linux coding style / submission
>> process (neither too early nor over the limit):
>> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
> Apologies, I think I made quite few other mistakes in the style of the
> patches I sent. I will work on improving this aspect, appreciated
> 
>> Why this cannot be passed by phandle, just like all reserved regions?
>>
>> From where do you take these protected heaps? Firmware? This would
>> explain why no relation is here (no probe ordering, no device links,
>> nothing connecting separate devices).
> 
> The protected heap is generaly obtained from a firmware (TEE) and could
> sometimes be a carved-out memory with restricted access.

Which is a reserved memory, isn't it?

> 
> The Panthor CSF kernel driver does not own or manage the protected heap
> and is instead a consumer of it (assuming the heap is made available by
> the system integrator).
> 
> I initially used a phandle, but then I realised it would introduce a new
> API to share the heap across kernel driver. In addition I found this
> patch series:
> -
> https://lore.kernel.org/lkml/20230911023038.30649-1-yong.wu@mediatek.com/#t
> 
> which introduces a DMA Heap API to the rest of the kernel to find a
> heap by name:
> - dma_heap_find()
> 
> I then decided to follow that approach to help isolate the heap
> management from the GPU driver code. In the Panthor driver, if the
> heap is not found at probe time, the driver will defer the probe until
> the exporter made it available.


I don't talk here really about the driver but even above mediatek
patchset uses reserved memory bindings.

You explained some things about driver yet you did not answer the
question. This looks like reserved memory. If it does not, bring
arguments why this binding cannot be a reserved memory, why hardware is
not a carve out memory.

Best regards,
Krzysztof

  reply	other threads:[~2025-02-05  9:14 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
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 [this message]
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=c0aad911-ecc4-4b04-a453-6da226f76ed2@kernel.org \
    --to=krzk@kernel.org \
    --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).