Re: [PATCH] ASoC: nau8315: add codec driver

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

>>> +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.