Received-SPF: pass (google.com: domain of linux-kernel+bounces-204495-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Thu, 6 Jun 2024 15:38:37 +0100
From: Mark Brown <broonie@kernel.org>
To: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Magnus Damm <magnus.damm@gmail.com>, linux-mmc@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-renesas-soc@vger.kernel.org,
	Fabrizio Castro <fabrizio.castro.jz@renesas.com>,
	Biju Das <biju.das.jz@bp.renesas.com>,
	Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [RFC PATCH 1/4] regulator: core: Ensure the cached state matches
 the hardware state in regulator_set_voltage_unlocked()
Message-ID: <c7f4dc07-5a78-4cd4-8f3e-063dec5d0bc4@sirena.org.uk>
References: <20240605074936.578687-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
 <20240605074936.578687-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
 <22664e29-4c7a-4544-ad32-25c3d7e342e9@sirena.org.uk>
 <CA+V-a8vStea7RZWNXjJLbuibz+-53KT9=5g-P9N4fUrbqjj91A@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="k+c8wgxJKe7M4G9M"
Content-Disposition: inline
In-Reply-To: <CA+V-a8vStea7RZWNXjJLbuibz+-53KT9=5g-P9N4fUrbqjj91A@mail.gmail.com>


--k+c8wgxJKe7M4G9M
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 06, 2024 at 03:12:42PM +0100, Lad, Prabhakar wrote:
> On Thu, Jun 6, 2024 at 1:05=E2=80=AFPM Mark Brown <broonie@kernel.org> wr=
ote:
> > On Wed, Jun 05, 2024 at 08:49:33AM +0100, Prabhakar wrote:

> > > Driver code flow:
> > > 1> set regulator to 1.8V (BIT0 =3D 1)
> > > 2> Regulator cached state now will be 1.8V
> > > 3> Now for some reason driver issues a reset to the IP block
> > >    which resets the registers to default value. In this process
> > >    the regulator is set to 3.3V (BIT0 =3D 0)
> > > 4> Now the driver requests the regulator core to set 1.8V

> > If something is resetting the regulator like this that's a problem in
> > general, we need to either have the driver notify the core when that
> > happens so it can reconfigure the regulator or have it reapply
> > configuration directly.  Obviously it's not great to have that happen at
> > all...

> Currently I am seeing this problem with SDHI driver. For the voltage
> switch operation the MMC core requests the driver to do the change and
> similarly the MMC core requests the reset operation.

> > Having the core driver notify the core when that happens so it can reco=
nfigure the regulator or have it reapply configuration directly.

> Again doing this would be a problem as MMC core also maintains the IOS
> states, reconfiguring the regulator would cause conflicts between the
> states.

If the device can't cope with the requested configuration being applied
why is this going through the regulator API at all?  This just seems
quite confused, putting a bodge in the core like this clearly isn't the
right solution.

--k+c8wgxJKe7M4G9M
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmZhye0ACgkQJNaLcl1U
h9BLqAf/UG65PeifE6tHyWrpslKd/R60qY5DdOnrVWie0kqlq5nDZHQH/T+YBOLN
ZnHdOfBmTHARgPc08z9ronRWn0YzjG3TwzclbJE6q7/sW793wynrKhhbSZCQRemS
aG1s81H6ARFCrIp1esBflxwaeVtsaYFYTKtLiF46dYQjRjiOgeFj5C9ECwe47Ndn
3zbm7Fn9MMWfjqyK3kOKLrnNoNxLjjeKtCvNhYNKRNogVxPBcFlz8JhY0fP8qhsa
aEftWbjuIUYATdQG6rvJqrvfYXdeZZN3SWm6UAuMLWwz2r0DnL9fw6RIfryfdhq1
EXlOvf1ya0E3D7poZG/K//OMoerQbA==
=AZYv
-----END PGP SIGNATURE-----

--k+c8wgxJKe7M4G9M--