Unverified Commit 51c0a0c6 authored by Mark Brown's avatar Mark Brown
Browse files

Merge series "regulator: bd718x7: support voltage scaling" from Matti...

Merge series "regulator: bd718x7: support voltage scaling" from Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>:

RFC for adding a support for typical voltage scaling connection

In few occasions there has been a need to scale the voltage output
from bucks on BD71837. Usually this is done when buck8 is used to
power specific GPU which can utilize voltages down to 0.7V. As lowest
the buck8 on BD71837 can go is 0.8V, and external connection is used to
scale the voltages.

The BD71837, BD71847 and BD71850 bucks can be adjusted by pulling up the
feedback pin using suitable voltage/resistors.

	|---------------|
	|       buck 8  |-------+----->Vout
	|               |       |
	|---------------|       |
	       |                |
	       |                |
	       +-------+--R2----+
	               |
	               R1
	               |
	       V FB-pull-up

This will scale the voltage as follows:
 - Vout_o = Vo - (Vpu - Vo)*R2/R1
 - Linear_step = step_orig*(R1+R2)/R1
where:
Vout_o is adjusted voltage output at vsel reg value 0
Vo is original voltage output at vsel reg value 0
Vpu is the pull-up voltage V FB-pull-up in the picture
R1 and R2 are resistor values.

>From HW point of view this does not need to be limited to buck 8. This
connection can be used to adjust output from any of the bucks on
BD71837/47/50.

As this seems to be a 'de-facto' way to scale the voltages on BD71837 it
might be a good idea to support computing the new voltage ranges for
bucks based on the V-pull-up and resistor R1/R2 values given from
device-tree. This allows describing the external HW connection using DT
to correctly scale the voltages.

This RFC uses "rohm,feedback-pull-up-r1-ohms" and
"rohm,feedback-pull-up-r2-ohms" to provide the resistor values - but
these names (without the picture) might not be too descriptive. I am
grateful for all suggestions as better and more descriptive names.

This patch series is an RFC because this connection feels somewhat
"hacky". OTOH - when hack becomes widely used, it is less of an hack and
more of a standard - and occasionally supporting HW hacks using SW may
benefit us all, right? :)

The other thing some projects do is allowing the change of BD71837 buck8
voltages when buck8 is enabled. This however will introduce voltage
spikes as buck8 was not originally designed for this. The specific HW
platform must be evaluated to be able to tolerate these spikes. Thus
this patch series does not support buck8 voltage changes when buck8 is
enabled. I wonder if this should be allowed per some config option(?) I
don't want to help people frying their boards... Opinions? Is there
suggested way of allowing this type of features at own risk? Config or
even Some #ifdef which is not listed in Kconfig? Device-tree property?
 If you have (good) suggestions I could add the optional (non default)
DVS support for non DVS bucks on BD71837.

Matti Vaittinen (3):
  dt-bindings: regulator: BD71837 support commonly used feedback
    connection
  dt-bindings: regulator: BD71847 support commonly used feedback
    connection
  regulator: bd718x7: Support external connection to scale voltages

 .../regulator/rohm,bd71837-regulator.yaml     |  48 +++++
 .../regulator/rohm,bd71847-regulator.yaml     |  49 ++++++
 drivers/regulator/bd718x7-regulator.c         | 164 +++++++++++++++++-
 3 files changed, 254 insertions(+), 7 deletions(-)

base-commit: 3cea11cd
--
2.21.3

--
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 =]
parents 28565413 d2ad9811
Loading
Loading
Loading
Loading
+9 −0
Original line number Diff line number Diff line
@@ -1910,6 +1910,15 @@ S: 660 Harvard Ave. #7
S: Santa Clara, CA 95051
S: USA

N: Kukjin Kim
E: kgene@kernel.org
D: Samsung S3C, S5P and Exynos ARM architectures

N: Sangbeom Kim
E: sbkim73@samsung.com
D: Samsung SoC Audio (ASoC) drivers
D: Samsung PMIC (RTC, regulators, MFD) drivers

N: Russell King
E: rmk@arm.linux.org.uk
D: Linux/arm integrator, maintainer & hacker
+9 −1
Original line number Diff line number Diff line
@@ -58,6 +58,14 @@ Users: All users of this interface who wish to be notified when
		be changed further.


Note:
   The fields should be use a simple notation, compatible with ReST markup.
   Also, the file **should not** have a top-level index, like::

	===
	foo
	===

How things move between levels:

Interfaces in stable may move to obsolete, as long as the proper
+4 −4
Original line number Diff line number Diff line
@@ -8,10 +8,10 @@ Description: Device DAX is the device-centric analogue of Filesystem
		system.  Device DAX is strict, precise and predictable.
		Specifically this interface:

		1/ Guarantees fault granularity with respect to a given
		1. Guarantees fault granularity with respect to a given
		   page size (pte, pmd, or pud) set at configuration time.

		2/ Enforces deterministic behavior by being strict about
		2. Enforces deterministic behavior by being strict about
		   what fault scenarios are supported.

		The /sys/class/dax/ interface enumerates all the
+3 −0
Original line number Diff line number Diff line
@@ -7,10 +7,13 @@ Description: It is possible to switch the cpi setting of the mouse with the
		setting reported by the mouse. This number has to be further
		processed to receive the real dpi value:

		===== ====
		VALUE DPI
		===== ====
		1     400
		2     800
		4     1600
		===== ====

		This file is readonly.
		Has never been used. If bookkeeping is done, it's done in userland tools.
+2 −0
Original line number Diff line number Diff line
@@ -13,6 +13,8 @@ Description:
  GPIOs are identified as they are inside the kernel, using integers in
  the range 0..INT_MAX.  See Documentation/admin-guide/gpio for more information.

  ::

    /sys/class/gpio
	/export ... asks the kernel to export a GPIO to userspace
	/unexport ... to return a GPIO to the kernel
Loading