Re: [RFC PATCH 3/5] dt-bindings: gpu: Add protected heap name to Mali Valhall CSF binding
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/submi...
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
Le mercredi 05 février 2025 à 10:13 +0100, Krzysztof Kozlowski a écrit :
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/submi...
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.
I think the point is that from the Mali GPU view, the memory does not need to be within the range the Linux Kernel actually see, even though current integration have that. From Mali GPU driver stand point (or codec drivers and what's not), the memory range is not useful to allocate protected/restricted memory. On top of which, its not reserved specifically for the Mali GPU.
What's your practical suggestion here ? Introduce dma_heap_find_by_region() ?
Nicolas
Best regards, Krzysztof
On 06/02/2025 22:21, Nicolas Dufresne wrote:
Le mercredi 05 février 2025 à 10:13 +0100, Krzysztof Kozlowski a écrit :
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/submi...
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.
I think the point is that from the Mali GPU view, the memory does not need to be within the range the Linux Kernel actually see, even though current integration
Do I get it right: Memory can be outside of kernel address range but you put it to the bindings as reserved memory? If yes, then I still do not understand why DT should keep that information. Basically, you can choose whatever memory is there, because it anyway won't interfere with Linux, right? Linux does not have any reasonable way to access it.
It might interfere with firmware or other processors, but then it's the job of firmware which has discoverable interfaces for this.
The binding says it is about protected heap name, but it explains nothing what is that protected heap. You pass it to some firmware as string? Does not look like, rather looks like Linux thingy, but this again is neither explained in commit msg nor actually correct: Linux thingies do not belong to DT.
have that. From Mali GPU driver stand point (or codec drivers and what's not), the memory range is not useful to allocate protected/restricted memory. On top of which, its not reserved specifically for the Mali GPU.
What's your practical suggestion here ? Introduce dma_heap_find_by_region() ?
I did not comment about driver and I do not judge how you access whatever you need to access. This is discussion purely about binding thus about hardware.
Best regards, Krzysztof
linaro-mm-sig@lists.linaro.org
-
Krzysztof Kozlowski -
Nicolas Dufresne