can we depend on ARCH_XTENSA and make this a Kconfig choice (where each choice would depend on ARCH_XTENSA_HIFI_n set by top level PLATFORM Kconfig) ?

Btw, I think Peter Mitsis (@peter-mitsis) will have the HiFi flavour landing in Zephyr soon as part of the HiFi context save/restore work. i.e. we can reuse RTOS supplied Kconfig data.

Whatever methodology we use, it should also scale to x86 and ARM SIMD.

where is ARCH_XTENSA and ARCH_XTENSA_HIFI_n definition? is it already exist or added later?

also, there is no HIFI option for this module, no HIFI3 and HIFI4 option.

also, there is no HIFI option for this module, no HIFI3 and HIFI4 option.

In this prototype you enter '3' or '4' or any version you like. @lgirdwood already requested a Kconfig choice

Please spend more time reading and make sure you understand better before commenting.

Just to confirm, I am indeed working on adding HiFi DSP support in Zephyr so that its registers will be saved/restored on relevant context switches.

EDIT: now at:

• arch: xtensa: save/restore the HiFi (AudioEngine) registers zephyrproject-rtos/zephyr#67628

@peter-mitsis , do you mean you will adding HIFI related config into zephyr, then SOF can directly leverage it?

All - @peter-mitsis will need to define a SOC level Kconfig to indicate the HIFI level on xtensa. i.e. this will say hifi3, hifi4, hifi5 etc as the different hifi ISA add additional register that must be saved/restored.
This same Kconfig can be reused here to indicate the highest HIFI SIMD level for each platform/SOC i.e. some menuconfig options will depend on this Zephyr SOC Kconfig.

All - @peter-mitsis will need to define a SOC level Kconfig to indicate the HIFI level on xtensa.

My attempt to do this:

• Add new XTENSA_ARCH_HAS_HIFIn zephyrproject-rtos/zephyr#67513

Just prototype and draft but a functional one so please review.

Thank you all, then this open will be resolved soon.
let's wait for Peter's PR to zephyr and got merged.

@peter-mitsis , could you share PR link here once you submit here? or add me into review list for the zephyr PR？

#8787 is similar to this but with a Kconfig choice instead.

Will need to namespace these as SOF_ARCH_XTENSA_feature

where is ARCH_XTENSA and ARCH_XTENSA_HIFI_n definition? is it already exist or added later?

I am not sure this is best way to go, with this, module HIFI config still depend on core-isa, this is centuralized.

The logic is more complex and with more dependency, like XCC, more complex SOF_USE_HIFI macro definition, if expand this to other dsp platform(non-xtensa and X86), this part will need change again and hard to make changes.

module HIFI config still depend on core-isa, this is centuralized

You haven't summarized why these are bad.

We can duplicate core-isa.h in various places and I'm looking at options but core-isa.h will always remain the origin, true reference for HIFI facts.

with more dependency, like __XCC__

__XCC__ is the only reliable way to detect Cadence toolchains and it's what Zephyr uses.
#8682 (comment)

Which other dependency?

The logic is more complex [...] and hard to make changes.

If you find this logic complex then I'm afraid nothing can be done for you.

I mean maintain and expand complex, this logic is for xtensa, how about if a new architecture add? for example, ARM?