Message ID | 20221028205540.3197304-7-nfraprado@collabora.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp1039564wru; Fri, 28 Oct 2022 13:59:52 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6PugoiiKtFe8eEp+plFE3cJ2RixHywfoVOOPfDmhmfVyI4m38eBv3rzASC477YXwG9Fjys X-Received: by 2002:a17:906:730f:b0:791:9b75:2ca1 with SMTP id di15-20020a170906730f00b007919b752ca1mr1065269ejc.140.1666990792365; Fri, 28 Oct 2022 13:59:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666990792; cv=none; d=google.com; s=arc-20160816; b=0xWqrrM2HTeSGqkGXTDecgS0Fjk1Vg81fss2WaN5mNu1yDlKSh4/ehrI+tIKEvQdnu 7vNyCj26Rdo/2E1OieGsyhG6j+OfkcES6T48n16npp2txTXqDH13AEHXVYxrQarf8AXX +9Zcn+UpDvu3r2GBeqKdYtRgstwks2GQilS1x6USctJs1aEPPirV+KjUKegI2r1F7Nyx FZbV7+502qTrt0OyfVGy0A7JDm1gKEtcoOaa5obMYFIYvyDMuY/wEJILgo8ytScMoHH8 x45q0dpLjDRBJGyjE2Hisqsw8OwMSSSMiR1Q5F8FIy9jdTxWoG5JJtq3mhWWlhMpoLw9 867w== 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 :dkim-signature; bh=rYa5pMjNhAFPhI5ihBUVVDJVKvw/GJeYpPF//wR/A4Q=; b=w2G6FvBBAqjEG/srPeWMeh/4+RXMHfn6J2kbFrqqGI1V484JPKApN9H6vFQJPMfh0l DOLCzaLqPQuK3q+fx6LwHbnL8Gyrgyydl3ntwFuJdZghRSRZM0mMjPk00KD4CNecy6jq gzqx9GxdGouoieLw3xrKTcgfrByhqxOb9FrPie0Qa2Il8C4Hk0WAeH7LHSPz8H7PNDKM 963jMmsQZaY2Yz303rfBlEpbXCgnrO03oGzwKug3xLEf+C2Ct9KFZlpQ1ERP/G3D7VSR Xe6s6Wrx8oE/HKH6x+0H9Gz/RXsl+Jm9mVclC55J5NAeN/Mn06hBSWG+fYNTbEOMVWjV IdXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b="Dr/5K/hx"; 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=collabora.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id va16-20020a17090711d000b007826de24087si4157710ejb.228.2022.10.28.13.59.28; Fri, 28 Oct 2022 13:59:52 -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=@collabora.com header.s=mail header.b="Dr/5K/hx"; 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=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229738AbiJ1U4T (ORCPT <rfc822;pusanteemu@gmail.com> + 99 others); Fri, 28 Oct 2022 16:56:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35590 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230070AbiJ1U4D (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 28 Oct 2022 16:56:03 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CCC522D59C for <linux-kernel@vger.kernel.org>; Fri, 28 Oct 2022 13:56:00 -0700 (PDT) Received: from notapiano.myfiosgateway.com (zone.collabora.co.uk [167.235.23.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nfraprado) by madras.collabora.co.uk (Postfix) with ESMTPSA id CD1676602943; Fri, 28 Oct 2022 21:55:57 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1666990559; bh=k0ciXJ9TnsI96EclJ+3I0qJrPTH22yg0wvdKWox0Yts=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Dr/5K/hxbGJrVT4XPuyjGzz/3Uum/9Fd9mrf8EQhK/6ZcWFGej3jAAgOHmJK//bUU TQ5J3NxsnHW67K1TKUI6HCXxr6VYdZNYNkXy6U3Mi7Q2Or18yPfN+v1v5XDd6c5lt1 QwaBjBwtRR4uwm9gcArc0HucMg1BUNbGteR9UQEtJzbgGpk1P+dMokd3vbreQuEZ6u ceUiW+a+fnsAAT+As/738oHDRssJPvywt3jXdgwz+vNUYCQkAdrUG9p49oIXFdM8MR P++AX6xwtUG1mvI5Ro4y/msZiEOpqecj3RnAKuER9ICKw2cU0wjSEbrRiXLioin/47 3BIwOoyt9X33g== From: =?utf-8?b?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= <nfraprado@collabora.com> To: Mark Brown <broonie@kernel.org>, Bjorn Andersson <andersson@kernel.org> Cc: kernel@collabora.com, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, =?utf-8?b?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= <nfraprado@collabora.com>, Jaroslav Kysela <perex@perex.cz>, Liam Girdwood <lgirdwood@gmail.com>, Oder Chiou <oder_chiou@realtek.com>, Takashi Iwai <tiwai@suse.com>, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org Subject: [PATCH 6/8] ASoC: rt5682: Support dbvdd and ldo1-in supplies Date: Fri, 28 Oct 2022 16:55:38 -0400 Message-Id: <20221028205540.3197304-7-nfraprado@collabora.com> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221028205540.3197304-1-nfraprado@collabora.com> References: <20221028205540.3197304-1-nfraprado@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 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,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?1747966537122325081?= X-GMAIL-MSGID: =?utf-8?q?1747966537122325081?= |
Series |
Adjust usage of rt5682(s) power supply properties
|
|
Commit Message
Nícolas F. R. A. Prado
Oct. 28, 2022, 8:55 p.m. UTC
Add support for the dbvdd and ldo1-in supplies.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
sound/soc/codecs/rt5682.c | 2 ++
sound/soc/codecs/rt5682.h | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
Comments
Il 28/10/22 22:55, Nícolas F. R. A. Prado ha scritto: > Add support for the dbvdd and ldo1-in supplies. > > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
On Fri, Oct 28, 2022 at 04:55:38PM -0400, Nícolas F. R. A. Prado wrote: > @@ -35,6 +35,8 @@ const char *rt5682_supply_names[RT5682_NUM_SUPPLIES] = { > "AVDD", > "MICVDD", > "VBAT", > + "dbvdd", > + "ldo1-in", Why are we making these inconsistent in style with the other supplies?
Il 31/10/22 14:09, Mark Brown ha scritto: > On Fri, Oct 28, 2022 at 04:55:38PM -0400, Nícolas F. R. A. Prado wrote: > >> @@ -35,6 +35,8 @@ const char *rt5682_supply_names[RT5682_NUM_SUPPLIES] = { >> "AVDD", >> "MICVDD", >> "VBAT", >> + "dbvdd", >> + "ldo1-in", > > Why are we making these inconsistent in style with the other supplies? Right. That would be the same for rt5682s, and for the entire series. :\ Cheers, angelo
On Mon, Oct 31, 2022 at 01:09:28PM +0000, Mark Brown wrote: > On Fri, Oct 28, 2022 at 04:55:38PM -0400, Nícolas F. R. A. Prado wrote: > > > @@ -35,6 +35,8 @@ const char *rt5682_supply_names[RT5682_NUM_SUPPLIES] = { > > "AVDD", > > "MICVDD", > > "VBAT", > > + "dbvdd", > > + "ldo1-in", > > Why are we making these inconsistent in style with the other supplies? In short because the other supplies already have users while these are new ones. My understanding was that new supplies should have lowercase names, following DT convention. But I do see the argument on having them all be consistent for a single driver/binding. If there are no remarks from Rob or Krzysztof I can change it in the next version. Thanks, Nícolas
On Mon, Oct 31, 2022 at 12:31:40PM -0400, Nícolas F. R. A. Prado wrote: > On Mon, Oct 31, 2022 at 01:09:28PM +0000, Mark Brown wrote: > > On Fri, Oct 28, 2022 at 04:55:38PM -0400, Nícolas F. R. A. Prado wrote: > > > > > @@ -35,6 +35,8 @@ const char *rt5682_supply_names[RT5682_NUM_SUPPLIES] = { > > > "AVDD", > > > "MICVDD", > > > "VBAT", > > > + "dbvdd", > > > + "ldo1-in", > > > > Why are we making these inconsistent in style with the other supplies? > > In short because the other supplies already have users while these are new ones. > My understanding was that new supplies should have lowercase names, following DT > convention. But I do see the argument on having them all be consistent for a > single driver/binding. If there are no remarks from Rob or Krzysztof I can > change it in the next version. We want lowercase and consistency... Between the 2, I pick consistency. Rob
On Mon, Oct 31, 2022 at 02:09:38PM -0500, Rob Herring wrote: > On Mon, Oct 31, 2022 at 12:31:40PM -0400, Nícolas F. R. A. Prado wrote: > > On Mon, Oct 31, 2022 at 01:09:28PM +0000, Mark Brown wrote: > > > On Fri, Oct 28, 2022 at 04:55:38PM -0400, Nícolas F. R. A. Prado wrote: > > > > > > > @@ -35,6 +35,8 @@ const char *rt5682_supply_names[RT5682_NUM_SUPPLIES] = { > > > > "AVDD", > > > > "MICVDD", > > > > "VBAT", > > > > + "dbvdd", > > > > + "ldo1-in", > > > > > > Why are we making these inconsistent in style with the other supplies? > > > > In short because the other supplies already have users while these are new ones. > > My understanding was that new supplies should have lowercase names, following DT > > convention. But I do see the argument on having them all be consistent for a > > single driver/binding. If there are no remarks from Rob or Krzysztof I can > > change it in the next version. > > We want lowercase and consistency... Between the 2, I pick consistency. We could have both if we converted the existing ones to lowercase first, but as I mentioned in [1] this requires using devm_regulator_get_optional() before falling back, which seemed like an abuse of that API and to unnecessarily complicate the code. So leaving the existing ones as they are and just keeping the consistency for the new ones seems like the way forward. [1] https://lore.kernel.org/all/20221028211224.iiphmwrpqqs27jr4@notapiano/ Thanks, Nícolas
On Mon, Oct 31, 2022 at 03:38:10PM -0400, Nícolas F. R. A. Prado wrote: > We could have both if we converted the existing ones to lowercase first, but as > I mentioned in [1] this requires using devm_regulator_get_optional() before > falling back, which seemed like an abuse of that API and to unnecessarily > complicate the code. Yeah, it's definitely not what the ABI is for and probably more trouble than it's worth. We *could* probably write some helpers that handle legacy supply names to the regulator core code if someone really wanted to retire old names, that way the complication would be shared between users which seems more managable but someone would still need the time and enthusiasm to write the code.
diff --git a/sound/soc/codecs/rt5682.c b/sound/soc/codecs/rt5682.c index 2df95e792900..f0a400285dcf 100644 --- a/sound/soc/codecs/rt5682.c +++ b/sound/soc/codecs/rt5682.c @@ -35,6 +35,8 @@ const char *rt5682_supply_names[RT5682_NUM_SUPPLIES] = { "AVDD", "MICVDD", "VBAT", + "dbvdd", + "ldo1-in", }; EXPORT_SYMBOL_GPL(rt5682_supply_names); diff --git a/sound/soc/codecs/rt5682.h b/sound/soc/codecs/rt5682.h index 52ff0d9c36c5..d568c6993c33 100644 --- a/sound/soc/codecs/rt5682.h +++ b/sound/soc/codecs/rt5682.h @@ -1424,7 +1424,7 @@ enum { RT5682_CLK_SEL_I2S2_ASRC, }; -#define RT5682_NUM_SUPPLIES 3 +#define RT5682_NUM_SUPPLIES 5 struct rt5682_priv { struct snd_soc_component *component;