Skip to content

Conversation

@jsarha
Copy link
Contributor

@jsarha jsarha commented May 26, 2025

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.

Jyri Sarha added 2 commits May 15, 2025 00:17
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>
Copy link
Member

@lgirdwood lgirdwood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, so is this a test topology that reproduces the issue ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. The same commit exists in the DP multi core test PR: #10009

@marcinszkudlinski
Copy link
Contributor

marcinszkudlinski commented May 28, 2025

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.
Another possible workaround (better in my opinion) - put all LL components that communicate with DP on core 0.

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

@lgirdwood
Copy link
Member

A proper fix for the issue is under development

Thanks - I think we should wait and upstream @jsarha test topology with your fix @marcinszkudlinski

@marcinszkudlinski
Copy link
Contributor

#10044

@jsarha
Copy link
Contributor Author

jsarha commented Jun 16, 2025

This is not needed any more.

@jsarha jsarha closed this Jun 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants