On Wed, Mar 22, 2023 at 12:17:24AM +0200, Marian Postevca wrote: > Mark Brown writes: > >> + if (SND_SOC_DAPM_EVENT_ON(event)) > >> + acp3x_es83xx_set_gpios_values(priv, 1, 0); > >> + else > >> + acp3x_es83xx_set_gpios_values(priv, 0, 1); > > Why are these two GPIOs tied together like this? > These GPIOs represent the speaker and the headphone switches. When > activating the speaker GPIO you have to deactivate the headphone GPIO > and vice versa. The logic is taken from the discussion on the sofproject > pull request: > https://github.com/thesofproject/linux/pull/4112/commits/810d03e0aecdf0caf580a5179ee6873fb33485ab > and > https://github.com/thesofproject/linux/pull/4066 Sure, but that doesn't answer the question. What is the reason they're tied together - what if someone wants to play back from both speaker and headphones simultaneously? > >> +static int acp3x_es83xx_suspend_pre(struct snd_soc_card *card) > >> +{ > >> + struct acp3x_es83xx_private *priv = get_mach_priv(card); > >> + > >> + dev_dbg(priv->codec_dev, "card suspend\n"); > >> + snd_soc_component_set_jack(priv->codec, NULL, NULL); > >> + return 0; > >> +} > > That's weird, why do that? > This is needed because if suspending the laptop with the headphones > inserted, when resuming, the sound is not working anymore. Sound stops > working on speakers and headphones. Reinsertion and removals of the > headphone doesn't solve the problem. > This seems to be caused by the fact > that the GPIO IRQ stops working in es8316_irq() after resume. That's a bug that should be fixed.