sof: ipc: switch platform IPC to Zephyr service

[tmleman]

This patch reworks the SOF IPC platform integration to use the generic Zephyr ipc_service instead of the Intel audio DSP specific driver.

Before this change SOF was talking directly to the Intel ADSP IPC driver, which made the IPC path tightly coupled to that particular backend. All commands were sent and completed via intel_adsp_ipc_*() functions.

The code now sends and receives IPC commands through a Zephyr ipc_service endpoint registered on the Intel ADSP host IPC instance, using sof_ipc_receive_cb() as the receive handler. Incoming messages are processed as before using the existing compact IPC path to process commands.

Each IPC command is treated as a compact two-word ipc_cmd_hdr and a BUILD_ASSERT guarantees that the header size remains aligned with the transport format assumptions.

This change is part of ongoing work to better integrate SOF with Zephyr and will allow other vendors to more easily integrate their own IPC backends.

[Copilot]

Pull request overview

This PR migrates SOF's platform IPC implementation from the Intel-specific ADSP IPC driver to the generic Zephyr ipc_service API, enabling better integration with Zephyr and easier vendor customization.

Key Changes:

• Replaced direct intel_adsp_ipc_*() calls with ipc_service_*() API calls throughout the IPC path
• Introduced sof_ipc_receive_cb() as the new IPC service endpoint callback handler
• Added compile-time assertion to validate IPC header format assumptions

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
west.yml	Updates Zephyr dependency to a PR branch containing the required IPC service changes
src/ipc/ipc-zephyr.c	Replaces Intel ADSP IPC driver calls with generic Zephyr IPC service API, registers endpoint, and updates message handling callbacks

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[lgirdwood]

@tmleman Jenkins results are good atm.

[lgirdwood]

@kv2019i pls take a look

[kv2019i]

Thanks @tmleman ! Let's see the CI results, this needs a thorough test, but code looks good.

[abonislawski]

In QB unrelated/known sporadic fail? Test didnt start

[tmleman]

@kv2019i @abonislawski @lgirdwood I must mention that there are two known problems caused by the refactor on the Zephyr side:

• intel_adsp/cavs25: intel_adsp_hda testsuite failure zephyrproject-rtos/zephyr#102106
• intel_adsp: boards.intel_adsp.smoke testsuite fail on different platforms zephyrproject-rtos/zephyr#102103

I was unable to reproduce this in the SOF environment and it probably only affects the intel_adsp_ipc_send_message_sync function.

[lgirdwood]

@kv2019i @abonislawski @lgirdwood I must mention that there are two known problems caused by the refactor on the Zephyr side:

• intel_adsp/cavs25: intel_adsp_hda testsuite failure zephyrproject-rtos/zephyr#102106
• intel_adsp: boards.intel_adsp.smoke testsuite fail on different platforms zephyrproject-rtos/zephyr#102103

I was unable to reproduce this in the SOF environment and it probably only affects the intel_adsp_ipc_send_message_sync function.

Can you check the PTL CI, lot of red, if unrelated we can rerun. Btw, do you have any fixes pending for Zephyr to prevent a revert ?

[softwarecki]

Great work. I like this solution and the direction it takes the design.

[tmleman]

@lgirdwood I haven't reviewed all the failures but in those I checked I don't see a connection to IPC. On the FW side, however, there's a recurring error:

[  303.601320] <inf> ipc: ipc_cmd: rx	: 0x47000000|0x0
[  303.601665] <err> os: k_mem_domain_init: architecture-specific initialization failed for domain 0x40191cf8 with -12

Regarding the issues filed in Zephyr, I'm working on this: zephyrproject-rtos/zephyr#102572

[lyakh]

@tmleman a fix for those PTL failures has been merged, let's re-test

[lyakh]

SOFCI TEST

[tmleman]

@lyakh Indeed there are fewer errors, but something new appeared on MTL (multiple-pause-resume-50.sh): https://sof-ci.01.org/sofpr/PR10422/build18627/devicetest/index.html

