[Sound-open-firmware] Zephyr memory allocation from heap
Guennadi Liakhovetski
guennadi.liakhovetski at intel.com
Tue Aug 23 17:30:25 CEST 2022
Concerning allocations:
On Tue, 23 Aug 2022, Andy Ross 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?
I don't think this is the case any more. We're now allocating memory
according to the flags: only when _SHARED is used, then uncached memory
pointer is returned, otherwise a cached one.
Thanks
Guennadi
> 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.
>
> 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.
>
> Andy
>
> On Mon, Aug 22, 2022 at 9:44 AM Daniel Baluta <daniel.baluta at nxp.com> wrote:
>>
>> + andyross at google.com
>>
>>
>> Subject: Re: [Sound-open-firmware] Zephyr memory allocation from heap
>>
>> + Andy, as he also worked on the initial zephyr with SOF.
>>
>> On Mon, Aug 22, 2022 at 5:04 PM Daniel Baluta <daniel.baluta at gmail.com> wrote:
>>>
>>> Hi guys,
>>>
>>> Did you encountered any problems with memory allocations when
>>> switching to Zephyr?
>>>
>>> I'm facing a very strange issue with a playback pipeline with module
>>> adapter (MP3) where
>>> it looks like the DAI hits underruns as soon as I start the pipeline.
>>>
>>> With normal PCM playback everything works fine.
>>>
>>> I think it might be a problem in the sense Zephyr allocates memory
>>> and/or Cadence
>>> memory alignment requirements?
>>>
>>> Looks like as soon as I change this:
>>>
>>> -#define PLATFORM_DCACHE_ALIGN sizeof(void *)
>>> +#define PLATFORM_DCACHE_ALIGN 32
>>>
>>>
>>> everything seems to work.
>>>
>>> But I cannot find any logical explanation.
>>
>>
>
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
More information about the Sound-open-firmware
mailing list