From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 10B7CC6FD1F for ; Wed, 22 Mar 2023 20:49:56 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 04067F10; Wed, 22 Mar 2023 21:49:04 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 04067F10 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1679518194; bh=UGI4wuqk28si00gqCk+pXZy1oVhNUVal257IJk22lcA=; h=From:To:Subject:In-Reply-To:References:Date:CC:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=fdjWqSulQB6/QZD0STFcT9NRH/DFN2BZuqUub4VYJZ2ELdLbB4NbkY5AQ6BYJmtjm khXVV2rmjE6ivBudgvGPrLuwX+GV7zkfREmtXYwHI8X114xc0kWu0yBy1VibydLVRV oMa7Wpqg965blfyt/5OTMe6UV90o1Yb+/XJll2gw= Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id A414CF8027B; Wed, 22 Mar 2023 21:48:41 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 31057F8027B; Wed, 22 Mar 2023 21:48:38 +0100 (CET) Received: from mail.mutex.one (mail.mutex.one [62.77.152.124]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 6B246F80105 for ; Wed, 22 Mar 2023 21:48:33 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 6B246F80105 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key, unprotected) header.d=mutex.one header.i=@mutex.one header.a=rsa-sha256 header.s=default header.b=NMckDuv5 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.mutex.one (Postfix) with ESMTP id 6BD4616C0008; Wed, 22 Mar 2023 22:48:32 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at mail.mutex.one Received: from mail.mutex.one ([127.0.0.1]) by localhost (mail.mutex.one [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D_69F_8jHUO; Wed, 22 Mar 2023 22:48:31 +0200 (EET) From: Marian Postevca DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mutex.one; s=default; t=1679518111; bh=UGI4wuqk28si00gqCk+pXZy1oVhNUVal257IJk22lcA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NMckDuv5o61W0GTAMnDxZYomYSjRDvNjw2n9tfnDDAipdtO80UIWbF8O6iq+58nl5 fCy4eAxEWvy3bgxhjzzyZIE4/SKKpQ6F1XvSAHs2/wVoORoUGR/XK+vYiA65Igati2 XR3es+DN0t0kKnjmLkUiDN+OBObA4KNmfyoe8BPI= To: Mark Brown , =?utf-8?B?5rKI5LiA6LaF?= , yangxiaohua , Zhu Ning Subject: Re: [PATCH 3/4] ASoC: amd: acp: Add machine driver that enables sound for systems with a ES8336 codec In-Reply-To: References: <20230320203519.20137-1-posteuca@mutex.one> <20230320203519.20137-4-posteuca@mutex.one> <141a3320-ff65-459f-9d00-c8bed691dcfc@sirena.org.uk> <87lejpwxzf.fsf@mutex.one> Date: Wed, 22 Mar 2023 22:48:28 +0200 Message-ID: <87ttycjyw3.fsf@mutex.one> MIME-Version: 1.0 Content-Type: text/plain Message-ID-Hash: I7K4JZMGM655SLF2ZGXEXIZ4CK5Y2ZPY X-Message-ID-Hash: I7K4JZMGM655SLF2ZGXEXIZ4CK5Y2ZPY X-MailFrom: posteuca@mutex.one X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-alsa-devel.alsa-project.org-0; header-match-alsa-devel.alsa-project.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Takashi Iwai , Liam Girdwood , linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org X-Mailman-Version: 3.3.8 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Mark Brown writes: > 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? > The GPIO handling is not documented in the codec datasheet, so I constructed this logic by looking at the existing implementations of machine drivers for this codec (sof_es8336.c, bytcht_es8316.c) and comments of Everest Semiconductor engineers on the sofproject pull requests. I'm saying all of this because I don't know the reasons why these GPIOs work the way they do. According to the Everest Semiconductor engineers this is the recommended way to switch these GPIOs: +--------------+--------------+----------------+ | | Speaker GPIO | Headphone GPIO | +--------------+--------------+----------------+ | Speaker on | active | inactive | | Headphone on | inactive | active | | Suspended | inactive | inactive | +--------------+--------------+----------------+ (https://github.com/thesofproject/linux/pull/4066/commits/b7f12e46a36b74a9992920154a65cd55f5b0cdb4#r1041693056) This lockstep between these two GPIOs can be seen in sof_es8336.c in pcm_pop_work_events() too. Regarding playing the speaker and headphone simultaneously, is not something I took into account. Is this even a valid usecase? The intel driver for es8336 doesn't seem to support it. Maybe someone from Everest Semiconductor can comment on this GPIO handling? >> >> +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. Agreed, but I don't know how easy it is to fix, and I would like to first offer users of these laptops a working sound driver. Afterwards this issue can be analyzed and properly fixed.