From: Chen-Yu Tsai <wenst@chromium.org>
To: Conor Dooley <conor@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Mark Brown <broonie@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/9] regulator: mt6358: Merge VCN33_* regulators
Date: Mon, 12 Jun 2023 12:19:01 +0800 [thread overview]
Message-ID: <CAGXv+5EcXW8P-EuWZp4MFUFAjaNTzEtRP_d8bkrFyPdq2k2Bqw@mail.gmail.com> (raw)
In-Reply-To: <20230610-bucket-rebuttal-c7c44c5b0a66@spud>
On Sat, Jun 10, 2023 at 11:28 PM Conor Dooley <conor@kernel.org> wrote:
>
> On Fri, Jun 09, 2023 at 04:56:05PM +0100, Conor Dooley wrote:
> > On Fri, Jun 09, 2023 at 04:30:00PM +0800, Chen-Yu Tsai wrote:
> > > The VCN33_BT and VCN33_WIFI regulators are actually the same regulator,
> > > having the same voltage setting and output pin. There are simply two
> > > enable bits that are ORed together to enable the regulator.
> > >
> > > Having two regulators representing the same output pin is misleading
> > > from a design matching standpoint, and also error-prone in driver
> > > implementations. If consumers try to set different voltages on either
> > > regulator, the one set later would override the one set before. There
> > > are ways around this, such as chaining them together and having the
> > > downstream one act as a switch. But given there's only one output pin,
> > > such a workaround doesn't match reality.
> > >
> > > Remove the VCN33_WIFI regulator. During the probe phase, have the driver
> > > sync the enable status of VCN33_WIFI to VCN33_BT. Also drop the suffix
> > > so that the regulator name matches the pin name in the datasheet.
> > >
> > > Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> > > ---
> > > drivers/regulator/mt6358-regulator.c | 65 +++++++++++++++++-----
> > > include/linux/regulator/mt6358-regulator.h | 6 +-
> > > 2 files changed, 52 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/drivers/regulator/mt6358-regulator.c b/drivers/regulator/mt6358-regulator.c
> > > index c9e16bd092f6..faf6b0757019 100644
> > > --- a/drivers/regulator/mt6358-regulator.c
> > > +++ b/drivers/regulator/mt6358-regulator.c
> > > @@ -277,7 +277,7 @@ static const unsigned int vcama_voltages[] = {
> > > 2800000, 2900000, 3000000,
> > > };
> > >
> > > -static const unsigned int vcn33_bt_wifi_voltages[] = {
> > > +static const unsigned int vcn33_voltages[] = {
> > > 3300000, 3400000, 3500000,
> > > };
> > >
> > > @@ -321,7 +321,7 @@ static const u32 vcama_idx[] = {
> > > 0, 7, 9, 10, 11, 12,
> > > };
> > >
> > > -static const u32 vcn33_bt_wifi_idx[] = {
> > > +static const u32 vcn33_idx[] = {
> > > 1, 2, 3,
> > > };
> > >
> > > @@ -566,12 +566,8 @@ static struct mt6358_regulator_info mt6358_regulators[] = {
> > > MT6358_LDO_VCAMA1_CON0, 0, MT6358_VCAMA1_ANA_CON0, 0xf00),
> > > MT6358_LDO("ldo_vemc", VEMC, vmch_vemc_voltages, vmch_vemc_idx,
> > > MT6358_LDO_VEMC_CON0, 0, MT6358_VEMC_ANA_CON0, 0x700),
> > > - MT6358_LDO("ldo_vcn33_bt", VCN33_BT, vcn33_bt_wifi_voltages,
> > > - vcn33_bt_wifi_idx, MT6358_LDO_VCN33_CON0_0,
> > > - 0, MT6358_VCN33_ANA_CON0, 0x300),
> > > - MT6358_LDO("ldo_vcn33_wifi", VCN33_WIFI, vcn33_bt_wifi_voltages,
> > > - vcn33_bt_wifi_idx, MT6358_LDO_VCN33_CON0_1,
> > > - 0, MT6358_VCN33_ANA_CON0, 0x300),
> > > + MT6358_LDO("ldo_vcn33", VCN33, vcn33_voltages, vcn33_idx,
> > > + MT6358_LDO_VCN33_CON0_0, 0, MT6358_VCN33_ANA_CON0, 0x300),
> >
> > Excuse me if I am being daft here, but could you explain how this change
> > is compatible with existing devicetrees?
>
> Ah, I see in the binding commit there's a "Luckily no device tree actually
> uses them." Does that just cover the kernel, or does it consider other
> operating systems/bootloaders?
That comment covers the upstream kernel and the downstream ChromeOS kernel
specifically. The bootloader that ChromeOS uses (coreboot) doesn't use
device trees. I don't know what MediaTek uses for their phones though.
AFAIK MediaTek only supports the Linux kernel, be it for Android or ChromeOS.
There's not a large community around it, unlike some of the other ARM SoCs.
I did find an old v4.4 Android kernel [1] for the MediaTek Helio P60
(MT6771) that is also paired with MT6358. There are no device tree
references to the VCN33 regulator either. Only the definition exists
in the mt6358.dtsi file, much like what we have upstream.
As far as the regulator driver goes, if it can't find a matching regulator
node, it's the same as if the node doesn't exist, and therefore the given
constraints are not ingested. If no constraints are ingested that can
turn it on, and no consumer references to enable it either, we can say
that the regulator is effectively unused.
ChenYu
[1] https://github.com/nokia-dev/android_kernel_nokia_mt6771
next prev parent reply other threads:[~2023-06-12 4:19 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-09 8:29 [PATCH 0/9] regulator: mt6358: Remove bogus regulators and improvements Chen-Yu Tsai
2023-06-09 8:29 ` [PATCH 1/9] regulator: dt-bindings: mt6358: Merge ldo_vcn33_* regulators Chen-Yu Tsai
2023-06-09 15:47 ` Matthias Brugger
2023-06-09 16:02 ` Krzysztof Kozlowski
2023-06-09 8:29 ` [PATCH 2/9] regulator: dt-bindings: mt6358: Drop *_sshub regulators Chen-Yu Tsai
2023-06-09 15:47 ` Matthias Brugger
2023-06-09 16:02 ` Krzysztof Kozlowski
2023-06-09 8:30 ` [PATCH 3/9] regulator: mt6358: Merge VCN33_* regulators Chen-Yu Tsai
2023-06-09 8:58 ` AngeloGioacchino Del Regno
2023-06-12 3:41 ` Chen-Yu Tsai
2023-06-09 15:56 ` Conor Dooley
2023-06-10 15:28 ` Conor Dooley
2023-06-12 4:19 ` Chen-Yu Tsai [this message]
2023-06-12 17:34 ` Conor Dooley
2023-06-12 10:56 ` Fei Shao
2023-06-15 7:37 ` Chen-Yu Tsai
2023-06-09 8:30 ` [PATCH 4/9] regulator: mt6358: Drop *_SSHUB regulators Chen-Yu Tsai
2023-06-09 9:03 ` AngeloGioacchino Del Regno
2023-06-12 4:45 ` Chen-Yu Tsai
2023-06-12 18:13 ` Mark Brown
2023-06-14 7:39 ` AngeloGioacchino Del Regno
2023-06-09 15:52 ` Matthias Brugger
2023-06-09 8:30 ` [PATCH 5/9] regulator: mt6358: Const-ify mt6358_regulator_info data structures Chen-Yu Tsai
2023-06-09 8:30 ` [PATCH 6/9] regulator: mt6358: Use linear voltage helpers for single range regulators Chen-Yu Tsai
2023-06-09 8:30 ` [PATCH 7/9] regulator: mt6358: Add output voltage fine tuning to fixed regulators Chen-Yu Tsai
2023-06-09 10:03 ` AngeloGioacchino Del Regno
2023-06-14 16:14 ` Mark Brown
2023-06-15 3:24 ` Chen-Yu Tsai
2023-06-09 8:30 ` [PATCH 8/9] regulator: mt6358: Add output voltage fine tuning to variable LDOs Chen-Yu Tsai
2023-06-09 10:03 ` AngeloGioacchino Del Regno
2023-06-09 8:30 ` [PATCH 9/9] arm64: dts: mediatek: mt6358: Merge ldo_vcn33_* regulators Chen-Yu Tsai
2023-06-14 18:58 ` (subset) [PATCH 0/9] regulator: mt6358: Remove bogus regulators and improvements Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGXv+5EcXW8P-EuWZp4MFUFAjaNTzEtRP_d8bkrFyPdq2k2Bqw@mail.gmail.com \
--to=wenst@chromium.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).