Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
MIME-Version: 1.0
References: <20230822084520.564937-1-wenst@chromium.org> <20230822084520.564937-3-wenst@chromium.org>
 <7f743fba-6cba-cce0-d499-0a9d95e3b026@collabora.com>
In-Reply-To: <7f743fba-6cba-cce0-d499-0a9d95e3b026@collabora.com>
From:   Chen-Yu Tsai <wenst@chromium.org>
Date:   Mon, 18 Sep 2023 18:22:01 +0800
Message-ID: <CAGXv+5FgGtpY697e9-Dnk=1Ro0dM7C6qmtdXkWHb5EtocU+t_w@mail.gmail.com>
Subject: Re: [PATCH v2 02/11] mfd: mt6358: Add registers for MT6366 specific regulators
To:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>
Cc:     Lee Jones <lee@kernel.org>, Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        Mark Brown <broonie@kernel.org>,
        Zhiyong Tao <zhiyong.tao@mediatek.com>,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        linux-mediatek@lists.infradead.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Sep 15, 2023 at 4:55=E2=80=AFPM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> Il 22/08/23 10:45, Chen-Yu Tsai ha scritto:
> > The MT6366 PMIC, compared to the MT6358, does away with the VCAM*
> > regulators. Two regulators VM18 and VMDDR reuse their register space.
> > There's also a VSRAM type regulator VSRAM_CORE thats' split between
> > the VCAM* register space and other parts.
> >
> > Add register address macros for these MT6366 specific regulators.
> >
> > Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
>
> For ease of applying to MFD, I think it's ok to have the header changes s=
plit
> from the actual user; so:

Actually that doesn't help, because this is a compile time dependency.
Merging this through the MFD tree and the rest through the regulator
tree would mean either creating an immutable branch, or Lee giving an
ack for this patch to go through the regulator tree. We would be doing
the latter if we squashed the patches together anyway. I think squashing
them does make sense.

ChenYu

> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collab=
ora.com>
>
> Cheers!
>
> > ---
> >   include/linux/mfd/mt6358/registers.h | 17 +++++++++++++++++
> >   1 file changed, 17 insertions(+)
> >
> > diff --git a/include/linux/mfd/mt6358/registers.h b/include/linux/mfd/m=
t6358/registers.h
> > index 5ea2590be710..d83e87298ac4 100644
> > --- a/include/linux/mfd/mt6358/registers.h
> > +++ b/include/linux/mfd/mt6358/registers.h
> > @@ -294,4 +294,21 @@
> >   #define MT6358_AUD_TOP_INT_CON0               0x2228
> >   #define MT6358_AUD_TOP_INT_STATUS0            0x2234
> >
> > +/*
> > + * MT6366 has no VCAM*, but has other regulators in its place. The nam=
es
> > + * keep the MT6358 prefix for ease of use in the regulator driver.
> > + */
> > +#define MT6358_LDO_VSRAM_CON5                 0x1bf8
> > +#define MT6358_LDO_VM18_CON0                  MT6358_LDO_VCAMA1_CON0
> > +#define MT6358_LDO_VM18_CON1                  MT6358_LDO_VCAMA1_CON1
> > +#define MT6358_LDO_VM18_CON2                  MT6358_LDO_VCAMA1_CON2
> > +#define MT6358_LDO_VMDDR_CON0                 MT6358_LDO_VCAMA2_CON0
> > +#define MT6358_LDO_VMDDR_CON1                 MT6358_LDO_VCAMA2_CON1
> > +#define MT6358_LDO_VMDDR_CON2                 MT6358_LDO_VCAMA2_CON2
> > +#define MT6358_LDO_VSRAM_CORE_CON0            MT6358_LDO_VCAMD_CON0
> > +#define MT6358_LDO_VSRAM_CORE_DBG0            0x1cb6
> > +#define MT6358_LDO_VSRAM_CORE_DBG1            0x1cb8
> > +#define MT6358_VM18_ANA_CON0                  MT6358_VCAMA1_ANA_CON0
> > +#define MT6358_VMDDR_ANA_CON0                 MT6358_VCAMD_ANA_CON0
> > +
> >   #endif /* __MFD_MT6358_REGISTERS_H__ */
>