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 14EEBC4332F for ; Mon, 19 Dec 2022 09:59:47 +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 41E652BE3; Mon, 19 Dec 2022 10:58:55 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 41E652BE3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1671443985; bh=LuxpFvZjSTMr36mVDWKrbtdysi8eAy7lEgCJYNJe6tk=; h=Date:From:To:Subject:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=W7s65Y8BJwdaLwj58obUT0LzaBVhDxnbmyeRl577Y3I3SYjBV0Hiwed7p96Gy/0WG 9TbwuFIXj6xP94hzgKDjNfDPxVHMtMO69ibT5gJIAM9Dbn7fuPgosh3whWUBiwl3++ 0dUIRcJO+Pt+3V9VQxENAOXdQW4agXeQP0hkHigI= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id F2288F8026D; Mon, 19 Dec 2022 10:58:54 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id BBC50F80423; Mon, 19 Dec 2022 10:58:53 +0100 (CET) Received: from mx0b-001ae601.pphosted.com (mx0a-001ae601.pphosted.com [67.231.149.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id B57CFF801C0 for ; Mon, 19 Dec 2022 10:58:51 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz B57CFF801C0 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=cirrus.com header.i=@cirrus.com header.a=rsa-sha256 header.s=PODMain02222019 header.b=lCgUmekZ Received: from pps.filterd (m0077473.ppops.net [127.0.0.1]) by mx0a-001ae601.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BJ7OmV6029670; Mon, 19 Dec 2022 03:58:49 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cirrus.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=PODMain02222019; bh=qXn/bJV1DX5QQQ9G3avNSKeTDlziEr16YH3fTzCVmIg=; b=lCgUmekZ8Go6Oej13PwBEjN1f48hAg+41nqr5klOnUgs92E4NiOY+zSF7kXRXO9BKw2k /Bx8Wpnzgm7d08bT2JdWDgbka25WesZQwjSGA1Y59Q2oa33XnAKGEIme+cimfDbWBLG/ j9LtbestVBlhIolMLIjpqOgAq5zFYtrRFhfDWkOfrnYQk2Wnq3IsCXMxDVcP/wvJcMWv cpuaRxx2vdI/grxrZciBjrqPuugiLbJL4l0WaGkcHhOBpftGzVNNPNO6BWCUJr6/H99t VF8FMOqqcvhTeC+U6LIzZll4RlU7l8CBo4nsKCQ57GPIYnEoqLNpavhqxGc+5yrI1DFn ww== Received: from ediex02.ad.cirrus.com ([84.19.233.68]) by mx0a-001ae601.pphosted.com (PPS) with ESMTPS id 3mhc27ae08-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Dec 2022 03:58:48 -0600 Received: from ediex01.ad.cirrus.com (198.61.84.80) by ediex02.ad.cirrus.com (198.61.84.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.20; Mon, 19 Dec 2022 03:58:46 -0600 Received: from ediswmail.ad.cirrus.com (198.61.86.93) by ediex01.ad.cirrus.com (198.61.84.80) with Microsoft SMTP Server id 15.2.1118.20 via Frontend Transport; Mon, 19 Dec 2022 03:58:46 -0600 Received: from ediswmail.ad.cirrus.com (ediswmail.ad.cirrus.com [198.61.86.93]) by ediswmail.ad.cirrus.com (Postfix) with ESMTP id B04B111CC; Mon, 19 Dec 2022 09:58:46 +0000 (UTC) Date: Mon, 19 Dec 2022 09:58:46 +0000 From: Charles Keepax To: Emanuele Ghidoli Subject: Re: wm8904 and output volume control Message-ID: <20221219095846.GC36097@ediswmail.ad.cirrus.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Proofpoint-ORIG-GUID: O3kkblowbZYisSbfE3cfMjGMtDzpqrnu X-Proofpoint-GUID: O3kkblowbZYisSbfE3cfMjGMtDzpqrnu X-Proofpoint-Spam-Reason: safe X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, Liam Girdwood , Takashi Iwai , Michael Walle , Mark Brown , Francesco Dolcini , emanuele.ghidoli@toradex.com Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Sat, Dec 17, 2022 at 12:47:14AM +0100, Emanuele Ghidoli wrote: > Hello, > I have found that output volume is set to the default value after a > limited time (~4 seconds) after play stop. > I have analyzed what is happening: > - at first play the volume is the expected one > - After stopping playing + ~4 seconds wm8904_set_bias_level (..., > SND_SOC_BIAS_OFF) is called > - Chip is reset and regulator is switched off if "possible" (not in > our case, it is important to note) > - at second play wm8904_set_bias_level (..., SND_SOC_BIAS_STANDBY) > is called. wm8904_hw_params is also called just before. > > I see that all I2C transactions are good, registers are written as > expected, especially volume control register (even the silly > HPOUT_VU bit, to do a volume update is correctly written). > Reading out this register, using i2cget (bypassing regcache), report > the "expected" value. But the real output volume correspond to the > default value (hw default, that it is the same value in > wm8904_reg_defaults structure). > > I checked that SYSCLK_ENA is 0 during register writing (needed if > MCLK/SYSCLK is not present). I do not know if there is some other > constrain on these registers. > Yes this might be my guess as well, I wonder if the HPOUT_VU bit needs SYSCLK to be present to take effect. > If I rewrite the volume control register, a second time, the volume > is set (tested with i2cset, from user space. And from kernel space, > bypassing regcache). > When you write the value the second time is that still before SYSCLK is present? Also does just writing one of HPOUT volumes cause the other to get updated? The HPOUT_VU bit should trigger an update to both. > I resolve also by reverting e9149b8c00d2 ("ASoC: wm8904: fix > regcache handling"). > I'm not here to say that the commit is wrong. I analyzed it and seem > perfect (in few words it align the hw with the regcache avoiding > potential incoherence). > Yeah I think that commit is fine, I would wager that your system doesn't turn off the regulators so without that commit the register retains the old volume across the "power down". Thanks, Charles