[PATCH 0/4] Add AM33XX regulators device tree data

This patch series add AM33XX regulators (tps65910/tps65217) device
tree data to am335x-evm and am335x-bone dts files. These patches
are based on Tony L "devel-dt" tree and tested on AM335x EVM and
Bone devices.

Resending patch 1 & 2 to group all the regulator DT data files.

AnilKumar Ch (4):
  ARM: OMAP2+: AM33XX: Add tps65910 device tree data
  ARM: OMAP2+: AM33XX: Add tps65217 device tree data
  arm/dts: Add tps65910 regulator DT data to am335x-evm.dts
  arm/dts: Add tps65217 regulator DT data to am335x-bone.dts

 arch/arm/boot/dts/am335x-bone.dts |   10 +++
 arch/arm/boot/dts/am335x-evm.dts  |   10 +++
 arch/arm/boot/dts/tps65217.dtsi   |   84 +++++++++++++++++++++++++
 arch/arm/boot/dts/tps65910.dtsi   |  123 +++++++++++++++++++++++++++++++++++++
 4 files changed, 227 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/tps65217.dtsi
 create mode 100644 arch/arm/boot/dts/tps65910.dtsi

Add device tree data for tps65910 regulator by adding all the
consumers necessary for AM335X-EVM. The data will be map to a
regulator constraints which is required for regulator set_voltage
and get_voltage calls.

All tps65910 PMIC regulator constraints are placed in a seperate
device tree include file (tps65910.dtsi).

This patch is tested by adding the I2C slave address of TPS65910
pmic to am335x-evm.dts file (Not included in this, I2C slave
addition patch will be submitted to linux-omap, where am335x-evm.dts
binding file is available).

Signed-off-by: AnilKumar Ch <redacted>
---
 arch/arm/boot/dts/tps65910.dtsi |  123 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 123 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/tps65910.dtsi

diff --git a/arch/arm/boot/dts/tps65910.dtsi b/arch/arm/boot/dts/tps65910.dtsi
new file mode 100644
index 0000000..b185235
--- /dev/null
+++ b/arch/arm/boot/dts/tps65910.dtsi

@@ -0,0 +1,123 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/tps65910.pdf
+ */
+
+&tps {
+	compatible = "ti,tps65910";
+
+	regulators {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		vrtc_reg: regulator at 0 {
+			reg = <0>;
+			regulator-compatible = "vrtc";
+			regulator-always-on;
+		};
+
+		vio_reg: regulator at 1 {
+			reg = <1>;
+			regulator-compatible = "vio";
+			regulator-min-microvolt = <1500000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};
+
+		vdd1_reg: regulator at 2 {
+			reg = <2>;
+			regulator-compatible = "vdd1";
+			regulator-min-microvolt = <600000>;
+			regulator-max-microvolt = <1500000>;
+			regulator-boot-on;
+			regulator-always-on;
+		};
+
+		vdd2_reg: regulator at 3 {
+			reg = <3>;
+			regulator-compatible = "vdd2";
+			regulator-min-microvolt = <600000>;
+			regulator-max-microvolt = <1500000>;
+			regulator-boot-on;
+			regulator-always-on;
+		};
+
+		vdd3_reg: regulator at 4 {
+			reg = <4>;
+			regulator-compatible = "vdd3";
+			regulator-always-on;
+		};
+
+		vdig1_reg: regulator at 5 {
+			reg = <5>;
+			regulator-compatible = "vdig1";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <2700000>;
+			regulator-always-on;
+		};
+
+		vdig2_reg: regulator at 6 {
+			reg = <6>;
+			regulator-compatible = "vdig2";
+			regulator-min-microvolt = <1000000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-always-on;
+		};
+
+		vpll_reg: regulator at 7 {
+			reg = <7>;
+			regulator-compatible = "vpll";
+			regulator-min-microvolt = <1000000>;
+			regulator-max-microvolt = <2500000>;
+			regulator-always-on;
+		};
+
+		vdac_reg: regulator at 8 {
+			reg = <8>;
+			regulator-compatible = "vdac";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2850000>;
+			regulator-always-on;
+		};
+
+		vaux1_reg: regulator at 9 {
+			reg = <9>;
+			regulator-compatible = "vaux1";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2850000>;
+			regulator-always-on;
+		};
+
+		vaux2_reg: regulator at 10 {
+			reg = <10>;
+			regulator-compatible = "vaux2";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};
+
+		vaux33_reg: regulator at 11 {
+			reg = <11>;
+			regulator-compatible = "vaux33";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};
+
+		vmmc_reg: regulator at 12 {
+			reg = <12>;
+			regulator-compatible = "vmmc";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};
+	};
+};

