On 12/02/2025 10:49, Maxime Ripard wrote: > On Wed, Feb 12, 2025 at 10:29:32AM +0000, Florent Tomasin wrote: >> >> >> On 12/02/2025 10:01, Maxime Ripard 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. >>> >>> 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? >> >> You are correct only the CMA allocator is relevant. I needed a way to >> sub-allocate from a carved-out memory. > > I'm still confused, sorry. You're saying that you require CMA but... Adding to Boris's comment, the objective here was to enable sub-allocation from a carved-out memory region. The CMA heap was used for convinience. It can be any other heap driver that allows allocating a protected buffer. >>> In the latter case, would something like this work: >>> https://lore.kernel.org/all/20240515-dma-buf-ecc-heap-v1-1-54cbbd049511@xxxxxxxxxx/ >> >> Thanks for sharing this link, I was not aware previous work was done >> on this aspect. The new carveout heap introduced in the series could >> probably be a good alternative. I will play-around with it and share >> some updates. > > ... you seem to be ok with a driver that doesn't use it? I will confirm it once I have done some validation.
