Temporary fix for multi core DP component memory problems#10031
Temporary fix for multi core DP component memory problems#10031jsarha wants to merge 2 commits intothesofproject:mainfrom
Conversation
This commit creates three new topologies, sof-mtl-nocodec-dp-core-test.tplg, sof-lnl-nocodec-dp-core-test.tplg, and sof-ptl-nocodec-dp-core-test.tplg. They are otherwise the same as the corresponding standard nocodec topologies, but both the src.11.1 on SSP2_Playback and src.5.1 on SSP2 Capture have scheduler_domain attribute set to "DP" and core_id to 1. This configuration executes SRC components for playback and capture to/from hw:0,2 on DSP core 1 in Data Processing mode, while the rest of the SSP2 pipelines are executed on DSP core 2. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>
Fix multi core data processing domain component issues by disabling virtual heap and resorting to more robust Zephyr allocation method. This is a temporary remedy to the problem until a better solution is found. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>
lgirdwood
left a comment
There was a problem hiding this comment.
I think its better we fix the issue in L3/VMH heap @jsarha @marcinszkudlinski but having a more robust 3 core pipeline topology for testing/CI is a good idea (so we can take that part).
| DMIC0_PCM_0_NAME "DMIC SFX1" | ||
| DMIC0_PCM_1_NAME "DMIC SFX2" | ||
| SRC_DOMAIN "default" | ||
| # Keep DP_SRC_CORE_ID == SSP2_PCM_CORE_ID, no nested define resolvation ATM |
There was a problem hiding this comment.
ok, so is this a test topology that reproduces the issue ?
There was a problem hiding this comment.
Yes. The same commit exists in the DP multi core test PR: #10009
|
If we really do need to enable those pipelines - go for it, just please add a clear comment in kconfig - disabled as a workaround etc. etc. And we do need to perform a full-scope testing, as virtual heaps were developed for memory optimalization and some scenarios may fail because of memory fragmentation etc. A proper fix for the issue is under development |
Thanks - I think we should wait and upstream @jsarha test topology with your fix @marcinszkudlinski |
|
This is not needed any more. |
This is a temporary fix for #10024 and includes #10009 .
The fix probably has some impact to SRAM usage and I made this a draft PR for now.