2022-10-28 21:06:33

by Nícolas F. R. A. Prado

[permalink] [raw]
Subject: [PATCH 6/8] ASoC: rt5682: Support dbvdd and ldo1-in supplies

Add support for the dbvdd and ldo1-in supplies.

Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
---

sound/soc/codecs/rt5682.c | 2 ++
sound/soc/codecs/rt5682.h | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)

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;
--
2.38.1



Subject: Re: [PATCH 6/8] ASoC: rt5682: Support dbvdd and ldo1-in supplies

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 <[email protected]>

Reviewed-by: AngeloGioacchino Del Regno <[email protected]>



2022-10-31 13:47:05

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH 6/8] ASoC: rt5682: Support dbvdd and ldo1-in supplies

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?


Attachments:
(No filename) (298.00 B)
signature.asc (499.00 B)
Download all attachments
Subject: Re: [PATCH 6/8] ASoC: rt5682: Support dbvdd and ldo1-in 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

2022-10-31 17:31:52

by Nícolas F. R. A. Prado

[permalink] [raw]
Subject: Re: [PATCH 6/8] ASoC: rt5682: Support dbvdd and ldo1-in supplies

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

2022-10-31 19:24:36

by Rob Herring (Arm)

[permalink] [raw]
Subject: Re: [PATCH 6/8] ASoC: rt5682: Support dbvdd and ldo1-in supplies

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

2022-10-31 20:08:56

by Nícolas F. R. A. Prado

[permalink] [raw]
Subject: Re: [PATCH 6/8] ASoC: rt5682: Support dbvdd and ldo1-in supplies

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

2022-10-31 22:50:46

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH 6/8] ASoC: rt5682: Support dbvdd and ldo1-in supplies

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.


Attachments:
(No filename) (735.00 B)
signature.asc (499.00 B)
Download all attachments