topology: sof-apl-nocodec: revert to static pipelines

[ranj063]

Dynamic pipelines will fail with the sof-apl-nocodec topology
due to issues with the memory allocator. Revert back to
use static pipelines until we have a more flexible memory
allocatory available with Zephyr.

Fixes #4305

[plbossart]

Revert back to
use static pipelines until we have a more flexible memory
allocatory available with Zephyr.

Not following @ranj063. Is there a plan to use Zephyr on APL in new releases, or are you saying that the optional support of Zephyr will also result in changes to the memory allocation.

[ranj063]

Not following @ranj063. Is there a plan to use Zephyr on APL in new releases, or are you saying that the optional support of Zephyr will also result in changes to the memory allocation

yes "optional support of Zephyr will also result in changes to the memory allocation". @lgirdwood please correct me if im wrong

[lgirdwood]

Not following @ranj063. Is there a plan to use Zephyr on APL in new releases, or are you saying that the optional support of Zephyr will also result in changes to the memory allocation

yes "optional support of Zephyr will also result in changes to the memory allocation". @lgirdwood please correct me if im wrong

The Zephyr allocator can utilize more of the memory hence we dont need the static block mappings and are more free to allocate with less wastage.

[plbossart]

Not following @ranj063. Is there a plan to use Zephyr on APL in new releases, or are you saying that the optional support of Zephyr will also result in changes to the memory allocation

yes "optional support of Zephyr will also result in changes to the memory allocation". @lgirdwood please correct me if im wrong

The Zephyr allocator can utilize more of the memory hence we dont need the static block mappings and are more free to allocate with less wastage.

what will happen if we don't compile on top of Zephyr then? Same results as today?
If yes, then we will be forced to use static pipelines or forced to transition to Zephyr to enable dynamic pipelines?

[ranj063]

what will happen if we don't compile on top of Zephyr then? Same results as today?
If yes, then we will be forced to use static pipelines or forced to transition to Zephyr to enable dynamic pipelines?

yes one of the above @plbossart depending on when we roll out zephyr for APL

[ranj063]

what will happen if we don't compile on top of Zephyr then? Same results as today?
If yes, then we will be forced to use static pipelines or forced to transition to Zephyr to enable dynamic pipelines?

yes one of the above @plbossart depending on when we roll out zephyr for APL

and oh im also a bit skeptical about saying zephyr will fix the problem until I see it for myself.

[lgirdwood]

what will happen if we don't compile on top of Zephyr then? Same results as today?
If yes, then we will be forced to use static pipelines or forced to transition to Zephyr to enable dynamic pipelines?

There is nothing stopping dynamic pipelines on platforms with more memory. APL only has 512kB, this is just a limitation of the SOF allocator with this limited heap size.

yes one of the above @plbossart depending on when we roll out zephyr for APL

Yes - xtos will be deprecated and removed. APL already works very well using Zephyr as the RTOS.

and oh im also a bit skeptical about saying zephyr will fix the problem until I see it for myself.

Turn the heap dump trace on and you will see allocator wastage due to some static block being unused (that cant be used for other allocations).

[ranj063]

Turn the heap dump trace on and you will see allocator wastage due to some static block being unused (that cant be used for other allocations).

@lgirdwood maybe the wastage fix in zephyr will help with the issue but Im not convinced it is entirely the reason for the failure. When we dont qualify the buffer allocation with expliciti HP/LP flag, it gets allocated wherever possible leaving the onesthat do have an explicit request fail at the end.

[keyonjie]

Considering the XTOS will be still a choice for part of platforms for a quite long ( > 2 years?) period, I would suggest to fix this kind of allocator issues, instead of fully relying on Zephyr.

I believe 512KB on APL is still big enough for our nocodec scenario, the fix itself should not be complicate, just go through the usage of all memory pools (system, system runtime, runtime, buffer) on all cAVS platforms, fine tune the size of each pool to make them more reasonable, that is, enough and no wastage for all our existed topology cases.

I can try to do this kind of refining when I have time, but for the moment, I am fine to revert to static pipeline for APL nocodec to make the CI happy.

[lgirdwood]

@keyonjie once we switch over to Zephyr, all CAVS platforms will switch over - there is no point doing some with xtos and some with Zephyr.