-
Notifications
You must be signed in to change notification settings - Fork 349
Tools: Topology: Add build of benchmark topologies for SDW #10047
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| Object.PCM.pcm_caps.1 { | ||
| direction "playback" | ||
| name $ANALOG_PLAYBACK_PCM | ||
| name $ANALOG_PLAYBACK_STREAM_NAME |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity, why is this change needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had stream name set to different than PCM name and noticed I had to change this also to get the topology to work. I could change it back as well, as you prefer.
Good you commented, I had a question in mind for you. What do you think, can the built SDW topology version be generic for all MTL SDW platforms with 3.5mm jack codec after rename to topology that kernel requests (or override tplg name with module option)? If yes, could this work also for other platforms like LNL and PTL? Do the platform definitions impact SDW settings (like e.g. NHLT impacts SSP and DMIC)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had stream name set to different than PCM name and noticed I had to change this also to get the topology to work. I could change it back as well, as you prefer.
Yes, as far as I understand, the PCM.pcm_caps name should be the same as the pipeline stream name. But it could be any string. That's why I was curious why changing the name is needed.
No, I don't have preference. I am ok with the change.
Good you commented, I had a question in mind for you. What do you think, can the built SDW topology version be generic for all MTL SDW platforms with 3.5mm jack codec after rename to topology that kernel requests (or override tplg name with module option)? If yes, could this work also for other platforms like LNL and PTL? Do the platform definitions impact SDW settings (like e.g. NHLT impacts SSP and DMIC)?
@singalsu I don't think the built SDW topology can be generic for all MTL SDW platforms. The platform definitions won't impact SDW settings, but the BE link names vary between machines. Like SDW0-Playback and Playback-SimpleJack.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I need to then offer at least those two BE link names variants, and I should be then able to drop the platform name string from topology. Then the number of different topologies for testing would remain quite low.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bardliao is the usage of SDWx-Playback and Playback-SimpleJack somehow "coded" into the normal production topology names? I wonder how I should show the alh-copier name in the test topologies. I'd not like to use sound chip names since there's many of them while the topologies still are the same, expect stream name.
Looks like most of the devices we build for are SimpleJack, but there are exceptions, like the laptop that I use for tests is SDW0, so I should build at least those two variants.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bardliao I added -sdw0 and -simplejack to topology names, how does this look now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bardliao is the usage of SDWx-Playback and Playback-SimpleJack somehow "coded" into the normal production topology names?
@singalsu No, however, we have the codec name and the SDW link number in the topology name. Like sof-lnl-rt712-l2-rt1320-l1.tplg where rt712 and rt1320 are codec names and l2 means SDW link 2, l1 means SDW link 1.
I added -sdw0 and -simplejack to topology names, how does this look now?
The topology naming looks good to me.
8e4a0df to
dc2452c
Compare
This patch adds build of test topologies for SDW MTL platforms, e.g. sof-mtl-sdw-benchmark-<module><16/24/32>.tplg. The benchmark topologies were before this build only for HDA generic platforms that limits current test devices availability. The HDA topologies build is cleaned up and benchmark tplg build is removed from the production topology high level file sof-hda-generic.conf. The required definitions are moved to cavs-benchmark-hda.conf. The io-gateway or dai definitions are moved to this file to keep the component specific topologies parts agnostic to audio codec endpoint. A similar high level benchmark topologies configuration file is added for SDW into cavs-benchmark-sdw.conf. The tplg-targets-bench.cmake is modified to build topologies for both HDA and SDW. In component specific files the dai-copier endpoints are passed in macro since the names are codec type specific. The route configurations are renamed to be without hda. The host gateway configuration is removed to be without io since it was moved to platform type specific higher level configuration. Signed-off-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com>
dc2452c to
61401f2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR refactors the benchmark topology configuration system to enable building of SDW (SoundWire) benchmark topologies for MTL platforms, alongside existing HDA support. The changes separate platform-specific configurations from generic component definitions, making the system more flexible and maintainable.
- Introduces a new SDW benchmark topology configuration for MTL platforms
- Refactors benchmark component configurations to use parameterized DAI endpoints
- Creates generic route configurations that work with both HDA and SDW backends
Reviewed Changes
Copilot reviewed 86 out of 86 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| sof-hda-generic.conf | Removes benchmark config from production HDA topology |
| cavs-benchmark-hda.conf | New comprehensive HDA-specific benchmark configuration |
| cavs-benchmark-sdw.conf | New SDW benchmark configuration for MTL platforms |
| include/bench/*.conf | Component configs updated to use parameterized pipeline indices and DAI endpoints |
| tplg-targets-bench.cmake | Build system updated to generate both HDA and SDW benchmark topologies |
| tplg-targets.cmake | References updated benchmark configuration |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
|
Will wait for @bardliao approval. |
|
SOFCI TEST |
This patch adds build of test topologies for SDW MTL platforms, e.g. sof-mtl-sdw-benchmark-<16/24/32>.tplg. The benchmark topologies were before this build only for HDA generic platforms that limits test devices availability.
The HDA topologies build is cleaned up and benchmark tplg build is removed from production topology high level file sof-hda-generic.conf. The required definitions are moved to cavs-benchmark-hda.conf. The io-gateway or dai definitions are moved to this file to keep component specific topologies parts agnostic to audio codec endpoint.
A similar high level benchmark topologies configuration file is added for SDW into cavs-benchmark-sdw.conf.
The tplg-targets-bench.cmake is modified to build topologies for both HDA and SDW.
In component specific files the dai-copier endpoints are passed in macro since the names are codec type specific. The route configurations are renamed to be without hda. The host gateway configuration is removed to be without io since it was moved to platform type specific higher level configuration.