dp: nocodec: switch playback SRC to DP by default

[lyakh]

Switch one of the two SRC instances in the nocodec topology to DP mode by default.

[lgirdwood]

@lyakh Some nocodec failings.

[lyakh]

@lyakh Some nocodec failings.

@lgirdwood yes, I've traced it back to an update in Zephyr, which had disabled double mapping. I'm working to fix it.

[Copilot]

Pull request overview

This PR switches the playback SRC (Sample Rate Converter) to use the DP (Data Processing) domain by default in the nocodec topology, while keeping the capture SRC in the default domain. Additionally, it adds cached memory partition support for DP scheduler tasks.

Key changes:

• Splits the SRC domain configuration into separate playback and capture domains
• Adds cached memory partition support (HEAP_CACHE and CFG_CACHE) for improved memory access patterns
• Updates test topology parameters to maintain capture path DP testing

Reviewed changes

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

File	Description
tools/topology/topology2/cavs-nocodec.conf	Splits SRC_DOMAIN into SRC_DOMAIN_PLAYBACK (DP) and SRC_DOMAIN_CAPTURE (default) and updates widget configurations
tools/topology/topology2/development/tplg-targets.cmake	Updates test topology parameters from SRC_DOMAIN to SRC_DOMAIN_CAPTURE for MTL, LNL, and PTL platforms
src/schedule/zephyr_dp_schedule_application.c	Adds cached memory partition initialization and cleanup for both heap and mailbox partitions
src/schedule/zephyr_dp_schedule.h	Extends the sof_dp_part_type enum with HEAP_CACHE and CFG_CACHE partition types

---

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

[lyakh]

SOFCI TEST

[lyakh]

retest with #10474 merged

[lyakh]

SOFCI TEST

[lyakh]

SOFCI TEST

[lyakh]

SOFCI TEST

[lyakh]

SOFCI TEST

[softwarecki]

I think we have crossed the line in terms of the amount of additional changes being bundled into a single PR, and it would be better to split it. This PR started as a change limited to SRC configuration, but it now also:

• updates Zephyr (disable FLIX)
• removes fast_get/put syscalls
• modifies the objpool allocator
• introduces some changes in DP

Regarding the Zephyr update:
Commit message / description is misleading. The fix for the double exception is already in use (Zephyr update done by #10494). The Zephyr update in this PR disabling FLIX! It also switching some configuration options, which are not described.

I recommend splitting this PR into smaller, logically scoped changes. At a minimum, I would expect commit messages to be corrected so that they accurately reflect the actual changes and do not mislead reviewers.

[lyakh]

Commit message / description is misleading. The fix for the double exception is already in use (Zephyr update done by #10494). The Zephyr update in this PR disabling FLIX! It also switching some configuration options, which are not described.

@softwarecki no, I don't think this is correct:

$ git log --oneline c1a2b3be459d4f34d31ae54774fd57e96438d237..935a8f7ceecb78f0c0fe2f14476c20aa82541f0a --author=Leung
a5a9ff4c28c xtensa: handle instruction TLB multi-hit exception
9b9e9ebde77 xtensa: mmu: data TLB multi-hit only handle exception address
599df95875c xtensa: return back to interrupted thread for certain exceptions
27e48026215 xtensa: remove unnecessary setting of is_fatal_error during exc
34021be7891 cmake: toolchain/xt-clang: add flag to skip FLIX generation
8776407309b cmake: compiler: add flags for VLIW generations
8c02dde4377 xtensa: move MMU init functions to mmu.c
ed4cec2d220 xtensa: ptables: doxygen doc
744a7f4daf1 xtensa: mmu: do doxygen for functions
50e980d9a83 xtensa: mmu: halt system if not enough L2 tables during boot
82b7d94d452 xtensa: mmu: add debug logs on page table allocations
0777dbea028 xtensa: mmu: assert when L2 table allocation fails during dup
231e72af8ed boards: snps/arc: add nsim_vpx5/mpuv3 board
ee8f9915a45 soc: arc: mark nsim_vpx5 as supporting MPU
2c911b1b8a8 soc: snps: vpx5: no -Hccm compiler option for userspace

[lgirdwood]

I think we have crossed the line in terms of the amount of additional changes being bundled into a single PR, and it would be better to split it. This PR started as a change limited to SRC configuration, but it now also:

• updates Zephyr (disable FLIX)
• removes fast_get/put syscalls
• modifies the objpool allocator
• introduces some changes in DP

Regarding the Zephyr update: Commit message / description is misleading. The fix for the double exception is already in use (Zephyr update done by #10494). The Zephyr update in this PR disabling FLIX! It also switching some configuration options, which are not described.

I recommend splitting this PR into smaller, logically scoped changes. At a minimum, I would expect commit messages to be corrected so that they accurately reflect the actual changes and do not mislead reviewers.

There is no gain in resending patches again. Important thing is its all separate patches, all been reviewed, passing CI (with is constrained today).

Lets spend our time on the technical aspects.

[lgirdwood]

ok, so FLIX broke userspace and is fixed by @dcpleung - we need to merge this 1st and then merge #10511

[softwarecki]

no, I don't think this is correct:

@lyakh This one disable FLIX for userspace builds:

8776407309b cmake: compiler: add flags for VLIW generations

choice COMPILER_CODEGEN_VLIW
	default COMPILER_CODEGEN_VLIW_DISABLED if USERSPACE

[softwarecki]

There is no gain in resending patches again.

@lgirdwood: Agree, this is a recommendation, not an expectation.

For the future, we should avoid starting with a small PR and then adding several unrelated changes after approvals are already given. Changes added later often do not get the same level of review, because reviewers typically do not re-review a PR they have already approved. That creates a risk of changes effectively bypassing proper review.

[lyakh]

no, I don't think this is correct:

@lyakh This one disable FLIX for userspace builds:

8776407309b cmake: compiler: add flags for VLIW generations

choice COMPILER_CODEGEN_VLIW
	default COMPILER_CODEGEN_VLIW_DISABLED if USERSPACE

@softwarecki I know. But the goal of that Zephyr update was to include TLB fixes. So your statement "The fix for the double exception is already in use" was wrong. That's what I pointed out to.

[lyakh]

There is no gain in resending patches again.

@lgirdwood: Agree, this is a recommendation, not an expectation.

For the future, we should avoid starting with a small PR and then adding several unrelated changes after approvals are already given. Changes added later often do not get the same level of review, because reviewers typically do not re-review a PR they have already approved. That creates a risk of changes effectively bypassing proper review.

I agree that keeping approvals can backfire. But reviewers absolutely should re-review PRs after each update and update their approvals accordingly.

[abonislawski]

Let's wait for #10511 and we will be fine with flix mess and zephyr update

[lgirdwood]

Let's wait for #10511 and we will be fine with flix mess and zephyr update

Now merged.

[softwarecki]

But the goal of that Zephyr update was to include TLB fixes.

@lyakh Indeed. I had no idea that zephyrproject-rtos/zephyr#103104 exist and I thought the double exception referred to my PR (zephyrproject-rtos/zephyr#102341). Zephyr was updated in another PR. FLIX remains enabled, so I do not see any blockers. I am not sure whether we should wait for zephyrproject-rtos/zephyr#103465 instead of disabling CONFIG_ACE_V1X_RTC_COUNTER in the config.

[abonislawski]

I assume this is disabled only for test.

zephyrproject-rtos/zephyr#103465 should be merged very soon and this will not be needed

[lgirdwood]

I've asked for this to be prioritized since its tainting CI results.

[lgirdwood]

@lyakh lets remove this conf change as we can rebase with the west fix for above Zephyr fix.

[lyakh]

but do we need that driver? If we don't need it anyway, why include it?

[abonislawski]

Not critical feature but it is actually used in intel base_fw.

Someone made a regression in zephyr and it just needs to be fixed, luckily it's easy

[lyakh]

https://github.com/thesofproject/sof/actions/runs/21742080825/job/62719480359?pr=10469 is a regression introduced by #10523 #10523 (comment)

[lyakh]

d263649 reverted because of a regression in SRC DP:

[  280.863861] <wrn> module_adapter: module_ext_init_decode: dp_data object too small 12 < 20
[  280.864021] <wrn> module_adapter: z_impl_mod_alloc_ext: mngr (nil) != cur 0x401907d0
[  280.865958] <inf> dp_schedule: dp_thread_fn: comp:0 0x100f userspace thread started
[  280.866228] <err> src_init: comp:0 0x100f Missing or bad size (44) init data
[  280.866368] <err> module_adapter: module_init: comp:0 0x100f error -22: module specific init failed
[  280.866446] <err> module_adapter: module_adapter_new_ext: comp:0 0x100f -22: module initialization failed
[  280.866905] <err> module_adapter: z_impl_mod_free: comp:0 0x100f error: could not find memory pointed by 0x40204380
[  280.867976] <err> ipc: ipc4_init_module_instance: error: failed to init module 100f : 0
[  280.868035] <err> ipc: ipc_cmd: ipc4: MODULE_MSG failed with err 104

https://sof-ci.01.org/sofpr/PR10469/build19047/devicetest/index.html?model=PTLH_RVP_NOCODEC&testcase=check-playback-10sec