Skip to contentSkip to conversation

regulators: ab3100: bootstrap board power

PATCH New Linus Walleij 3 participants 3 messages Jun 13, 2013 – Jun 16, 2013

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

PATCH 2/2 regulators: ab3100: bootstrap board power

From: Linus Walleij <[email protected]>

This moves the code from the platform that is bootstrapping the power on the U300 platform out from the machine directory and the special-purpose board node and module and into the regulator node and driver itself.

---
 Documentation/devicetree/bindings/arm/ste-u300.txt |  18 ---
 arch/arm/boot/dts/ste-u300.dts                     |   9 +-
 arch/arm/mach-u300/Makefile                        |   1 -
 arch/arm/mach-u300/regulator.c                     | 133 ---------------------
 drivers/regulator/ab3100.c                         |  73 +++++++++++
 5 files changed, 76 insertions(+), 158 deletions(-)
 delete mode 100644 arch/arm/mach-u300/regulator.c
Documentation/devicetree/bindings/arm/ste-u300.txt +0 -18
index 69b5ab0..5ae045f 100644
@@ -13,18 +13,6 @@ This contains the system controller.
 - compatible: must be "stericsson,u300-syscon".
 - reg: the base address and size of the system controller.
 
-Boards with the U300 SoC include:
-
-S365 "Small Board U365":
-
-Required node: s365
-This contains the board-specific information.
-- compatible: must be "stericsson,s365".
-- vana15-supply: the regulator supplying the 1.5V to drive the
-  board.
-- syscon: a pointer to the syscon node so we can acccess the
-  syscon registers to set the board as self-powered.
-
 Example:
 
 / {
@@ -33,12 +21,6 @@ Example:
 	#address-cells = <1>;
 	#size-cells = <1>;
 
-	s365 {
-		compatible = "stericsson,s365";
-		vana15-supply = <&ab3100_ldo_d_reg>;
-		syscon = <&syscon>;
-	};
-
 	syscon: syscon at c0011000 {
 		compatible = "stericsson,u300-syscon";
 		reg = <0xc0011000 0x1000>;
arch/arm/boot/dts/ste-u300.dts +3 -6
index 8a1032c..fecc72a 100644
@@ -24,12 +24,6 @@
 		reg = <0x48000000 0x03c00000>;
 	};
 
-	s365 {
-		compatible = "stericsson,s365";
-		vana15-supply = <&ab3100_ldo_d_reg>;
-		syscon = <&syscon>;
-	};
-
 	syscon: syscon at c0011000 {
 		compatible = "stericsson,u300-syscon", "syscon";
 		reg = <0xc0011000 0x1000>;
@@ -314,6 +308,9 @@
 			interrupts = <0>; /* EXT0 IRQ */
 			ab3100-regulators {
 				compatible = "stericsson,ab3100-regulators";
+				/* This is for powering the board */
+				vana15-supply = <&ab3100_ldo_d_reg>;
+				syscon = <&syscon>;
 				ab3100_ldo_a_reg: ab3100_ldo_a {
 					regulator-compatible = "ab3100_ldo_a";
 					startup-delay-us = <200>;
arch/arm/mach-u300/Makefile +0 -1
index 0f362b6..fcaa301 100644
@@ -8,4 +8,3 @@ obj-n		:=
 obj-		:=
 
 obj-$(CONFIG_MACH_U300_SPIDUMMY)  += dummyspichip.o
-obj-$(CONFIG_REGULATOR_AB3100)    += regulator.o
arch/arm/mach-u300/regulator.c deleted +0 -133

133 lines not on this page · raw message

drivers/regulator/ab3100.c +73 -0

94 lines not on this page · raw message

Signature · 1 line
1.7.11.3
maintainer
#1 lore raw

PATCH 2/2 regulators: ab3100: bootstrap board power

Quoted 6 lines · Linus Walleij

From: Linus Walleij <[email protected]>

This moves the code from the platform that is bootstrapping the power on the U300 platform out from the machine directory and the special-purpose board node and module and into the regulator node and driver itself.

Hrm. Wouldn't this fit better into the new reset framework?
-------------- 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/20130614/cdf730b6/attachment.sig>

#2 lore raw

PATCH 2/2 regulators: ab3100: bootstrap board power

Quoted 9 lines · Mark Brown
Quoted 6 lines · Linus Walleij

From: Linus Walleij <[email protected]>

This moves the code from the platform that is bootstrapping the power on the U300 platform out from the machine directory and the special-purpose board node and module and into the regulator node and driver itself.

Hrm. Wouldn't this fit better into the new reset framework?

OK that would anyway involve creating some specific DT node for this thing I guess.

Then the current approach with a board node is no more complicated, so we can refactor from that point instead.

Yours,
Linus Walleij