Hi Nicolas and Krzysztof, On 09/02/2025 11:56, Krzysztof Kozlowski wrote: > 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/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@xxxxxxxxxxxx/#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. Indeed, the protected heap name refers to a Linux concept: the DMA heap name. I understand the confusion introduced by this patch. I added a SW concept in the DTB, where it is meant to describe the HW. Following a discussion with Boris, we agreed to remove the DTB entry, and instead rely on an alternative way to get the name of the heap in the Panthor kernel driver. I will prepare a v2 of the RFC which will rely on a module parameter. Regards, Florent
