Messages in this thread | | | Subject | Re: [PATCH] ASoC: Intel: bxt-da7219-max98357a: support MAX98390 speaker amp | From | Pierre-Louis Bossart <> | Date | Tue, 30 Jun 2020 11:26:53 -0500 |
| |
>> diff --git a/sound/soc/intel/boards/Kconfig >> b/sound/soc/intel/boards/Kconfig index 3d820e1..b3b863e 100644 >> --- a/sound/soc/intel/boards/Kconfig >> +++ b/sound/soc/intel/boards/Kconfig >> @@ -291,9 +291,17 @@ config >> SND_SOC_INTEL_DA7219_MAX98357A_GENERIC >> select SND_SOC_DMIC >> select SND_SOC_HDAC_HDMI >> >> +config SND_SOC_INTEL_DA7219_MAX98390_GENERIC >> + tristate >> + select SND_SOC_DA7219 >> + select SND_SOC_MAX98390 >> + select SND_SOC_DMIC >> + select SND_SOC_HDAC_HDMI >> + >> config SND_SOC_INTEL_BXT_DA7219_MAX98357A_COMMON >> tristate >> select SND_SOC_INTEL_DA7219_MAX98357A_GENERIC >> + select SND_SOC_INTEL_DA7219_MAX98390_GENERIC
this doesn't look too good, the only difference is the addition of MAX98090 which should be added in SND_SOC_INTEL_DA7219_MAX98357A_GENERIC above.
>> >> if SND_SOC_INTEL_APL >> >> @@ -309,6 +317,18 @@ config >> SND_SOC_INTEL_BXT_DA7219_MAX98357A_MACH >> Say Y or m if you have such a device. This is a recommended option. >> If unsure select "N". >> >> +config SND_SOC_INTEL_BXT_DA7219_MAX98390_MACH >> + tristate "Broxton with DA7219 and MAX98390 in I2S Mode" >> + depends on I2C && ACPI && GPIOLIB >> + depends on MFD_INTEL_LPSS || COMPILE_TEST >> + depends on SND_HDA_CODEC_HDMI >> + select SND_SOC_INTEL_BXT_DA7219_MAX98357A_COMMON >> + help >> + This adds support for ASoC machine driver for Broxton-P platforms >> + with DA7219 + MAX98390 I2S audio codec. >> + Say Y or m if you have such a device. This is a recommended option. >> + If unsure select "N". >> +
i don't think you need a different top-level config, just extend the existing one to say MAX98357A or MAX98390.
[...]
>> if (soc_intel_is_glk()) >> snd_soc_dapm_add_routes(&card->dapm, gemini_map, >> ARRAY_SIZE(gemini_map)); >> @@ -631,17 +719,17 @@ static int bxt_card_late_probe(struct snd_soc_card >> *card) >> component = pcm->codec_dai->component; >> snprintf(jack_name, sizeof(jack_name), >> "HDMI/DP, pcm=%d Jack", pcm->device); >> - err = snd_soc_card_jack_new(card, jack_name, >> + ret = snd_soc_card_jack_new(card, jack_name, >> SND_JACK_AVOUT, >> &broxton_hdmi[i], >> NULL, 0); >> >> - if (err) >> - return err; >> + if (ret) >> + return ret; >> >> - err = hdac_hdmi_jack_init(pcm->codec_dai, pcm->device, >> + ret = hdac_hdmi_jack_init(pcm->codec_dai, pcm->device, >> &broxton_hdmi[i]); >> - if (err < 0) >> - return err; >> + if (ret < 0) >> + return ret;
these look like unrelated changes?
>> --- a/sound/soc/intel/common/soc-acpi-intel-cml-match.c >> +++ b/sound/soc/intel/common/soc-acpi-intel-cml-match.c >> @@ -15,8 +15,8 @@ static struct snd_soc_acpi_codecs rt1011_spk_codecs = >> { }; >> >> static struct snd_soc_acpi_codecs max98357a_spk_codecs = { >> - .num_codecs = 1, >> - .codecs = {"MX98357A"} >> + .num_codecs = 2, >> + .codecs = {"MX98357A", "MX98390"}
That looks just wrong?
It would be really odd to list two devices as prerequisites for loading a driver, when in practice they are mutually exclusive? Something's broken in coreboot if both are present.
see below what we used for JSL:
see static struct snd_soc_acpi_codecs jsl_7219_98373_codecs = { .num_codecs = 1, .codecs = {"MX98373"} };
static struct snd_soc_acpi_codecs mx98360a_spk = { .num_codecs = 1, .codecs = {"MX98360A"} };
| |