| Message ID | 36b57dcf20860398ba83985e1c5b6f6958d08ba7.1738228114.git.florent.tomasin@arm.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC,1/5] dt-bindings: dma: Add CMA Heap bindings | expand |
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 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). Best regards, Krzysztof
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. 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. Best regards, Florent
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml index a5b4e0021758..dc633b037ede 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml @@ -85,6 +85,12 @@ properties: dma-coherent: true + protected-heap-name: + $ref: /schemas/types.yaml#/definitions/string + description: + Specifies the name of the protected Heap from + which the GPU driver allocates protected memory. + required: - compatible - reg
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. Signed-off-by: Florent Tomasin <florent.tomasin@arm.com> --- .../devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 6 ++++++ 1 file changed, 6 insertions(+)