[FEATURE][meta] Use Zephyr native interfaces

[kv2019i]

This is a meta issue to track work to move SOF code to use Zephyr native interfaces. The task is two-fold:

1. move (audio) application code to use native Zephyr interfaces (this is the primary focus, affects all SOF users and configurations)
2. move driver and hw platform code to Zephyr (this is secondary as new platforms will be Zephyr-only -- current we have some Intel and IMX platforms that support both XTOS and Zephyr and separate set of cleanups are needed for these platforms)

Change in brief: SOF application code will transition to Zephyr application interfaces. Change is done incrementally so that build with the "in-tree XTOS" continuous to work.

Guard rails:

• code in sof/src/audio is the primary application code, should only use Zephyr interfaces
• drivers in sof/src/drivers should be moved to Zephyr upstream
• arch code in sof/src/arch is not used for SOF Zephyr builds, this is only for XTOS builds
• rtos interface provided via <rtos/foo.h> interface with implmentation in
  - sof/zephyr/include/rtos/
  - sof/xtos/include/rtos/

Transition tools:

• sof/zephyr/wrapper.c - xtos-to-zephyr wrapping that was used for initial introduction of Zephyr. this will grow smaller and smaller and eventually be removed
• sof/src/arch/xtos-wrapper/ - zephyr-to-xtos wrapper used to maintain capability to build SOF app code on XTOS
• when application code moves to use native Zephyr interface, XTOS fallback should be added in src/xtos/include/ (example xtos/include/rtos/spinlock.h )

Ongoing work for generic code (affects all SOF configurations):

• Module init with native Zephyr interface [FEATURE] Implement module_init in Zephyr builds #5406 [SOF2.5]
• Spinlocks Convert spinlock to Zephyr API #5286
• System clock for timing Wallclock Clocks timer: Align SOF timer API with Zephyr #5393
• Logging, partially done in sof: replace log calls with zephyr logging api #5707
• Wait k_usleep() and k_msleep() wrappers for xtos #5770
• Zephyr DAI interface - partially done in dma: switch to native Zephyr API for dw-dma & HDA #5610
• Zephyr DMA interface - partially started in dma: switch to native Zephyr API for dw-dma & HDA #5610
• Split of RTOS headers for XTOS/Zephyr rtos: abstraction: partition RTOS logic into separate directories #6161 [SOF2.5]
• Probe interface to use native Zephyr DMA interface - [BUG] unable to enable probes logging for MTL #7218 and Enable probes on MTL #7989
• Zephyr cache API z_xtensa_cache_*() -- dependency to xtensa: use generic cache API zephyrproject-rtos/zephyr#50136
• irq_local_*able() to to Zephyr irq_lock() / irq_unlock()
• make CONFIG_SOF_ZEPHYR_STRICT_HEADERS the default [BUG] make CONFIG_SOF_ZEPHYR_STRICT_HEADERS the default #9015
• cleanup overlap between Zephyr and SOF lib dma.h interfaces [FEATURE] Clean up SOF DMA interface(s) #9561

Ongoing work for SOF platform layer (affects all SOF configurations):

• Platform.h - [FEATURE][Zephyr] Clarify expectations of platform.h for Zephyr SOF builds #7248
• implement clk.h without platform layer [FEATURE][Zephyr] implement clk.h with native Zephyr interface and drop platform clk.h #9541
• implement mailbox.h without platform layer [FEATURE][Zephyr] replace mailbox.h with a IPC abstraction #9697
• implement cpu.h without platform layer -- zephyr: lib/cpu.h: remove dependency to platform layer #9648
• implement dai.h without platform layer -- remove platform lib/dai.h from SOF Zephyr builds #9653
• implement dma.h without platform layer -- zephyr: lib/dma.h: limit use of platform/lib/dma.h #9667
• implement pm_runtime.h without platform layer -- zephyr: decouple from platform pm_runtime.h interface #9495

Ongoing work for specific platforms (Intel cAVS, NXP IMX)

