On Wed, 12 Feb 2025 11:01:11 +0100 Maxime Ripard <mripard@xxxxxxxxxx> wrote: > On Wed, Feb 12, 2025 at 09:49:56AM +0000, Florent Tomasin wrote: > > Note that the CMA patches were initially shared to help reproduce my > > environment of development, I can isolate them in a separate patch > > series and include a reference or "base-commit:" tag to it in the > > Panthor protected mode RFC, to help progress this review in another > > thread. It will avoid overlapping these two topics: > > > > - Multiple standalone CMA heaps support > > - Panthor protected mode handling > > You keep insisting on using CMA here, but it's really not clear to me > why you would need CMA in the first place. CMA is certainly not the solution. As Florent said, it's just here to help people test the panthor protected-mode feature without having to pull Mediatek's protected heap implementation, which currently lives in some vendor tree and is thus quite painful to integrate to a vanilla kernel. I would suggest keeping those patches in a public tree we can point to, and dropping them from v2, to avoid the confusion. > > By CMA, do you mean the CMA allocator, and thus would provide buffers > through the usual dma_alloc_* API, or would any allocator providing > physically contiguous memory work? Panthor can work with the system heap too AFAICT (I've done my testing with the system heap, and it seems to work fine). It gets tricky when you want to allocate protected scanout buffers and import them in the KMS device though. But as said above, we shouldn't really bother exposing custom CMA heaps, because that's not what we want to use ultimately. What we'll want is some ATF implementation for protected memory, that we can rely on to implement a standard protected dma-heap implementation, I guess. > > In the latter case, would something like this work: > https://lore.kernel.org/all/20240515-dma-buf-ecc-heap-v1-1-54cbbd049511@xxxxxxxxxx/ > > Maxime
