Received-SPF: pass (google.com: domain of linux-kernel+bounces-183748-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Mon, 20 May 2024 15:36:55 +0300
From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Matti Vaittinen <mazziesaccount@gmail.com>,
	Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>,
	=?iso-8859-1?Q?M=E5rten?= Lindahl <marten.lindahl@axis.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH v2 2/2] regulator: tps6287x: Force writing VSEL bit
Message-ID: <ZktD50C5twF1EuKu@fedora>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="4RW6lHdK0m4qn3Ux"
Content-Disposition: inline


--4RW6lHdK0m4qn3Ux
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

The data-sheet for TPS6287x-Q1
https://www.ti.com/lit/ds/symlink/tps62873-q1.pdf
states at chapter 9.3.6.1 Output Voltage Range:

"Note that every change to the VRANGE[1:0] bits must be followed by a
write to the VSET register, even if the value of the VSET[7:0] bits does
not change."

The current implementation of the driver uses the
regulator_set_voltage_sel_pickable_regmap() helper which further uses
regmap_update_bits() to write the VSET-register. The
regmap_update_bits() will not access the hardware if the new register
value is same as old. It is worth noting that this is true also when the
register is marked volatile, which I can't say is wrong because
'read-mnodify-write'-cycle with a volatile register is in any case
something user should carefully consider.

The 'range_applied_by_vsel'-flag in regulator desc was added to force
the vsel register upodates by using regmap_write_bits(). This variant
will always unconditionally write the bits to the hardware.

It is worth noting that the vsel is now forced to be written to the
hardware, whether the range was changed or not. This may cause a
performance drop if users are wrtiting same voltage value repeteadly.

It would be possible to read the range register to determine if it was
changed, but this would be a performance issue for users who don't use
reg cache for vsel.

Always write the VSET register to the hardware regardless the cache.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Fixes: 7b0518fbf2be ("regulator: Add support for TI TPS6287x regulators")

---
This change has not been tested in appropriate hardware. All testing /
reviewing is very much appreciated.

And just a note - the git log for this file has a few invalid
'signed-off-by'-lines, where the last '>' is missing in email addresses.
I guess it's too late to help it, but it's good to know that the
get_maintainer.pl generates recipient lists where the '>' endings are
also missing. As a consequence, at least the version of mutt mail-client
which I use leaves the Cc field empty - which can result patches never
ending up to intended recipients ... not that the undersigned was so
careless sender :rolleyes:

---
 drivers/regulator/tps6287x-regulator.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/tps6287x-regulator.c b/drivers/regulator/tps=
6287x-regulator.c
index 9b7c3d77789e..3c9d79e003e4 100644
--- a/drivers/regulator/tps6287x-regulator.c
+++ b/drivers/regulator/tps6287x-regulator.c
@@ -115,6 +115,7 @@ static struct regulator_desc tps6287x_reg =3D {
 	.vsel_mask =3D 0xFF,
 	.vsel_range_reg =3D TPS6287X_CTRL2,
 	.vsel_range_mask =3D TPS6287X_CTRL2_VRANGE,
+	.range_applied_by_vsel =3D true,
 	.ramp_reg =3D TPS6287X_CTRL1,
 	.ramp_mask =3D TPS6287X_CTRL1_VRAMP,
 	.ramp_delay_table =3D tps6287x_ramp_table,
--=20
2.45.1


--=20
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =3D]=20

--4RW6lHdK0m4qn3Ux
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCAAdFiEEIx+f8wZb28fLKEhTeFA3/03aocUFAmZLQ+cACgkQeFA3/03a
ocVlJAf+OPTQb3cFf8kzq+C7N7NiYwVxkco/xW8BQSE/ugMthes4VC341nNWQoQy
0afm2u9EvHpAp5MOtVsipS3fKnsTpfPLqBsNdjt5DnYD+8MBX7zqfyp04L6hm1xU
xaQC+sWP9wfaSMLy+RrLpy/adfDBKcWgziGXkDmlTeMfhB4+BT+WI/EN3ySS66IZ
opxdhx4DvvUT6T2YDN94zq3hObaC02Q+kUT7bcidx7NA5x1cFHQHrpI4Ljxbj+zk
pkf77Zj4xdQNl21g1hU9t4sIFbo4fq7/hrsmwUS7nAs2qU7Z6EfOXfh+cF2q5f51
0kZedszcC3pHC853gjW3y+pwT5xC1g==
=RujD
-----END PGP SIGNATURE-----

--4RW6lHdK0m4qn3Ux--