Thanks a lot Andy / Guennadi for your answers.
I wonder why SOF rmalloc & friends always force the allocations to be aligned with PLATFORM_DCACHE_ALIGN.
On Tue, Aug 23, 2022 at 5:53 PM Andy Ross andyross@google.com wrote:
It depends on what SOF is going to do with that memory, obviously. :)
The two big limitations in the past have been cache and hardware. The Xtensa architectural cache line size is 64 bytes, not 32, so that's probably not what's tripping you up (though it might be: you'd be 50/50 to get a working pointer!). IIRC the SOF heap actually returns uncached memory these days by default anyway? You need to use the uncached_to_cached() API (or the Zephyr equivalent that it's wrapping) to end up polluting the cache. There were multiple bugs fixed in this space last year.
Actually the cache line size depends on processor configuration. On i.MX8 is 128.
The other issue on Intel was that one of the DMA controllers (I think it was the Synopsys one, but it might have been HDA) had an (undocumented?) alignment requirement of (I think?) 32 bytes. I'm fuzzier on the details here, but this seems more likely to be the kind of thing you're looking at. The resolution there was to align the requirement at the driver level, I think? So if you're using different drivers you might need to do the same thing. Guennadi or +Kai would be likely to know more about this.
Thanks this is a good point. Will look into it.