Skip to content

ASoC: SOF: topology: Use acpi mach from the machine driver #5665

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.

Sign up for GitHub

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

Open
bardliao wants to merge 1 commit into
base: topic/sof-dev
Choose a base branch
from
+6 −1
Open

ASoC: SOF: topology: Use acpi mach from the machine driver #5665

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion sound/soc/intel/common/sof-function-topology-lib.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,12 @@ enum tplg_device_id {
int sof_sdw_get_tplg_files(struct snd_soc_card *card, const struct snd_soc_acpi_mach *mach,
const char *prefix, const char ***tplg_files, bool best_effort)
{
struct snd_soc_acpi_mach_params mach_params = mach->mach_params;
struct snd_soc_acpi_mach *card_mach = dev_get_platdata(card->dev);
/*
* Use the acpi mach from the machine driver because the machine driver
* may change the dmic_num based on the machine driver quirk.
Copy link
Collaborator

@ujfalusi ujfalusi Feb 10, 2026

Choose a reason for hiding this comment

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

but the mach passed by parameter contains the num_dmic or other overrides coming from module parameters of SOF modules?

In code we use one of the match here and there, would be nice to clarify the rules?

Copy link
Member

@lgirdwood lgirdwood Feb 10, 2026

Choose a reason for hiding this comment

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

anything provided by the user should override data found in ACPI, NHLT, DISCO or quirks. i.e. user is overriding for a reason

Copy link
Collaborator Author

@bardliao bardliao Feb 10, 2026

Choose a reason for hiding this comment

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

but the mach passed by parameter contains the num_dmic or other overrides coming from module parameters of SOF modules?

The mach passed by parameter contains the num_dmic detected by the NHLT blob or the module parameters of the snd_sof_intel_hda_generic module. The dmic_num value will be set by the check_dmic_num() function.
And the sof_sdw machine driver may overwrite the num_dmic of its own mach by the quirk.

In code we use one of the match here and there, would be nice to clarify the rules?

Currently, I only see the sof_sdw machine driver will change the dmic_num.

anything provided by the user should override data found in ACPI, NHLT, DISCO or quirks. i.e. user is overriding for a reason

Agree. In general, module parameters have higher priority than the NHLT, quirks. However, the machine driver changes the dmic_num with below rules.

        if (ctx->ignore_internal_dmic) {
                dev_dbg(dev, "SoundWire DMIC is used, ignoring internal DMIC\n");
                mach_params->dmic_num = 0;
        } else if (mach_params->dmic_num) {
                dmic_num = 2;
        } else if (sof_sdw_quirk & SOC_SDW_PCH_DMIC) {
                dmic_num = 2;
                /*
                 * mach_params->dmic_num will be used to set the cfg-mics value of
                 * card->components string. Set it to the default value.
                 */
                mach_params->dmic_num = DMIC_DEFAULT_CHANNELS;
        }

ctx->ignore_internal_dmic will be true if a standalone SoundWire DMIC is used. We assume that PCH DMIC will not be used in such case. And we need the SOC_SDW_PCH_DMIC quirk for Chrome because there is no NHLT blob in the coreboot.

Copy link
Collaborator Author

@bardliao bardliao Feb 11, 2026

Choose a reason for hiding this comment

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

My first thought is to always use the mach from the machine driver because the machine driver may change the parameters. But it seems there is no guarantee that a card->dev's platform data should be snd_soc_acpi_mach although it seems to be a convention.

*/
struct snd_soc_acpi_mach_params mach_params = card_mach->mach_params;
struct snd_soc_dai_link *dai_link;
const struct firmware *fw;
char platform[SOF_INTEL_PLATFORM_NAME_MAX];
Expand Down
Loading