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;
MIME-Version: 1.0
References: <20221024220015.1759428-1-nfraprado@collabora.com>
 <20221024220015.1759428-3-nfraprado@collabora.com> <CAGXv+5HJo5x2ieOegmv5vkfh+rTevdR_fri-7PeK+Gd+GXVjNw@mail.gmail.com>
 <20221027143627.nbbketezqunkclxh@notapiano> <CAGXv+5Hki=VsvZrtANujFYseBp0Lxj4WVf3nzT7cx1kkMmWPFg@mail.gmail.com>
 <CAGXv+5EZO0+Af-Fmz8JW0SiV+b5He8ZSrinJ3TtaCP0vEoW1Mg@mail.gmail.com> <20221027192015.qbmf4bwwok63wytz@notapiano>
In-Reply-To: <20221027192015.qbmf4bwwok63wytz@notapiano>
From:   Chen-Yu Tsai <wenst@chromium.org>
Date:   Thu, 27 Oct 2022 13:42:01 -0700
Message-ID: <CAGXv+5H3B33cTJ7mxd11D3WALHo90fCdTXKXZRfnaK4GATnPMA@mail.gmail.com>
Subject: Re: [PATCH v2 2/4] ASoC: dt-bindings: realtek, rt5682s: Add AVDD and
 MICVDD supplies
To:     =?UTF-8?B?TsOtY29sYXMgRi4gUi4gQS4gUHJhZG8=?= 
        <nfraprado@collabora.com>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Rob Herring <robh+dt@kernel.org>,
        Mark Brown <broonie@kernel.org>, devicetree@vger.kernel.org,
        alsa-devel@alsa-project.org, Liam Girdwood <lgirdwood@gmail.com>,
        linux-kernel@vger.kernel.org, Derek Fang <derek.fang@realtek.com>,
        kernel@collabora.com,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Oct 27, 2022 at 12:20 PM N=C3=ADcolas F. R. A. Prado
<nfraprado@collabora.com> wrote:
>
> On Thu, Oct 27, 2022 at 11:11:08AM -0700, Chen-Yu Tsai wrote:
> > On Thu, Oct 27, 2022 at 10:48 AM Chen-Yu Tsai <wenst@chromium.org> wrot=
e:
> > >
> > > On Thu, Oct 27, 2022 at 7:36 AM N=C3=ADcolas F. R. A. Prado
> > > <nfraprado@collabora.com> wrote:
> > > >
> > > > On Tue, Oct 25, 2022 at 01:12:49PM -0700, Chen-Yu Tsai wrote:
> > > > > On Mon, Oct 24, 2022 at 3:01 PM N=C3=ADcolas F. R. A. Prado
> > > > > <nfraprado@collabora.com> wrote:
> > > > > >
> > > > > > The rt5682s codec can have two supplies: AVDD and MICVDD. They =
are
> > > > >
> > > > > The actual chip also has LDO1_IN (for digital core and charge pum=
p)
> > > > > and DBVDD (for I/O). However in the Chromebook designs these two
> > > > > and AVDD are all provided from the same power rail, through separ=
ate
> > > > > filter banks.
> > > >
> > > > What about rt5682 (no s), does that chip also have these same suppl=
ies?
> >
> > (Missed this question)
> >
> > The RT5682 has the same supplies, plus the VBAT one.
> >
> > ChenYu
> >
> > > > Also, since you already gave the purpose of these other supplies, c=
ould you also
> > > > tell the purpose of AVDD, MICVDD and (for rt5682) VBAT? That way I =
could add
> > > > some description for them in the binding.
> > >
> > > As Mark mentioned in his reply, these are quite standard names.
> > >
> > > AVDD is for the analog bits. MICVDD is for the microphone bias.
> > > VBAT is called battery power in the datasheet. The block diagram
> > > shows it going through an internal controllable LDO whose output
> > > then powers MICVDD. This could be used in designs that don't
> > > include a suitable external supply for MICVDD. If MICVDD is provided,
> > > then one would turn the internal LDO off.
> > >
> > > So either VBAT or MICVDD has to be provided.
>
> So if I get this right we should be making the following supplies require=
d:
> AVDD
> VBAT or MICVDD (on rt5682s there's no VBAT so just MICVDD)

That's right.

> And for LDO1_ON and DBVDD what would be the best way to model? Should we =
make
> them required in the binding as well and add them pointing to the same re=
gulator
> from AVDD in the chromebook DT or just leave them as optional?

They should be required. And we then describe them to match the board.

ChenYu

> Thanks,
> N=C3=ADcolas
>
> > >
> > > ChenYu
> > >
> > > > Thanks,
> > > > N=C3=ADcolas
> > > >
> > > > >
> > > > > Neither does the datasheet specify the ordering of AVDD, DBVDD, a=
nd
> > > > > LDO1_IN for power sequencing, just that three should be toggled t=
ogether.
> > > > >
> > > > > Should we model these? Or wait until some design actually splits =
these?
> > > > [..]