LNL: all LLEXT-capable modules as "m"

[lyakh]

switch smart-amp-sample, eq-iir and mixin-mixout to LLEXT modules on Lunarlake by default

[tmleman]

I have no comments on the changes in the PR. I wasn't at the meeting where we decided to enable this feature on all platforms and I have no opinion. But I will take this opportunity to ask questions about LLEXT:

1. Why do overlay files such as module_overlay.conf even exist if this is enabled in platform configs?
2. What is the purpose of this file llext_relocatable.conf existence? From what I see, it adds a side config without which MTL and LNL won't even build. Shouldn't this config then be among the platform configs? And why is it also added for PTL, where it is not needed?

[kv2019i]

@tmleman wrote:

1. Why do overlay files such as [module_overlay.conf](https://github.com/thesofproject/sof/blob/main/app/overlays/mtl/module_overlay.conf) even exist if this is enabled in platform configs?

I think this will go away as it was a way to introduce modules as an optional build option, but if we move default configs to use modules, then this is no longer needed.

2. What is the purpose of this file [llext_relocatable.conf](https://github.com/thesofproject/sof/blob/main/app/llext_relocatable.conf) existence? From what I see, it adds a side config without which MTL and LNL won't even build. Shouldn't this config then be among the platform configs? And why is it also added for PTL, where it is not needed?

This is needed to handle toolchain differences, see #9151

[lgirdwood]

@lyakh CI results look fine for Jenkins
@wszypelt @lrudyX not sure if this feature is tested on Internal CI yet ?

[abonislawski]

(Regardless of loadable modules method) I see no reason in switching such frequently used module if we will load it always anyway.
I checked "reference firmware" and they are not using loadable option for typical modules, only for rarely used or external modules so I think we could optimize our settings similarly

[lgirdwood]

@abonislawski Today we are quite monolithic once FW and library has been loaded into SRAM, this works today, but is not fully optimal if we want to be more aggressive for PnP and offload more to DSP. Long term we need to optimize our hot code more to run on SRAM and cold code on IMR/DRAM, being able to unload (delete from SRAM and keep in IMR/DRAM) is needed if we want to maximize offload capability with limited SRAM. i.e. we can unload to swap media decoder modules (or other modules), power off SRAM banks when not used, change processing coefficients (e.g. switching SRC rates), unload init code (only used once), etc.

[marc-hb]

@llyakh can please look at the Zephyr SDK + zero Kconfig warnings inconsistencies I just reported in #9151 (review) ?

cc:

• General lack of .config control exposed by fuzzer .config divergence #9386

[lyakh]

So far LNL is not switching all modules to LLEXT by default