On Wed, Nov 4, 2020 at 10:51 PM Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com 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....
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.