-- 
1.7.0.4

Add device tree data for tps65217 regulator by adding all the consumers
necessary for AM335X-BeagleBone. The data will be map to a regulator
constraints which is required for regulator set_voltage and get_voltage
calls.

All tps65217 PMIC regulator constraints are placed in a seperate device
tree include file (tps65217.dtsi).

This patch is tested by adding the I2C slave address of TPS65217
pmic to am335x-bone.dts file (Not included in this, I2C slave
addition patch will be submitted to linux-omap, where am335x-bone.dts
binding file is available).

Signed-off-by: AnilKumar Ch <redacted>
---
 arch/arm/boot/dts/tps65217.dtsi |   84 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 84 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/tps65217.dtsi

diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
new file mode 100644
index 0000000..cbb9e5d
--- /dev/null
+++ b/arch/arm/boot/dts/tps65217.dtsi

@@ -0,0 +1,84 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/tps65217.pdf
+ */
+
+&tps {
+	compatible = "ti,tps65217";
+
+	regulators {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		dcdc1_reg: regulator at 0 {
+			reg = <0>;
+			regulator-compatible = "dcdc1";
+			regulator-min-microvolt = <900000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-boot-on;
+			regulator-always-on;
+		};
+
+		dcdc2_reg: regulator at 1 {
+			reg = <1>;
+			regulator-compatible = "dcdc2";
+			regulator-min-microvolt = <900000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-boot-on;
+			regulator-always-on;
+		};
+
+		dcdc3_reg: regulator at 2 {
+			reg = <2>;
+			regulator-compatible = "dcdc3";
+			regulator-min-microvolt = <900000>;
+			regulator-max-microvolt = <1500000>;
+			regulator-boot-on;
+			regulator-always-on;
+		};
+
+		ldo1_reg: regulator at 3 {
+			reg = <3>;
+			regulator-compatible = "ldo1";
+			regulator-min-microvolt = <1000000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-boot-on;
+			regulator-always-on;
+		};
+
+		ldo2_reg: regulator at 4 {
+			reg = <4>;
+			regulator-compatible = "ldo2";
+			regulator-min-microvolt = <900000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-boot-on;
+			regulator-always-on;
+		};
+
+		ldo3_reg: regulator at 5 {
+			reg = <5>;
+			regulator-compatible = "ldo3";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-boot-on;
+			regulator-always-on;
+		};
+
+		ldo4_reg: regulator at 6 {
+			reg = <6>;
+			regulator-compatible = "ldo4";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-boot-on;
+			regulator-always-on;
+		};
+	};
+};

-- 
1.7.0.4

Adds tps65910 regulator device tree data, which adds I2C node
with I2C frequency and tps65910 PMIC I2C slave address.

Signed-off-by: AnilKumar Ch <redacted>
---
 arch/arm/boot/dts/am335x-evm.dts |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index d6a97d9..15d03ba 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts

@@ -18,3 +18,13 @@
 		reg = <0x80000000 0x10000000>; /* 256 MB */
 	};
 };
+
+&i2c1 {
+	clock-frequency = <400000>;
+
+	tps: tps at 2D {
+		reg = <0x2D>;
+	};
+};
+
+/include/ "tps65910.dtsi"

-- 
1.7.0.4

Adds tps65217 regulator device tree data, which adds I2C node
with I2C frequency and tps65217 PMIC I2C slave address.

Signed-off-by: AnilKumar Ch <redacted>
---
 arch/arm/boot/dts/am335x-bone.dts |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index a9af4db..a4d4415 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts

@@ -18,3 +18,13 @@
 		reg = <0x80000000 0x10000000>; /* 256 MB */
 	};
 };
+
+&i2c1 {
+	clock-frequency = <400000>;
+
+	tps: tps at 24 {
+		reg = <0x24>;
+	};
+};
+
+/include/ "tps65217.dtsi"

-- 
1.7.0.4

On Fri, Jul 20, 2012 at 12:16:26PM +0530, AnilKumar Ch wrote:

+		vio_reg: regulator at 1 {
+			reg = <1>;
+			regulator-compatible = "vio";
+			regulator-min-microvolt = <1500000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};

