lkml.org 
[lkml]   [2020]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] ASoC: Intel: bxt-da7219-max98357a: support MAX98390 speaker amp
From
Date

>> 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"}
};

\
 
 \ /
  Last update: 2020-06-30 19:27    [W:0.053 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site