Message ID | 20230705125723.40464-1-srinivas.kandagatla@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f45:0:b0:3ea:f831:8777 with SMTP id v5csp1853250vqx; Wed, 5 Jul 2023 06:05:45 -0700 (PDT) X-Google-Smtp-Source: APBJJlHo6igpdPgYkJgdOIO2giVT/owDHwHBpOmHOMLdj8i6REP2mTGgMvU5iMAUhIz6LbsAB+R4 X-Received: by 2002:a17:90a:a8f:b0:260:fe48:491f with SMTP id 15-20020a17090a0a8f00b00260fe48491fmr12547291pjw.45.1688562345318; Wed, 05 Jul 2023 06:05:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688562345; cv=none; d=google.com; s=arc-20160816; b=Q9mnymicmpyc0Gbo91nkKhKrP6mP2GMoN3V0olIYRG+KVMsfH7UjysKCSe4SOq6/tl KMYabNn7fJs9RVokciC0wGA5SYcfSt+htVkZ3nUnP/e8Jcx3FDKPje/ujMX5ARSDXu5P 5rvprah7tUX5v9dBJu/Zydxo7me1VGUrKkeEiZwz29IEqkRzfLDmOqjxfP7jIOIG/8KS SkDJuEDYp4QFnAWbMl1D96RgaSxXjYlLy1HUBzO5i18e/HEGnXkBlSfIxzRu+BjRXtNG ZJ3fnx5ODNZzU/fOuOiuae1RpAdisT790mqAwztxIvwNPnEp9WfiuE8vCUO3msYOO5Q8 k6FA== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=xhg4Btd/0KybnmhVesqfMosrv9Aez9Q8GYSJ7Z38kYc=; fh=tpU9CJxuaUNNFBscRgb2MScY0Si+Z89S9iWbqTFwq2o=; b=C2PI9evv2aJaeEGa/UwEGEa5GngshMc80lIwYO504Vgn77jpsZduAthKP02wbZHMHh rHkqKZWO/X6GT+BJJwpIVkPFPY7YteQGmIceIXaJ+I7Y2mXlN3um5Z0Md8c8RVR8rB0L J+oMtwBKWp7+xrxxrKCIDe99hgkqxres6udgK38gtuvFIDD1OciF4rRdzUWRFOahRZi0 IyVwQzFON7FeYGvDwfviKYom9HYOIPuxbnrKTDr+88LmNUc6/uwrsxHZNd/Nby9Cd1nf 748X3hJLI6eMS3Mu3h/aCUcOSsjDOuIEYUnSQ+LAbe5OYBZRKBQs5brEW+A5a70v3Bkx WzJg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Npwz7cfc; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id li11-20020a170903294b00b001b890417a0bsi7361872plb.410.2023.07.05.06.05.32; Wed, 05 Jul 2023 06:05:45 -0700 (PDT) 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; dkim=pass header.i=@linaro.org header.s=google header.b=Npwz7cfc; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232033AbjGEM53 (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Wed, 5 Jul 2023 08:57:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55476 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231154AbjGEM52 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 5 Jul 2023 08:57:28 -0400 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E17D610F5 for <linux-kernel@vger.kernel.org>; Wed, 5 Jul 2023 05:57:27 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-3fbc5d5742bso67805565e9.2 for <linux-kernel@vger.kernel.org>; Wed, 05 Jul 2023 05:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1688561846; x=1691153846; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=xhg4Btd/0KybnmhVesqfMosrv9Aez9Q8GYSJ7Z38kYc=; b=Npwz7cfcZgmC0s2V6ezJBOFdy4P05NRAP4wOB0hnf08Cx3+flkWy/1N5uEYlx3AXT1 3paPunOjWfJO30Lvj/A4owjC32Jk4fMUQ5FKxtW/43Y9yPSva/2jwLRFy/uKgDNvvCre D6Oebsi5p9u9DATB8WMm+4OCKjoSvZLkASmtEgaVykWt6yPublzxBxL9g/72jY8nPq4/ uO+IqlKDtL8VO4AWCiGie2dpM/JHRH2HHcpEgrySVWCs6JylK/crCzIcJIxP7/WKbpXM +v/BFUHKADoIbw5JNt+9pU2HR/yhDScol9ZBRHFfuk/KaF8/VjG7UBdtr2KJsw3lq4Ya HlzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688561846; x=1691153846; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xhg4Btd/0KybnmhVesqfMosrv9Aez9Q8GYSJ7Z38kYc=; b=HKL7/8XlI4ivOjzYS80LHUUiY5KRVgLVwOX949k76vPPWmB5o7tFadt1/NaKC63hbD Ftc0rRTgnwCMr74zywDtt2BXKC3zLwmxlbfoD51oEkxc7iFKAtEnmeTZz3QAYaWj1uA3 VdpoXoLbHQXrJxnn7h4ZjFXPl2vqDPykTCZWRHj7grkV8N7NtQpjhPX+lPFFHDI89dKn so0RpiaAgvHmrvmJXjU4IdbszfikwoKIIy0wfl8xkmOZMfAQil8BIBD+JnFEsq4aD0c6 YZGsen4KD9Dkc9OWfngEwEO5gJJ0JkmgNJu8SM3BGX47bYNoU+EeSi/WkobZRawv+xT5 vNJw== X-Gm-Message-State: AC+VfDzcxiCKDNSvkm/LFVPlw5Q5W5mWq26vZcn/W2Eix/Knd/KuQbkh t9j0nTTY7xBhDSm0EtslHehkLg== X-Received: by 2002:a1c:7903:0:b0:3fa:c3e8:901a with SMTP id l3-20020a1c7903000000b003fac3e8901amr13883895wme.25.1688561846413; Wed, 05 Jul 2023 05:57:26 -0700 (PDT) Received: from localhost.localdomain ([5.133.47.210]) by smtp.gmail.com with ESMTPSA id y6-20020a7bcd86000000b003fbb346279dsm2100555wmj.38.2023.07.05.05.57.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Jul 2023 05:57:25 -0700 (PDT) From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> To: broonie@kernel.org Cc: perex@perex.cz, tiwai@suse.com, lgirdwood@gmail.com, ckeepax@opensource.cirrus.com, kuninori.morimoto.gx@renesas.com, linux-kernel@vger.kernel.org, pierre-louis.bossart@linux.intel.com, alsa-devel@alsa-project.org, Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Subject: [PATCH] ASoC: codecs: wcd938x: fix dB range for HPHL and HPHR Date: Wed, 5 Jul 2023 13:57:23 +0100 Message-Id: <20230705125723.40464-1-srinivas.kandagatla@linaro.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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?1770585949911851876?= X-GMAIL-MSGID: =?utf-8?q?1770585949911851876?= |
Series |
ASoC: codecs: wcd938x: fix dB range for HPHL and HPHR
|
|
Commit Message
Srinivas Kandagatla
July 5, 2023, 12:57 p.m. UTC
dB range for HPHL and HPHR gains are from +6dB to -30dB in steps of
1.5dB with register values range from 0 to 24.
Current code maps these dB ranges incorrectly, fix them to allow proper
volume setting.
Fixes: e8ba1e05bdc0("ASoC: codecs: wcd938x: add basic controls")
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
sound/soc/codecs/wcd938x.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Comments
On Wed, 05 Jul 2023 13:57:23 +0100, Srinivas Kandagatla wrote: > dB range for HPHL and HPHR gains are from +6dB to -30dB in steps of > 1.5dB with register values range from 0 to 24. > > Current code maps these dB ranges incorrectly, fix them to allow proper > volume setting. > > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: codecs: wcd938x: fix dB range for HPHL and HPHR commit: c03226ba15fe3c42d13907ec7d8536396602557b All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
On Wed, Jul 05, 2023 at 01:57:23PM +0100, Srinivas Kandagatla wrote: > dB range for HPHL and HPHR gains are from +6dB to -30dB in steps of > 1.5dB with register values range from 0 to 24. > > Current code maps these dB ranges incorrectly, fix them to allow proper > volume setting. > > Fixes: e8ba1e05bdc0("ASoC: codecs: wcd938x: add basic controls") > Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> > --- > sound/soc/codecs/wcd938x.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/sound/soc/codecs/wcd938x.c b/sound/soc/codecs/wcd938x.c > index faa15a5ed2c8..3a3360711f8f 100644 > --- a/sound/soc/codecs/wcd938x.c > +++ b/sound/soc/codecs/wcd938x.c > @@ -210,7 +210,7 @@ struct wcd938x_priv { > }; > > static const SNDRV_CTL_TLVD_DECLARE_DB_MINMAX(ear_pa_gain, 600, -1800); > -static const SNDRV_CTL_TLVD_DECLARE_DB_MINMAX(line_gain, 600, -3000); > +static const DECLARE_TLV_DB_SCALE(line_gain, -3000, 150, -3000); This looks wrong, and indeed that forth argument appears to be a mute flag. I guess that one should have been 0 (false) here? Headphone output also appears to be way too loud by default with this patch (alone) applied. Perhaps it's just the default mixer settings need to be updated to match? It looks like you're inverting the scale above. Perhaps that's intended, but some more details in the commit message as to what was wrong and what you intended to do would have been good. Johan
On Fri, Jul 07, 2023 at 09:35:44AM +0200, Johan Hovold wrote: > On Wed, Jul 05, 2023 at 01:57:23PM +0100, Srinivas Kandagatla wrote: > > +static const DECLARE_TLV_DB_SCALE(line_gain, -3000, 150, -3000); > This looks wrong, and indeed that forth argument appears to be a mute > flag. I guess that one should have been 0 (false) here? Yes, it is - it's for flagging if the lowest value is mute (many devices integrate mute into a volume control). > Headphone output also appears to be way too loud by default with this > patch (alone) applied. Perhaps it's just the default mixer settings need > to be updated to match? Some of the discussion on IRC suggested that this might be the case.
On 07/07/2023 08:35, Johan Hovold wrote: > On Wed, Jul 05, 2023 at 01:57:23PM +0100, Srinivas Kandagatla wrote: >> dB range for HPHL and HPHR gains are from +6dB to -30dB in steps of >> 1.5dB with register values range from 0 to 24. >> >> Current code maps these dB ranges incorrectly, fix them to allow proper >> volume setting. >> >> Fixes: e8ba1e05bdc0("ASoC: codecs: wcd938x: add basic controls") >> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> >> --- >> sound/soc/codecs/wcd938x.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/sound/soc/codecs/wcd938x.c b/sound/soc/codecs/wcd938x.c >> index faa15a5ed2c8..3a3360711f8f 100644 >> --- a/sound/soc/codecs/wcd938x.c >> +++ b/sound/soc/codecs/wcd938x.c >> @@ -210,7 +210,7 @@ struct wcd938x_priv { >> }; >> >> static const SNDRV_CTL_TLVD_DECLARE_DB_MINMAX(ear_pa_gain, 600, -1800); >> -static const SNDRV_CTL_TLVD_DECLARE_DB_MINMAX(line_gain, 600, -3000); >> +static const DECLARE_TLV_DB_SCALE(line_gain, -3000, 150, -3000); > > This looks wrong, and indeed that forth argument appears to be a mute > flag. I guess that one should have been 0 (false) here? yes, this should be true instead of a mute dB value. > > Headphone output also appears to be way too loud by default with this > patch (alone) applied. Perhaps it's just the default mixer settings need > to be updated to match? > > It looks like you're inverting the scale above. Perhaps that's intended, yes, the highest value corresponds to lowest dB which is why its inverted. > but some more details in the commit message as to what was wrong and > what you intended to do would have been good. HPHR/HPHL Volume control is broken on this codec. current UCM uses digital volume control for x13s which needs to be moved to Analog volume control. I have this change https://termbin.com/mpp9 in UCM which I plan to send out once I test and fix other paths as well. --srini > > Johan
On Fri, 07 Jul 2023 14:54:31 +0200, Srinivas Kandagatla wrote: > > On 07/07/2023 08:35, Johan Hovold wrote: > > On Wed, Jul 05, 2023 at 01:57:23PM +0100, Srinivas Kandagatla wrote: > >> dB range for HPHL and HPHR gains are from +6dB to -30dB in steps of > >> 1.5dB with register values range from 0 to 24. > >> > >> Current code maps these dB ranges incorrectly, fix them to allow proper > >> volume setting. > >> > >> Fixes: e8ba1e05bdc0("ASoC: codecs: wcd938x: add basic controls") > >> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> > >> --- > >> sound/soc/codecs/wcd938x.c | 6 +++--- > >> 1 file changed, 3 insertions(+), 3 deletions(-) > >> > >> diff --git a/sound/soc/codecs/wcd938x.c b/sound/soc/codecs/wcd938x.c > >> index faa15a5ed2c8..3a3360711f8f 100644 > >> --- a/sound/soc/codecs/wcd938x.c > >> +++ b/sound/soc/codecs/wcd938x.c > >> @@ -210,7 +210,7 @@ struct wcd938x_priv { > >> }; > >> static const SNDRV_CTL_TLVD_DECLARE_DB_MINMAX(ear_pa_gain, 600, > >> -1800); > >> -static const SNDRV_CTL_TLVD_DECLARE_DB_MINMAX(line_gain, 600, -3000); > >> +static const DECLARE_TLV_DB_SCALE(line_gain, -3000, 150, -3000); > > > > This looks wrong, and indeed that forth argument appears to be a mute > > flag. I guess that one should have been 0 (false) here? > > yes, this should be true instead of a mute dB value. > > > > > Headphone output also appears to be way too loud by default with this > > patch (alone) applied. Perhaps it's just the default mixer settings need > > to be updated to match? > > > > It looks like you're inverting the scale above. Perhaps that's intended, > > yes, the highest value corresponds to lowest dB which is why its inverted. Ouch, that's a bad design choice... Takashi
On Fri, Jul 07, 2023 at 03:20:10PM +0200, Takashi Iwai wrote: > Srinivas Kandagatla wrote: > > yes, the highest value corresponds to lowest dB which is why its inverted. > Ouch, that's a bad design choice... It's moderately common - typically in these cases the control is described in the datasheet as an attenuation control rather than a gain, and this usually corresponds to the physical implementation being only able to make signals smaller relative to the reference.
On Fri, 07 Jul 2023 15:22:45 +0200, Mark Brown wrote: > > On Fri, Jul 07, 2023 at 03:20:10PM +0200, Takashi Iwai wrote: > > Srinivas Kandagatla wrote: > > > > yes, the highest value corresponds to lowest dB which is why its inverted. > > > Ouch, that's a bad design choice... > > It's moderately common - typically in these cases the control is > described in the datasheet as an attenuation control rather than a gain, > and this usually corresponds to the physical implementation being only > able to make signals smaller relative to the reference. Yeah, I see the use case. The problem is, however, that we're using the very same dB info for both gain and attenuation. That means, application has no idea how to interpret those dB values -- to be added or to be subtracted. We should have defined a new TLV type for attenuation to differentiate, and define the TLV macro to give proper min/max. Takashi
On Fri, Jul 07, 2023 at 03:30:48PM +0200, Takashi Iwai wrote: > Mark Brown wrote: > > It's moderately common - typically in these cases the control is > > described in the datasheet as an attenuation control rather than a gain, > > and this usually corresponds to the physical implementation being only > > able to make signals smaller relative to the reference. > Yeah, I see the use case. The problem is, however, that we're using > the very same dB info for both gain and attenuation. That means, > application has no idea how to interpret those dB values -- to be > added or to be subtracted. > We should have defined a new TLV type for attenuation to > differentiate, and define the TLV macro to give proper min/max. The ASoC generic control stuff supports inverting the value prior to presentation to userspace so it's masked there (instead of writing the number userspace sees to the register we subtract the number from the maximum value and write that to the register), pulling that up further to the ALSA core might be nice I guess?
On Fri, Jul 07, 2023 at 01:54:31PM +0100, Srinivas Kandagatla wrote: > On 07/07/2023 08:35, Johan Hovold wrote: > > On Wed, Jul 05, 2023 at 01:57:23PM +0100, Srinivas Kandagatla wrote: > >> static const SNDRV_CTL_TLVD_DECLARE_DB_MINMAX(ear_pa_gain, 600, -1800); > >> -static const SNDRV_CTL_TLVD_DECLARE_DB_MINMAX(line_gain, 600, -3000); > >> +static const DECLARE_TLV_DB_SCALE(line_gain, -3000, 150, -3000); > > > > This looks wrong, and indeed that forth argument appears to be a mute > > flag. I guess that one should have been 0 (false) here? > > yes, this should be true instead of a mute dB value. Ok, so mute is supported. Then that argument can just be changed to "1" as a cleanup to follow the current convention. > > Headphone output also appears to be way too loud by default with this > > patch (alone) applied. Perhaps it's just the default mixer settings need > > to be updated to match? > > > > It looks like you're inverting the scale above. Perhaps that's intended, > > yes, the highest value corresponds to lowest dB which is why its inverted. Got it, thanks. > > but some more details in the commit message as to what was wrong and > > what you intended to do would have been good. > > HPHR/HPHL Volume control is broken on this codec. > current UCM uses digital volume control for x13s which needs to be moved > to Analog volume control. > I have this change https://termbin.com/mpp9 in UCM which I plan to send > out once I test and fix other paths as well. With those UCM changes the headphone volume appears to be restored even if pavucontrol now sets the "base" marker at 80% rather than 20% volume on the X13s (which is much too loud here). Audio quality seem fine and I'm not hearing any distortion at 20% volume as some people were complaining about (even if I haven't really used the headphones myself before). Sounds like you had a similar fix for the speaker distortion coming soon too, looking forward to that one. Johan
On Fri, 07 Jul 2023 15:35:29 +0200, Mark Brown wrote: > > On Fri, Jul 07, 2023 at 03:30:48PM +0200, Takashi Iwai wrote: > > Mark Brown wrote: > > > > It's moderately common - typically in these cases the control is > > > described in the datasheet as an attenuation control rather than a gain, > > > and this usually corresponds to the physical implementation being only > > > able to make signals smaller relative to the reference. > > > Yeah, I see the use case. The problem is, however, that we're using > > the very same dB info for both gain and attenuation. That means, > > application has no idea how to interpret those dB values -- to be > > added or to be subtracted. > > > We should have defined a new TLV type for attenuation to > > differentiate, and define the TLV macro to give proper min/max. > > The ASoC generic control stuff supports inverting the value prior to > presentation to userspace so it's masked there (instead of writing the > number userspace sees to the register we subtract the number from the > maximum value and write that to the register), pulling that up further > to the ALSA core might be nice I guess? I believe yes. Though, I'm still not sure how we can improve the mismatch of dB min/max. The dB values of those inverted controls reflect the result of subtraction, no? Takashi
On Fri, Jul 07, 2023 at 03:47:47PM +0200, Takashi Iwai wrote: > Mark Brown wrote: > > The ASoC generic control stuff supports inverting the value prior to > > presentation to userspace so it's masked there (instead of writing the > > number userspace sees to the register we subtract the number from the > > maximum value and write that to the register), pulling that up further > > to the ALSA core might be nice I guess? > I believe yes. Though, I'm still not sure how we can improve the > mismatch of dB min/max. The dB values of those inverted controls > reflect the result of subtraction, no? Yes, the dB scale presented to userspace is reversed relative to the ordering in the registers.
On Fri, 07 Jul 2023 17:06:24 +0200, Mark Brown wrote: > > On Fri, Jul 07, 2023 at 03:47:47PM +0200, Takashi Iwai wrote: > > Mark Brown wrote: > > > > The ASoC generic control stuff supports inverting the value prior to > > > presentation to userspace so it's masked there (instead of writing the > > > number userspace sees to the register we subtract the number from the > > > maximum value and write that to the register), pulling that up further > > > to the ALSA core might be nice I guess? > > > I believe yes. Though, I'm still not sure how we can improve the > > mismatch of dB min/max. The dB values of those inverted controls > > reflect the result of subtraction, no? > > Yes, the dB scale presented to userspace is reversed relative to the > ordering in the registers. Right, the TLV min/max corresponds to the control values, and they don't mean the raw register values. BTW, this thread made me wonder whether it makes sense to give some sanity checks (maybe with CONFIG_SND_DEBUG) in ALSA core. e.g. read_tlv_buf() in sound/core/control.c can perform some tests before actually passing to user-space. Takashi
diff --git a/sound/soc/codecs/wcd938x.c b/sound/soc/codecs/wcd938x.c index faa15a5ed2c8..3a3360711f8f 100644 --- a/sound/soc/codecs/wcd938x.c +++ b/sound/soc/codecs/wcd938x.c @@ -210,7 +210,7 @@ struct wcd938x_priv { }; static const SNDRV_CTL_TLVD_DECLARE_DB_MINMAX(ear_pa_gain, 600, -1800); -static const SNDRV_CTL_TLVD_DECLARE_DB_MINMAX(line_gain, 600, -3000); +static const DECLARE_TLV_DB_SCALE(line_gain, -3000, 150, -3000); static const SNDRV_CTL_TLVD_DECLARE_DB_MINMAX(analog_gain, 0, 3000); struct wcd938x_mbhc_zdet_param { @@ -2655,8 +2655,8 @@ static const struct snd_kcontrol_new wcd938x_snd_controls[] = { wcd938x_get_swr_port, wcd938x_set_swr_port), SOC_SINGLE_EXT("DSD_R Switch", WCD938X_DSD_R, 0, 1, 0, wcd938x_get_swr_port, wcd938x_set_swr_port), - SOC_SINGLE_TLV("HPHL Volume", WCD938X_HPH_L_EN, 0, 0x18, 0, line_gain), - SOC_SINGLE_TLV("HPHR Volume", WCD938X_HPH_R_EN, 0, 0x18, 0, line_gain), + SOC_SINGLE_TLV("HPHL Volume", WCD938X_HPH_L_EN, 0, 0x18, 1, line_gain), + SOC_SINGLE_TLV("HPHR Volume", WCD938X_HPH_R_EN, 0, 0x18, 1, line_gain), WCD938X_EAR_PA_GAIN_TLV("EAR_PA Volume", WCD938X_ANA_EAR_COMPANDER_CTL, 2, 0x10, 0, ear_pa_gain), SOC_SINGLE_EXT("ADC1 Switch", WCD938X_ADC1, 1, 1, 0,