[Sound-open-firmware] Zephyr memory allocation from heap

[Daniel Baluta]

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 at 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.