Every regulator here has a rather large voltage range specified with no
consumers added.  Are you sure these voltage ranges make sense in your
design and you've not just cut'n'pasted the entire voltage range that
your regulator supports without reference to what your board can do?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120720/46545946/attachment.sig>

On Fri, Jul 20, 2012 at 12:16:27PM +0530, AnilKumar Ch wrote:

+		dcdc1_reg: regulator at 0 {
+			reg = <0>;
+			regulator-compatible = "dcdc1";
+			regulator-min-microvolt = <900000>;
+			regulator-max-microvolt = <1800000>;

Same issue here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120720/fa4d5480/attachment.sig>

Hi Mark,

Thanks for the review.

On Fri, Jul 20, 2012 at 15:29:36, Mark Brown wrote:

On Fri, Jul 20, 2012 at 12:16:26PM +0530, AnilKumar Ch wrote:

quoted

+		vio_reg: regulator at 1 {
+			reg = <1>;
+			regulator-compatible = "vio";
+			regulator-min-microvolt = <1500000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};

Every regulator here has a rather large voltage range specified with no
consumers added.  Are you sure these voltage ranges make sense in your
design and you've not just cut'n'pasted the entire voltage range that
your regulator supports without reference to what your board can do?

tps65217.dtsi is a generic file to be used by the SoCs so these constraints
were taken from the regulator itself. SoC specific limits can be added in
SoC specific .dts file to tighten the constraints to require limit. I have
tested the driver with this approach.

Required consumers will be added while submitting the regulator dependent
Consumers. One of the usecase I can specify here is MPU voltage control
through DVFS framework. So if require, MPU consumer will be added along
with the DVFS support.

Thanks
AnilKumar

On Fri, Jul 20, 2012 at 11:27:36AM +0000, AnilKumar, Chimata wrote:

On Fri, Jul 20, 2012 at 15:29:36, Mark Brown wrote:

quoted

Every regulator here has a rather large voltage range specified with no
consumers added.  Are you sure these voltage ranges make sense in your
design and you've not just cut'n'pasted the entire voltage range that
your regulator supports without reference to what your board can do?

tps65217.dtsi is a generic file to be used by the SoCs so these constraints
were taken from the regulator itself. SoC specific limits can be added in
SoC specific .dts file to tighten the constraints to require limit. I have
tested the driver with this approach.

No, this is not a sane approach.  You've no idea if any of these
settings are safe or sane for the board.  Boards should enable things
they know are safe, not remove those they know are broken.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120720/91ea542e/attachment.sig>

On Fri, Jul 20, 2012 at 17:08:06, Mark Brown wrote:

On Fri, Jul 20, 2012 at 11:27:36AM +0000, AnilKumar, Chimata wrote:

quoted

On Fri, Jul 20, 2012 at 15:29:36, Mark Brown wrote:

quoted

quoted

Every regulator here has a rather large voltage range specified with no
consumers added.  Are you sure these voltage ranges make sense in your
design and you've not just cut'n'pasted the entire voltage range that
your regulator supports without reference to what your board can do?

quoted

tps65217.dtsi is a generic file to be used by the SoCs so these constraints
were taken from the regulator itself. SoC specific limits can be added in
SoC specific .dts file to tighten the constraints to require limit. I have
tested the driver with this approach.

No, this is not a sane approach.  You've no idea if any of these
settings are safe or sane for the board.  Boards should enable things
they know are safe, not remove those they know are broken.

Unsterstood, I will send v2 with constraints updated.

Regards
AnilKumar

On Mon, Jul 23, 2012 at 12:36:48, AnilKumar, Chimata wrote:

On Fri, Jul 20, 2012 at 17:08:06, Mark Brown wrote:

quoted

On Fri, Jul 20, 2012 at 11:27:36AM +0000, AnilKumar, Chimata wrote:

quoted

On Fri, Jul 20, 2012 at 15:29:36, Mark Brown wrote:

quoted

quoted

Every regulator here has a rather large voltage range specified with no
consumers added.  Are you sure these voltage ranges make sense in your
design and you've not just cut'n'pasted the entire voltage range that
your regulator supports without reference to what your board can do?

quoted

tps65217.dtsi is a generic file to be used by the SoCs so these constraints
were taken from the regulator itself. SoC specific limits can be added in
SoC specific .dts file to tighten the constraints to require limit. I have
tested the driver with this approach.

No, this is not a sane approach.  You've no idea if any of these
settings are safe or sane for the board.  Boards should enable things
they know are safe, not remove those they know are broken.

Unsterstood, I will send v2 with constraints updated.

By the way, if we look at all the regulator added (DT supported) till now have
the similar problem.

arch/arm/boot/dts/imx6q.dtsi
arch/arm/boot/dts/twl4030.dtsi
arch/arm/boot/dts/twl6030.dtsi
arch/arm/boot/dts/db8500.dtsi

Regards
AnilKumar

On Mon, Jul 23, 2012 at 01:23:50PM +0000, AnilKumar, Chimata wrote:

By the way, if we look at all the regulator added (DT supported) till now have
the similar problem.

arch/arm/boot/dts/imx6q.dtsi

This is fine - the SoC contains integrated regulators which supply other
bits of the Soc so we can be confident that the hookup is good just
based on the silicon.

arch/arm/boot/dts/twl4030.dtsi
arch/arm/boot/dts/twl6030.dtsi

These appear to have similar issues and should be fixed, at least as far
as the voltage ranges go.

arch/arm/boot/dts/db8500.dtsi

I'm not actually seeing anything terribly problematic here, though the
regulator-name properties should really be removed as they're fairly
useless and seem to be missing the point of having the property.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120723/fa09dbb7/attachment-0001.sig>

On 23/07/12 14:34, Mark Brown wrote:

On Mon, Jul 23, 2012 at 01:23:50PM +0000, AnilKumar, Chimata wrote:

quoted

By the way, if we look at all the regulator added (DT supported) till now have
the similar problem.

quoted

arch/arm/boot/dts/imx6q.dtsi

This is fine - the SoC contains integrated regulators which supply other
bits of the Soc so we can be confident that the hookup is good just
based on the silicon.

quoted

arch/arm/boot/dts/twl4030.dtsi
arch/arm/boot/dts/twl6030.dtsi

These appear to have similar issues and should be fixed, at least as far
as the voltage ranges go.

quoted

arch/arm/boot/dts/db8500.dtsi

I'm not actually seeing anything terribly problematic here, though the
regulator-name properties should really be removed as they're fairly
useless and seem to be missing the point of having the property.

I've missed the context of the thread, so can't comment, but I'm happy 
to remove the regulator-name properties from db8500.dts. Adding to my TODO.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Hi Mark,

quoted

arch/arm/boot/dts/db8500.dtsi

I'm not actually seeing anything terribly problematic here, though the
regulator-name properties should really be removed as they're fairly
useless and seem to be missing the point of having the property.

Just looking at this now. 

The regulator-name property is used to populate constrains->name. Are
you sure you still want them all removed?

Kind regards,
Lee

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

On Tue, Aug 28, 2012 at 12:26:07PM +0100, Lee Jones wrote:

quoted

quoted

arch/arm/boot/dts/db8500.dtsi

quoted

I'm not actually seeing anything terribly problematic here, though the
regulator-name properties should really be removed as they're fairly
useless and seem to be missing the point of having the property.

Just looking at this now. 

The regulator-name property is used to populate constrains->name. Are
you sure you still want them all removed?

Yes, of course.  There's no way that a generic .dtsi used for any
possible board could come up with a sensible value.

On Tue, Aug 28, 2012 at 10:21:33AM -0700, Mark Brown wrote:

On Tue, Aug 28, 2012 at 12:26:07PM +0100, Lee Jones wrote:

quoted

quoted

quoted

arch/arm/boot/dts/db8500.dtsi

quoted

quoted

I'm not actually seeing anything terribly problematic here, though the
regulator-name properties should really be removed as they're fairly
useless and seem to be missing the point of having the property.

quoted

Just looking at this now. 

quoted

The regulator-name property is used to populate constrains->name. Are
you sure you still want them all removed?

Yes, of course.  There's no way that a generic .dtsi used for any
possible board could come up with a sensible value.

So how should constrains->name be populated then? Would you prefer
regulator-names moved to the .dts file(s), or something else?

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

On Wed, Aug 29, 2012 at 09:31:31AM +0100, Lee Jones wrote:

On Tue, Aug 28, 2012 at 10:21:33AM -0700, Mark Brown wrote:

quoted

quoted

The regulator-name property is used to populate constrains->name. Are
you sure you still want them all removed?

quoted

Yes, of course.  There's no way that a generic .dtsi used for any
possible board could come up with a sensible value.

So how should constrains->name be populated then? Would you prefer
regulator-names moved to the .dts file(s), or something else?

Of course, yes.  The sole purpose of that field is to give a board
specific name to the supply.  It can't usefully be set by anything
except the board.