On Wed, Nov 4, 2020 at 10:51 PM Pierre-Louis Bossart
<pierre-louis.bossart@xxxxxxxxxxxxxxx> wrote:
> 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.
We have a platform that max98357a shares the I2S with another codec.
The software control here is for separating them. See the commit
message of 128f825aeab79 ("ASoC: max98357a: move control of SD_MODE to
DAPM") for more details.
> 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?
There was a report for max98357a pop noise on rk3399-gru-kevin due to
commit 128f825aeab79. Commit 04a646ff5acaa ("ASoC: max98357a: move
control of SD_MODE back to DAI ops") fixes it. See
https://patchwork.kernel.org/project/alsa-devel/patch/20200721114232.2812254-1-tzungbi@xxxxxxxxxx/#23502085.
There is no reason for the asymmetric POST_PMU/POST_PMD here. You
should find that the sdmode_switch doesn't take effect immediately in
the DAPM event. I guess I was trying something (e.g. turning on/off
when the stream is opening) but failed. And I probably forgot to
recover the DAPM events back to symmetric (to avoid confusing people).
If nau8315 doesn't share I2S with other components for now, it could
be better to not introduce the software mute control.
