From patchwork Fri Apr 14 14:01:59 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Pawe=C5=82_Anikiel?= X-Patchwork-Id: 13212364 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 DE491C77B71 for ; Sat, 15 Apr 2023 09:12:44 +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 8DB2AA4B; Sat, 15 Apr 2023 11:11:52 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 8DB2AA4B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1681549962; bh=AXUIMngCzsxNiINJkXbWpCesvLoamuuHv6HjOcT+zX4=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Reply-To:Cc:From; b=hibTOBxxrbcjBjY24jWsiLw0EpwfjeP8YldCWxmed//XdLmtkxk578zQ4QGwcZ9Yg 6jIKnLh/+fInqaN9XFHDpwQcGUrwWbylTeGV8iWBcr9xwVI1MRg6l/rg4+k4TvkTSN BBPXPSk+nByC5BcQgKMROzfYP8tha2EH6dWMl9U0= Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id DA27FF80564; Sat, 15 Apr 2023 11:09:34 +0200 (CEST) To: alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, lgirdwood@gmail.com, broonie@kernel.org Subject: [PATCH 5/9] ASoC: ssm2602: Add workaround for playback with external MCLK Date: Fri, 14 Apr 2023 16:01:59 +0200 In-Reply-To: <20230414140203.707729-1-pan@semihalf.com> References: <20230414140203.707729-1-pan@semihalf.com> X-Mailman-Rule-Hits: nonmember-moderation 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 X-Mailman-Approved-At: Sat, 15 Apr 2023 09:08:58 +0000 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: MIME-Version: 1.0 Message-ID: <168154977392.26.12888416405257429334@mailman-core.alsa-project.org> X-Patchwork-Original-From: =?utf-8?q?Pawe=C5=82_Anikiel_via_Alsa-devel?= From: =?utf-8?q?Pawe=C5=82_Anikiel?= Reply-To: =?utf-8?q?Pawe=C5=82_Anikiel?= Cc: tiwai@suse.com, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, dinguyen@kernel.org, lars@metafoo.de, nuno.sa@analog.com, upstream@semihalf.com, =?utf-8?q?Pawe=C5=82_Anikiel?= Content-Disposition: inline Apply a workaround for what seems to be a hardware quirk: when using an external MCLK signal, powering on Output and DAC for the first time produces output distortions unless they're powered together with whole chip power. The workaround powers them on in probe for the first time, as doing it later may be impossible (e.g. when starting playback while recording, whole chip power will already be on). Here are some initialization sequences run after all other control registers were set (`ssmset reg val` sets the value of a register via i2c): ssmset 0x09 0x01 # core ssmset 0x06 0x07 # chip, out OK ssmset 0x09 0x01 # core ssmset 0x06 0x87 # out, dac ssmset 0x06 0x07 # chip OK (disable MCLK) ssmset 0x09 0x01 # core ssmset 0x06 0x1f # chip ssmset 0x06 0x07 # out, dac (enable MCLK) OK ssmset 0x09 0x01 # core ssmset 0x06 0x1f # chip ssmset 0x06 0x07 # out, dac NOT OK ssmset 0x06 0x1f # chip ssmset 0x09 0x01 # core ssmset 0x06 0x07 # out, dac NOT OK ssmset 0x09 0x01 # core ssmset 0x06 0x0f # chip, out ssmset 0x06 0x07 # dac NOT OK ssmset 0x09 0x01 # core ssmset 0x06 0x17 # chip, dac ssmset 0x06 0x07 # out NOT OK Here are some sequences run at the very start before a sw reset (and later using one of the NOT OK sequences from above): ssmset 0x09 0x01 # core ssmset 0x06 0x07 # chip, out, dac OK (disable MCLK) ssmset 0x09 0x01 # core ssmset 0x06 0x07 # chip, out, dac (enable MCLK after reset) NOT OK ssmset 0x09 0x01 # core ssmset 0x06 0x17 # chip, dac NOT OK ssmset 0x09 0x01 # core ssmset 0x06 0x0f # chip, out NOT OK ssmset 0x06 0x07 # chip, out, dac NOT OK This was tested on a Google Chameleon v3 board using an SSM2603 with an external MCLK. This doesn't seem to just be a PCB issue, as this was also observed on a ZYBO Z7-10: https://ez.analog.com/audio/f/q-a/543726/solved-ssm2603-right-output-offset-issue/480229 Signed-off-by: Paweł Anikiel --- sound/soc/codecs/ssm2602.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/sound/soc/codecs/ssm2602.c b/sound/soc/codecs/ssm2602.c index cbbe83b85ada..021e0c860fa1 100644 --- a/sound/soc/codecs/ssm2602.c +++ b/sound/soc/codecs/ssm2602.c @@ -589,6 +589,17 @@ static int ssm260x_component_probe(struct snd_soc_component *component) return ret; } + /* Workaround for what seems to be a hardware quirk: when using an + * external MCLK signal, powering on Output and DAC for the first + * time produces output distortions unless they're powered together + * with whole chip power. We power them here for the first time, + * as doing it later may be impossible (e.g. when starting playback + * while recording, whole chip power will already be on) + */ + regmap_write(ssm2602->regmap, SSM2602_ACTIVE, 0x01); + regmap_write(ssm2602->regmap, SSM2602_PWR, 0x07); + regmap_write(ssm2602->regmap, SSM2602_RESET, 0x00); + /* set the update bits */ regmap_update_bits(ssm2602->regmap, SSM2602_LINVOL, LINVOL_LRIN_BOTH, LINVOL_LRIN_BOTH);