[PATCH] ASoC: nau8315: add codec driver
Pierre-Louis Bossart
pierre-louis.bossart at linux.intel.com
Wed Nov 4 15:51:08 CET 2020
>>> +static int nau8315_enpin_event(struct snd_soc_dapm_widget *w,
>>> + struct snd_kcontrol *kcontrol, int event)
>>> +{
>>> + struct snd_soc_component *component =
>>> + snd_soc_dapm_to_component(w->dapm);
>>> + struct nau8315_priv *nau8315 =
>>> + snd_soc_component_get_drvdata(component);
>>> +
>>
>> [1]
>>
>>> + if (event & SND_SOC_DAPM_POST_PMU)
>>> + nau8315->enpin_switch = 1;
>>> + else if (event & SND_SOC_DAPM_POST_PMD)
>>> + nau8315->enpin_switch = 0;
>>
>> And even if this variable was useful, for symmetry should it be
>> PRE_PMU/POST_PMD?
>>
> Yes, I agree with your opinion.
>
> From the above description, I suppose you might want to point whether
> the dapm widget of EN_PIN is redundant, right? That's a reason the
> physical hardware pin is set to high/low in trigger function point of
> snd_soc_dai_ops, it always occurred after dapm event.
> If yes, from my current platform of verification, even if the dapm
> widget of EN_PIN is removed, the result of sound output is same yet.
> Maybe the first version, I should submit a simpler version.
The model from the Max98357a seems to come from 128f825aeab79 ('
ASoC: max98357a: move control of SD_MODE to DAPM')
It doesn't seem like this additional EN_PIN is useful at the codec level
but may help with machine integration.
I still don't get the POST_PMU/POST_PMD. This was changed in
04a646ff5acaa by Tzung-Bi Shih @ Google, wondering if there is an
explanation?
Not pushing back, just trying to get what makes sense for amplifiers.
More information about the Alsa-devel
mailing list