• PM runtime move to Zephyr PM model (Intel ACE done, Intel cAVS in zephyr: cavs: use zephyr pm, clk and dma glue #7183 )
• [FEATURE][Zephyr] Move all hw init code from platform_init() to Zephyr #5602

From @dbaluta - For NXP we have on roadmap to port to Zephyr:

• DAIs (SAI and ESAI);
• EDMA;
• SDMA;
• Interrupt controller (irq steer).

[hongshui3000]

is there any plan to move code in sof/src/platform/ to zephyr？
I want development drivers and platforms to be out of tree

[lgirdwood]

is there any plan to move code in sof/src/platform/ to zephyr？ I want development drivers and platforms to be out of tree

Yes - we are just working out the stages for this. Topic at TSC tomorrow.

[lenghonglin]

is there any plan to move code in sof/src/platform/ to zephyr？ I want development drivers and platforms to be out of tree

Yes - we are just working out the stages for this. Topic at TSC tomorrow.

Is there something news to share after TSC？

[lgirdwood]

@lenghonglin apologies, I and some other TSC member were travelling last week.

Please see minutes here. https://github.com/orgs/thesofproject/teams/steering-committee/discussions/31

[lgirdwood]

@kv2019i we should add the DAI/DMA integration here too ?

[kv2019i]

Marked multiple items as done. Added one new item for platform code init.

[lgirdwood]

@abonislawski @mwasko @dbaluta any items you can add/update here ?

[kv2019i]

A lot of work has been done to cleanup the XTOS/Zephyr split in SOF codebase for 2.5, and to continue the move to native calls in SOF application code. Some work is left though, so moving this meta item for v2.6 milestone. A few subitems are still queued for v2.5 and they will be included if they get merged to main before the cutoff.

[lgirdwood]

@abonislawski @lyakh @juimonen anything else still todo ? cache API ?

[lyakh]

@abonislawski @lyakh @juimonen anything else still todo ? cache API ?

@lgirdwood yes, moving over to the Zephyr native z_xtensa_cache_*() API is one of the remaining items. irq_local_*able() is another XTOS API that's still widely used in SOF.

[kv2019i]

Updated description of the transition tools and guarrails to include the new "{xtos/zephyr}/include/rtos" mechanism to abstract OS services.

Also added @lyakh the cache and local ireq control as tasks. Please do add items directly here as well. This will serve both as a tasklist, and will provide example how to do the transitions.

[lgirdwood]

@dbaluta any Zephyr related interfaces pending for NXP ?

[iuliana-prodan]

@dbaluta any Zephyr related interfaces pending for NXP ?

For NXP we have on roadmap to port to Zephyr:

• DAIs (SAI and ESAI);
• DMAs (SDMA and EDMA);
• Interrupt controller (irq steer).

We are now using the ones from SOF.

[lgirdwood]

@juimonen @dbaluta are we on track for v2.6 ? Can we close ?

[kv2019i]

@lgirdwood let's dis-engage this meta-item from the milestones and track the subitems with milestones instead. FYI for @dbaluta . This can be then used for other vendors as well to help with the Zephyr migration.

[dbaluta]

@kv2019i do you suggest on creating separate Issues for NXP for example, to track the switch to native interfaces?

Since Zephyr has a DAI interface, for us porting NXP DAIs should be low hanging fruits and doable for v2.6

We need to look into the DMA and also the IRQ controller as this could be trickier.

Cc: @iuliana-prodan

[kv2019i]

@dbaluta I think we can keep NXP issues here as well. We can assign subitems (like the DAI port) to milestones and track them at that level.

[iuliana-prodan]

@kv2019i @lgirdwood is the Zephyr native drivers for DAI, DMA, irq related with IPC4?
Meaning, can we move to zephyr native drivers for DAI, DMA and still using IPC3?
Or should we move to IPC4 also?

[kv2019i]

@iuliana-prodan the DAI/DMA interfaces are IPC agnostic, so no hard requirement to move to IPC4 to use native drivers. The main changes are in dai-zephyr.c/dai-legacy.c and host-zephyr.c/host-legacy.c. There are a few IPC specific bits, but those are related to IPC functionality like bind/unbind (only in IPC4), so the main code is completely shared. Of course with Intel targets moved to IPC4, testing coverage is better with IPC4 now (would be nice to have some IPC3 devices in upstream SOF CI so we'd catch issues sooner).

[dbaluta]

Cc: @LaurentiuM1234 who is working on this.

[LaurentiuM1234]

Small update on NXP's side:

1. Driver status
   • irqsteer driver was tested (nothing fancy, just checked if aplay works, will most likely require a stress test to make sure everything's fine) and is done. Zephyr PR: drivers: interrupt_controller: Add driver for NXP's irqsteer zephyrproject-rtos/zephyr#62776.
   • DAI/EDMA drivers are mostly done. Will upstream once I make sure everything's fine.
2. Switch to native drivers status
   • currently, I'm working on switching i.MX93 to using the Zephyr native drivers plus the dai-zephyr/host-zephyr combo.
   • so far no issue with the IPC version (as far as I can tell)
   • will probably have to tweak/rework the Zephyr DMA domain (unless we switch to the timer domain?) as things are a bit different now (e.g: IRQ management is done in the drivers, the state of the DMA channels is something internal to the driver and we can't query it ATM etc... + we have the option to use the DMA CB instead of enabling Zephyr shared interrupts and then registering dma_irq_handler)
3. To dos
   • as far as I can tell right now, before we can switch we need to sort out the domain issue and implement the rest of the drivers (SDMA, ESAI and MU). Hopefully I didn't miss anything?

[lgirdwood]

@marcinszkudlinski @mwasko @abonislawski @softwarecki @kv2019i @lyakh any other nativization work that should be added to the main feature list as we are nearing completion of initial tasks.

[kv2019i]

Add:

• [BUG] make CONFIG_SOF_ZEPHYR_STRICT_HEADERS the default #9015

[LaurentiuM1234]

From NXP's side: imx8, imx93, and imx8ulp have all been ported to native Zephyr. All of these platforms have been switched to timer domain, which, so far, has been working well. For the switch, we've added drivers in Zephyr for the following IPs previously kept in SOF tree:

1. IRQ_STEER
2. SAI
3. ESAI
4. EDMA

[lgirdwood]

@dbaluta @LaurentiuM1234 @iuliana-prodan - Great work everybody :)

I guess this now means you can remove NXP xtos code in main and do similar code clean ups like @kv2019i is doing atm for Intel to simplify your code base.

[kv2019i]

Added a separate section for tasks related to "thinning out" the sof/src/platform layer for Zephyr builds. In short the the intention is to continue pruning this interface and move everything that is hardware specific, to Zephyr. This will reduce the work that needs to be done to add a new hardware target to SOF.