[FEATURE][Zephyr] Clarify expectations of platform.h for Zephyr SOF builds

[kv2019i]

Levelling up from #5602

Is your feature request related to a problem? Please describe.
The platform.h has three interfaces:

int platform_boot_complete(uint32_t boot_message);
int platform_init(struct sof *sof);
int platform_context_save(struct sof *sof);

Plus a set of capability definitions used by application code (like PLATFORM_MAX_CHANNELS). These need to be defined by each platform via platform.h.

Documented here: https://github.com/thesofproject/sof/blob/main/src/include/sof/platform.h

Now we have three types of platforms implemented in SOF main (2023/March situation):

• native Zephyr, can only be built with Zephyr (e.g. platform/intel/ace)
• native XTOS, can be only built with XTOS (e.g. platform/mtk8186)
• hybrid that can be built with either Zephyr or XTOS (e.g. platform/intel/cavs and platform/imx8)

Describe the solution you'd like
Clear definition of semantics of platform.h expected for native Zephyr platforms. Based on experience with intel/ace , there is still need for a thin platform layer.

As XTOS does not have its own platform layer, SOF platform.h will need to continue to serve as the platform layer as long as SOF main supports XTOS builds.

Describe alternatives you've considered

• removal of platform layer completely and make it XTOS only interface
  - this is still a possibility but hard to do unless all platforms move to native Zephyr
  - a new solution would be needed for e.g. intel/ace/platform.c
• split out "platfrom-capability.h" that only exports platform.h interfaces needed by src/audio/
  - on Zephyr this can be a thin mapping to DTS information (and possibly shared across platforms)
  - this would allow to clean up code for hybrid platforms that continue to support both Zephyr and XTOS builds (versus the current ifdef ZEPHYR mess we have now in some of the platform files)

Additional context

[kv2019i]

FYI @thesofproject/maintainers @andyross @lenghonglin @marcinszkudlinski @mwasko @Andrey @dbaluta @LaurentiuM1234 @paulstelian97

[dbaluta]

int platform_boot_complete(uint32_t boot_message);
int platform_boot_complete(uint32_t boot_message);

Do you mean int platform_init(struct sof *sof) instead of one of platform_boot_complete?

[kv2019i]

Cleared the v2.7 milestone. Let's use this meta-item to track the transition of platfrom from XTOS to hybrid and to native Zephyr. This is likely to require multiple releases to complete.

[marc-hb]

hybrid that can be built with either Zephyr or XTOS (e.g. platform/intel/cavs and platform/imx8)

I believe it's only imx8 left now in the main branch, correct?

this would allow to clean up code for hybrid platforms that continue to support both Zephyr and XTOS builds (versus the current ifdef ZEPHYR mess we have now in some of the platform files)

Is this hybrid mode still necessary? It was useful to quickly and conveniently compare XTOS and Zephyr when Zephyr was taking off and had no SOF track record or validation yet. Now that Zephyr is routinely validated on some platforms, any future platform trying to switch to Zephyr too has the confidence of a common codebase that is well tested by other platforms. So maybe SOF does not need such an hybrid mode any more?

In other words and pardon me if I'm over-simplifying because I'm not familiar with this topic:

• ./src/platform/imx8m-XTOS/platform.c
• ./src/platform/imx8m-zephyr/platform.c

... with a fair amount of copy/paste between the two: who cares it's only a temporary transition!

My 2 cents, hope its helps.

[lgirdwood]

@kv2019i we should not need a platform.c for Zephyr builds as all IP code should now be in Zephyr. If there is application init code around in platform.c then we can move it to a more generic init file.

[kv2019i]

Linking here as well. To manage custom vendor code to add IPC4 tuples, SOF platform concept seems like a good fit, my arguments for this at #9012 (comment)