ASoC: soc-acpi / SOF: Add best_effort flag to get_function_tplg_files op#5596
Merged
bardliao merged 2 commits intothesofproject:topic/sof-devfrom Dec 1, 2025
Conversation
ujfalusi
requested review from
bardliao,
dbaluta,
kv2019i,
lgirdwood,
plbossart and
ranj063
as code owners
bardliao
previously approved these changes
Nov 20, 2025
This was referenced Nov 20, 2025
kv2019i
reviewed
Nov 25, 2025
Collaborator
kv2019i
left a comment
kv2019i
left a comment
There was a problem hiding this comment.
Code is ok, one inline comment about readability...
|
|
||
| if (!sof_pdata->disable_function_topology && !disable_function_topology && | ||
| sof_pdata->machine && sof_pdata->machine->get_function_tplg_files) { | ||
| bool no_fallback = strstr(file, "dummy"); |
Collaborator
There was a problem hiding this comment.
This bit would benefit from some hint (in code comment?) why "dummy" should change the behaviour. I think it's ok to have the longer story in commit message, but something in code would be helpful why this check is done.
Collaborator
Author
There was a problem hiding this comment.
OK, I'll cook up something
ujfalusi
force-pushed
the
peter/sof/pr/function-tplg-best-effort
branch
from
d8a9f36 to
0287b57
Compare
When there is no fallback possibility available for the function topology use it is better to try to create a profile for the card in best effort manner, leaving out non supported links for example. As an example: some laptops present SSPx-BT link but we don't have fragment yet to support this. If we only have support for functional topology without monolithic fallback then we would fail the card creation. The reason why the monolithic topology works on the same device is that it does not have the SSPx-BT link handled, it is ignored. In case when there is no fallback possibility we should try to create the card with links that we support as best effort instead of failing and leaving the user without a card. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
…able Revert "ASoC: Intel: soc-acpi-intel-nvl-match: add rt722 l3 support" NVL should be only using functional topologies for products, no monolithic topologies are planned to be released. In parallel a feature has been landed [1] which allows to remove the entries from the match table for sdca codecs to rely solely on function fragments. Link: https://lore.kernel.org/linux-sound/20251014071335.3844631-1-yung-chuan.liao@linux.intel.com/ This reverts commit 41566e3. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Collaborator
Author
|
Changes since v1:
|
kv2019i
approved these changes
Nov 25, 2025
bardliao
approved these changes
Nov 26, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When there is no fallback possibility available for the function topology use it is better to try to create a profile for the card in best effort manner, leaving out non supported links for example.
As an example: some laptops present SSPx-BT link but we don't have fragment yet to support this. If we only have support for functional topology without monolithic fallback then we would fail the card creation. The reason why the monolithic topology works on the same device is that it does not have the SSPx-BT link handled, it is ignored.
In case when there is no fallback possibility we should try to create the card with links that we support as best effort instead of failing and leaving the user without a card.
Remove the rt722 from the nvl match table to force the use of function topologies.