[ 2525.377050] <inf> ll_schedule: zephyr_domain_unregister: zephyr_domain_unregister domain->type 1 domain->clk 0
[ 2525.378645] <inf> ipc: ipc_cmd: rx	: 0x12000000|0x0
[ 2525.379131] <err> ipc: ipc_comp_free: comp id: 0x5 state is 5 cannot be freed
[ 2525.379216] <err> ipc: ipc_pipeline_free: module free () failed
[ 2525.379335] <err> ipc: ipc_cmd: ipc4: FW_GEN_MSG failed with err 12
[ 2525.380258] <inf> ipc: ipc_cmd: rx	: 0x46020005|0x20007
[ 2525.381821] <inf> ipc: ipc_cmd: rx	: 0x12010000|0x0
[ 2525.382126] <err> ipc: ipc_comp_free: comp id: 0x10007 state is 5 cannot be freed
[ 2525.382271] <err> ipc: ipc_pipeline_free: module free () failed
[ 2525.382320] <err> ipc: ipc_cmd: ipc4: FW_GEN_MSG failed with err 12
[ 2525.384188] <inf> ipc: ipc_cmd: rx	: 0x12020000|0x0
[ 2525.384510] <err> ipc: ipc_comp_free: comp id: 0x20007 state is 5 cannot be freed
[ 2525.384655] <err> ipc: ipc_pipeline_free: module free () failed
[ 2525.384703] <err> ipc: ipc_cmd: ipc4: FW_GEN_MSG failed with err 12

However, I don't see a connection between these errors and the IPC changes.

[kv2019i]

@tmleman Let me kick the Linux CI once more so we get an additional data point. I checked test runs from this week, and this test has passed without on the same test device, which is somewhat suspicious. it's also true we've seen errors in longer stress test with current SOF main, so it could also be your PR was just unlucky and triggered an existing problem. Anyways, IPC changes are always potentially high-impact, so let's do an additional round.

[kv2019i]

SOFCI TEST

[lyakh]

@lyakh Indeed there are fewer errors, but something new appeared on MTL (multiple-pause-resume-50.sh): https://sof-ci.01.org/sofpr/PR10422/build18627/devicetest/index.html

hm, looks like it's started a bit earlier with this:

[ 2519.815810] <wrn> host_comp: host_get_copy_bytes_normal: comp:3 0x40005 no bytes to copy, available samples: 0, free_samples: 192
[ 2525.316150] <wrn> dai_comp: dai_common_copy: comp:0 0x5 nothing to copy, src_frames: 132, sink_frames: 0
--- 478 messages dropped ---
[ 2525.317233] <wrn> dai_comp: dai_common_copy: comp:0 0x5 Copy_bytes 0 + free bytes 128 < period bytes 768, possible glitch
[ 2525.317350] <wrn> dai_comp: dai_common_copy: comp:0 0x5 nothing to copy, src_frames: 184, sink_frames: 0
[ 2525.318176] <wrn> dai_comp: dai_common_copy: comp:0 0x5 nothing to copy, src_frames: 36, sink_frames: 0
[ 2525.319258] <wrn> dai_comp: dai_common_copy: comp:0 0x5 nothing to copy, src_frames: 88, sink_frames: 0

[tmleman]

@tmleman Let me kick the Linux CI once more so we get an additional data point. I checked test runs from this week, and this test has passed without on the same test device, which is somewhat suspicious. it's also true we've seen errors in longer stress test with current SOF main, so it could also be your PR was just unlucky and triggered an existing problem. Anyways, IPC changes are always potentially high-impact, so let's do an additional round.

I have nothing against it. I'd rather wait and be sure than watch someone revert my changes 😛

[kv2019i]

The rerun results look better and the test that was previously failing now passes. So this supports the argument that the fail is not related to this PR. Let me proceed with the merge so we can expose this to more testing.

And thanks to @dcpleung who made the initial version of the service switch, great to have this complete!