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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F854EB64D9 for ; Fri, 7 Jul 2023 13:30:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232449AbjGGNa6 (ORCPT ); Fri, 7 Jul 2023 09:30:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49550 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232196AbjGGNaz (ORCPT ); Fri, 7 Jul 2023 09:30:55 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 847451FEC for ; Fri, 7 Jul 2023 06:30:50 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id E7C1F22695; Fri, 7 Jul 2023 13:30:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1688736648; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dML+Bci7dvwejb6fUN7elzw5DqVmGNwoDlI56jXp5jo=; b=OfKupCDLFLkgEOE1Gv6MCWiNkK7+GW6YUeLeaUAOcWOc9SFKx4HPAJ4fBbSuQPNMe9J7rl Glj83gAjHi7uHvlsmhLpkqgkXY2HMBMSMkUYZzYDnCPDa7cP5wK14AxxNkbhdRf73RslgL j8kKcs6TP8gXFbxN8MydDSZNJM9TPBI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1688736648; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dML+Bci7dvwejb6fUN7elzw5DqVmGNwoDlI56jXp5jo=; b=VPllrIwjpS28/Oy40IrMqdng/0BqwT/L23bu9CyaTHtRoWcVsnu6tNlmyJsv1E2uX8oZdw nfLc5Tzn6sMsbfDg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 9FB6F1346D; Fri, 7 Jul 2023 13:30:48 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Vd3gJYgTqGQIWgAAMHmgww (envelope-from ); Fri, 07 Jul 2023 13:30:48 +0000 Date: Fri, 07 Jul 2023 15:30:48 +0200 Message-ID: <87wmzbkfw7.wl-tiwai@suse.de> From: Takashi Iwai To: Mark Brown Cc: Srinivas Kandagatla , Johan Hovold , 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 Subject: Re: [PATCH] ASoC: codecs: wcd938x: fix dB range for HPHL and HPHR In-Reply-To: <3450ef1e-cb20-4242-b482-41d3d34c4564@sirena.org.uk> References: <20230705125723.40464-1-srinivas.kandagatla@linaro.org> <87y1jrkgdx.wl-tiwai@suse.de> <3450ef1e-cb20-4242-b482-41d3d34c4564@sirena.org.uk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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