Message ID | 20221213095328.122309-2-r.czerwinski@pengutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:e747:0:0:0:0:0 with SMTP id c7csp20693wrn; Tue, 13 Dec 2022 01:59:14 -0800 (PST) X-Google-Smtp-Source: AA0mqf5K200+0pzeNNBRVxHScEZM3+QqyQAoYFcjsRIl7iwaKBQnSX1aPIxbEn0cDTXJIO5/2CEJ X-Received: by 2002:a05:6a20:4494:b0:ad:87b4:948e with SMTP id co20-20020a056a20449400b000ad87b4948emr9385038pzb.12.1670925553859; Tue, 13 Dec 2022 01:59:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670925553; cv=none; d=google.com; s=arc-20160816; b=1GnQ1V+8tZ8WlvXJQJjtHqyvRYJ+UOtN+hQ+YKakyIFX48AluTJDl4EsZD6gt8P+/F jkhfqlXJWp7TkGt3K3jOlxqsIOpYwBguaFrUr5jSkoF1VC2JxcA9doaDLtBiwGw+ojAT mqR+1DUs14VMJep3p6HL1WRJHlyeIcA97MIoO8/COBfOyU0r0wLexn3uj32YOLdjPW1X Gp7uuMGnDfjgHp7B5YH1Ih65dpoC1o/NIVA43iWDTp7kDkOOQO65sUxSmfaKQ734lPUV r64CeGSOIHjtzq0J8oePqtzEao+Wp7cUqz0sEP5XGVAphe3v1N5h7xj5NTC55iIG9Pc3 RRNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=KRfvqRDPx+TVYL2sSCV7zFCOI8sqtgnbgArOfzCKqUo=; b=KErvLpQ1l977iWokj01SBvpCLVdQ2mTUI4eC0vwpat6xi8HpgPeaVk7Wy8n5zRKboc 3VkgcBo5pxjQnkFd5i+OZWQx28uKY7SoA5CLEcbWU0ry6ULZIGTvPK/q2KW0PPpgvtbb 2nU3gTINTbWskWyHKkVIyJck/qxIgK/pR8X/ShQqeC/wrLv6gfWox30paH2V3L+0jhrp lAwGLDWixZC5AZNvsT0dgYaMA9PDjHdT425MA/lVgS7BWK7B21ASrJ7Rhn7axKMSAAXl l5EKADbFR36gYXbAnyePTuUZ/5zmk92yjLsZVb4NLqb0HI+465uV7ymad3h+RMY8rkId yx2w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u14-20020a63790e000000b004790794f259si12420146pgc.739.2022.12.13.01.58.58; Tue, 13 Dec 2022 01:59:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235014AbiLMJxo (ORCPT <rfc822;jeantsuru.cumc.mandola@gmail.com> + 99 others); Tue, 13 Dec 2022 04:53:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234982AbiLMJxm (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 13 Dec 2022 04:53:42 -0500 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 530AB2604 for <linux-kernel@vger.kernel.org>; Tue, 13 Dec 2022 01:53:41 -0800 (PST) Received: from ptz.office.stw.pengutronix.de ([2a0a:edc0:0:900:1d::77] helo=localhost) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <r.czerwinski@pengutronix.de>) id 1p51yd-0000ec-M5; Tue, 13 Dec 2022 10:53:31 +0100 From: Rouven Czerwinski <r.czerwinski@pengutronix.de> To: Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com> Cc: kernel@pengutronix.de, Marco Felsch <m.felsch@pengutronix.de>, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/2] ASoC: max98088: fix initial dai mute state Date: Tue, 13 Dec 2022 10:53:28 +0100 Message-Id: <20221213095328.122309-2-r.czerwinski@pengutronix.de> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221213095328.122309-1-r.czerwinski@pengutronix.de> References: <20221213095328.122309-1-r.czerwinski@pengutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2a0a:edc0:0:900:1d::77 X-SA-Exim-Mail-From: r.czerwinski@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1752092433732371738?= X-GMAIL-MSGID: =?utf-8?q?1752092433732371738?= |
Series |
[1/2] ASoC: max98088: fix dai1/2_hw_params access
|
|
Commit Message
Rouven Czerwinski
Dec. 13, 2022, 9:53 a.m. UTC
From: Marco Felsch <m.felsch@pengutronix.de> According the datasheets [1], [2] the initial value of register 0x2f/0x31 (dai1/dai2) is 0x00 which means that dai is unmuted. So upon the first playback request the register is not touched since it is cached by regmap. But the device output keeps silent. After ending the playback session the mute() callback updates the register. Now the 2nd playback request updates the register again (-> unmute the device) and now we can really hear the output signal. I've checked the register initial value which is '0x00' so the driver is correct. Accroding the above inspections it seems that the hardware does not update the register correctly on power up because the output is muted. To fix that we need to explicit set the mute state. Now the first playback request gets played correctly. [1] https://datasheets.maximintegrated.com/en/ds/MAX98089.pdf [2] https://datasheets.maximintegrated.com/en/ds/MAX98088.pdf Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> --- sound/soc/codecs/max98088.c | 5 +++++ 1 file changed, 5 insertions(+)
Comments
On Tue, Dec 13, 2022 at 10:53:28AM +0100, Rouven Czerwinski wrote: > To fix that we need to explicit set the mute state. Now the first > playback request gets played correctly. > +++ b/sound/soc/codecs/max98088.c > @@ -1710,6 +1710,11 @@ static int max98088_probe(struct snd_soc_component *component) > snd_soc_component_write(component, M98088_REG_1E_DAI2_IOCFG, > M98088_S2NORMAL|M98088_SDATA); > > + snd_soc_component_update_bits(component, M98088_REG_2F_LVL_DAI1_PLAY, > + M98088_DAI_MUTE_MASK, M98088_DAI_MUTE); > + snd_soc_component_update_bits(component, M98088_REG_31_LVL_DAI2_PLAY, > + M98088_DAI_MUTE_MASK, M98088_DAI_MUTE); > + Won't this be broken again after suspend? The device gets powered off over suspend, then when it powers on again with the output unmuted nothing will do another write since the register is already in the state in the cache.
Hi Mark, On 22-12-13, Mark Brown wrote: > On Tue, Dec 13, 2022 at 10:53:28AM +0100, Rouven Czerwinski wrote: > > > To fix that we need to explicit set the mute state. Now the first > > playback request gets played correctly. > > > +++ b/sound/soc/codecs/max98088.c > > @@ -1710,6 +1710,11 @@ static int max98088_probe(struct snd_soc_component *component) > > snd_soc_component_write(component, M98088_REG_1E_DAI2_IOCFG, > > M98088_S2NORMAL|M98088_SDATA); > > > > + snd_soc_component_update_bits(component, M98088_REG_2F_LVL_DAI1_PLAY, > > + M98088_DAI_MUTE_MASK, M98088_DAI_MUTE); > > + snd_soc_component_update_bits(component, M98088_REG_31_LVL_DAI2_PLAY, > > + M98088_DAI_MUTE_MASK, M98088_DAI_MUTE); > > + > > Won't this be broken again after suspend? The device gets powered off > over suspend, then when it powers on again with the output unmuted > nothing will do another write since the register is already in the state > in the cache. I didn't found any suspend logic within the driver. Is this handled within the ASoC core? Regards, Marco
On Thu, Dec 15, 2022 at 10:17:47AM +0100, Marco Felsch wrote: > On 22-12-13, Mark Brown wrote: > > > + snd_soc_component_update_bits(component, M98088_REG_2F_LVL_DAI1_PLAY, > > > + M98088_DAI_MUTE_MASK, M98088_DAI_MUTE); > > > + snd_soc_component_update_bits(component, M98088_REG_31_LVL_DAI2_PLAY, > > > + M98088_DAI_MUTE_MASK, M98088_DAI_MUTE); > > > + > > Won't this be broken again after suspend? The device gets powered off > > over suspend, then when it powers on again with the output unmuted > > nothing will do another write since the register is already in the state > > in the cache. > I didn't found any suspend logic within the driver. Is this handled > within the ASoC core? Register save and restore for the device won't be.
diff --git a/sound/soc/codecs/max98088.c b/sound/soc/codecs/max98088.c index 7f108e147355..c00d7726ac04 100644 --- a/sound/soc/codecs/max98088.c +++ b/sound/soc/codecs/max98088.c @@ -1710,6 +1710,11 @@ static int max98088_probe(struct snd_soc_component *component) snd_soc_component_write(component, M98088_REG_1E_DAI2_IOCFG, M98088_S2NORMAL|M98088_SDATA); + snd_soc_component_update_bits(component, M98088_REG_2F_LVL_DAI1_PLAY, + M98088_DAI_MUTE_MASK, M98088_DAI_MUTE); + snd_soc_component_update_bits(component, M98088_REG_31_LVL_DAI2_PLAY, + M98088_DAI_MUTE_MASK, M98088_DAI_MUTE); + max98088_handle_pdata(component); err_access: