How long do we need XTOS driver support for SOF Zephyr builds?

[kv2019i]

In short: SOF mainline has support to build SOF with Zephyr as RTOS, but still use existing XTOS-based drivers (in sof/src/drivers/ ).
In build this is gated behind CONFIG_ZEPHYR_NATIVE_DRIVERS Kconfig option.

This utility has been used by e.g. NXP and Intel to transfer to Zephyr, but for NXP and Intel platforms the transition starts to be complete (#9608 is left).

The question I have now is: how long we should keep this transition layer in place?

Use of XTOS drivers is not only option to transition. When Zephyr support was added to the first targets, this was probably more important as we did not have experience in porting over a full SOF implementation to Zephyr, and there were gaps in interfaces (e.g. for DAIs), but now in 2024, there are multiple shipping products as plenty of examples both in Zephyr and SOF, so a more direct jump to native Zephyr drivers is possible (and could be even less work).

There is some cost in keeping this support around as the SOF Zephyr build must continue to support full set of interfaces used by XTOS drivers. This set some hard limits on how much we can clean SOF side code that is using Zephyr as we need to keep the ability to use XTOS drivers as well (which have their own distinct interfaces). This is very visible e.g. in #9728 .

Based on comments in #9731 , it would seem at least MTK platforms are planning to use XTOS drivers.

How about @thesofproject/amd . I see @DINESHKUMARK1 #9578 was still using XTOS drivers in the Zephyr port? Is the plan to use same approach for other platforms?

References:

• [FEATURE][meta] Use Zephyr native interfaces #5794

[bhiregoudar]

Currently work in progress for AMD to migrate to Zephyr native drivers.

[lgirdwood]

Ok, so it sounds like v2.12 (January 2025) will be last release with xtos in the codebase and once @andyross and @bhiregoudar are ready we can delete the xtos code and clean up APIs to align fully with Zephyr for full performance and simplification.

[andyross]

That sounds doable. The existing MTK layer is a proprietary AFE device to talk to the audio devices, which I think I have a pretty good handle on.

The host side is a CPU-copied dummy_dma thing that AFAICT was cut/pasted from NXP work, though it doesn't need the complexity of HOST_PTABLES as the allocations host-side are out of a contiguous DSP-dedicated space. I don't know how this is evolving, and it looks like NXP is moving to a real DMA controller for the host transfers? If so I may need to do a Zephyr port of this. MTK doesn't expose any mem-to-mem DMA devices in the integrations already contributed (and even so there's nothing in the kernel either).

Basically @dbaluta: what's the plan for dummy_dma and HOST_PTABLES? Are you Zephyrizing those or should I?

[dbaluta]

Basically @dbaluta: what's the plan for dummy_dma and HOST_PTABLES? Are you Zephyrizing those or should I?

dummy_dma was already ported to Zephyr by @LaurentiuM1234 under drivers/dma/dma_nxp_sof_host_dma.c. Maybe the nxp naming could have been made generic as I understand also MTK uses it.

the dummy/host driver /HOST TABLE was actually done to fit into Intel programming model. Maybe at some point we can just remove it and refactor Host component to get rid of it.

Cc: @LaurentiuM1234

[andyross]

Actually I think the idea of having every endpoint be a "zephyr DMA device" has a lot of value, as it's a clean expression of "a thing that copies into and out of local memory"). The job of the host component should just be to translate "zephyr DMA" to "SOF sof_source/sink".

IMHO, if we really want to innovate here, what we really want to do is have the initial component stream directly out of host memory (i.e. wrap the host interface in a source/sink directly).

Will take a look at that driver. But a quick scan seems to show that it's single-buffer only, no HOST_PTABLES support. Is that not needed (which would be very nice for MTK, which has a contiguous buffer) or handled in SOF still? Would be good to put that protocol into the DMA device itself.

[LaurentiuM1234]

The HOST_PTABLE stuff is still handled in SOF

But a quick scan seems to show that it's single-buffer only

At this point the driver (i.e: dma_nxp_sof_host_dma.c) is really just a wrapper over a memcpy + some cache invalidations/flushes which you need to configure each time with the source and destination addresses. If you have multiple buffers I guess you can configure it with each of the buffer's addresses and perform the transfers (i.e: configure address, transfer, configure address, transfer etc..) but I'm not sure how well suited this would be for MTK's case?

Would be good to put that protocol into the DMA device itself

Would be interesting to see how this would play out