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 <[email protected]>
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/tps6287x-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 = {
.vsel_mask = 0xFF,
.vsel_range_reg = TPS6287X_CTRL2,
.vsel_range_mask = TPS6287X_CTRL2_VRANGE,
+ .range_applied_by_vsel = true,
.ramp_reg = TPS6287X_CTRL1,
.ramp_mask = TPS6287X_CTRL1_VRAMP,
.ramp_delay_table = tps6287x_ramp_table,
--
2.45.1
--
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 =]
On Mon, 20 May 2024 15:36:55 +0300, Matti Vaittinen wrote:
> 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."
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[2/2] regulator: tps6287x: Force writing VSEL bit
commit: 1ace99d7c7c4c801c0660246f741ff846a9b8e3c
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark