linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH] Parse missing regulator constraints from device tree blob
@ 2014-01-17 15:11 Saurabh Singh
  0 siblings, 0 replies; 6+ messages in thread
From: Saurabh Singh @ 2014-01-17 15:11 UTC (permalink / raw)
  To: Mark Brown
  Cc: Mark Rutland, lgirdwood, grant.likely, rob.herring, linux-kernel,
	devicetree, celinux-dev, SREEVATSA D B, Praveen BP

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=windows-1252, Size: 7156 bytes --]

This patch adds support for parsing following regulator contraints from
device tree blob.
1. valid modes mask (valid_modes_mask)
2. initial mode (initial_mode)
3. initial state (initial_state)
4. state mem (state_mem)
5. state disk (state_disk)
6. state standby (state_standby)

Signed-off-by: Saurabh Singh Sengar <saurabh1.s@samsung.com>
---
 .../devicetree/bindings/regulator/regulator.txt    |   45 ++++++++++++
 drivers/regulator/of_regulator.c                   |   77 ++++++++++++++++++++
 2 files changed, 122 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
index 2bd8f09..6dc935b 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -14,6 +14,36 @@ Optional properties:
 - regulator-ramp-delay: ramp delay for regulator(in uV/uS)
   For hardwares which support disabling ramp rate, it should be explicitly
   intialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay.
+- regulator-valid-modes-mask: valid operations for regulator on particular machine
+  Supports following modes of operations:
+  Mode			Description
+  ----			-----------
+  fast			Regulator can handle fast changes in it's load
+  normal		Normal regulator power supply mode
+  idle			Regulator runs in a more efficient mode for light loads.
+  standby		Regulator runs in the most efficient mode for very light loads
+  See the example given below.
+
+- regulator-initial-mode: default mode to set on startup
+  Refer to regulator-initial-mode for modes supported
+
+- regulator-initial-state: suspend state to set at init
+  Any one of the following states can be set:
+  Mode			Description
+  ----			-----------
+  suspend-mem		suspend to memory
+  suspend-standby	standby mode
+  suspend-disk		suspend to disk
+  See the example given below.
+
+- regulator-state-mem, regulator-state-disk, regulator-state-standby:
+	defines regulator suspend to memory, suspend to disk (hibernate) and standby respectively.
+	have following sub-constarints:
+	- regulator-state-uv: voltage to set in suspend state
+	- regulator-state-mode: suspend regulator operating mode,
+	  refer to regulator-valid-modes-mask for modes supported
+	- regulator-state-enabled: is regulator enabled in this suspend state
+	- regulator-state-disabled: is the regulator disbled in this suspend state
 
 Deprecated properties:
 - regulator-compatible: If a regulator chip contains multiple
@@ -29,6 +59,21 @@ Example:
 		regulator-max-microvolt = <2500000>;
 		regulator-always-on;
 		vin-supply = <&vin>;
+		regulator-initial-mode = "normal";
+		regulator-initial-state = "suspend-mem";
+		regulator-valid-modes-mask {
+		/*can support multiple mode
+		 * in this example supporting fast and normal mode */
+			fast-mode;
+			normal-mode;
+		};
+		regulator-state-mem {
+			regulator-state-mode = "idle";
+			regulator-state-enabled;
+		};
+		regulator-state-disk {
+			regulator-state-disabled;
+		};
 	};
 
 Regulator Consumers:
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 7827384..3030597 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -16,11 +16,36 @@
 #include <linux/regulator/machine.h>
 #include <linux/regulator/of_regulator.h>
 
+/**
+ * set_regulator_state_constraints - set regulator state for low power system states
+ * @np: device node for the low power regulator state
+ * @regulator_state: regulator_state structure need to be filled
+ */
+static void set_regulator_state_constraints(struct device_node *np,
+		struct regulator_state *state)
+{
+	of_property_read_u32(np, "regulator-state-uv", &state->uV);
+	if (!of_property_match_string(np, "regulator-state-mode", "fast"))
+		state->mode = REGULATOR_MODE_FAST;
+	else if (!of_property_match_string(np, "regulator-state-mode",
+								"normal"))
+		state->mode = REGULATOR_MODE_NORMAL;
+	else if (!of_property_match_string(np, "regulator-state-mode", "idle"))
+		state->mode = REGULATOR_MODE_IDLE;
+	else if (!of_property_match_string(np, "regulator-state-mode",
+								"standby"))
+		state->mode = REGULATOR_MODE_STANDBY;
+	state->enabled = of_property_read_bool(np, "regulator-state-enabled");
+	state->disabled = of_property_read_bool(np, "regulator-state-disabled");
+}
+
+
 static void of_get_regulation_constraints(struct device_node *np,
 					struct regulator_init_data **init_data)
 {
 	const __be32 *min_uV, *max_uV, *uV_offset;
 	const __be32 *min_uA, *max_uA, *ramp_delay;
+	struct device_node *state, *valid_modes;
 	struct property *prop;
 	struct regulation_constraints *constraints = &(*init_data)->constraints;
 
@@ -73,6 +98,58 @@ static void of_get_regulation_constraints(struct device_node *np,
 		else
 			constraints->ramp_disable = true;
 	}
+
+	valid_modes = of_find_node_by_name(np, "regulator-valid-modes-mask");
+	if (valid_modes) {
+		if (of_property_read_bool(valid_modes, "fast"))
+			constraints->valid_modes_mask = REGULATOR_MODE_FAST;
+		if (of_property_read_bool(valid_modes, "normal"))
+			constraints->valid_modes_mask |= REGULATOR_MODE_NORMAL;
+		if (of_property_read_bool(valid_modes, "idle"))
+			constraints->valid_modes_mask |= REGULATOR_MODE_IDLE;
+		if (of_property_read_bool(valid_modes, "standby"))
+			constraints->valid_modes_mask |= REGULATOR_MODE_STANDBY;
+	}
+
+	/* flag assignment for initial mode*/
+	if (!of_property_match_string(np, "regulator-initial-mode", "fast"))
+		constraints->initial_mode = REGULATOR_MODE_FAST;
+	else if (!of_property_match_string(np, "regulator-initial-mode",
+								"normal"))
+		constraints->initial_mode = REGULATOR_MODE_NORMAL;
+	else if (!of_property_match_string(np, "regulator-initial-mode",
+								"idle"))
+		constraints->initial_mode = REGULATOR_MODE_IDLE;
+	else if (!of_property_match_string(np, "regulator-initial-mode",
+								"standby"))
+		constraints->initial_mode = REGULATOR_MODE_STANDBY;
+
+	/* flag assignment for initial state*/
+	if (!of_property_match_string(np,
+				"regulator-initial-state", "suspend-mem"))
+		constraints->initial_state = PM_SUSPEND_MEM;
+	else if (!of_property_match_string(np,
+				"regulator-initial-state", "suspend-standby"))
+		constraints->initial_state = PM_SUSPEND_STANDBY;
+	else if (!of_property_match_string(np,
+				"regulator-initial-state", "suspend-disk"))
+		constraints->initial_state = PM_SUSPEND_MAX;
+
+	/* regulator state during low power system states */
+	state = of_find_node_by_name(np, "regulator-state-mem");
+	if (state)
+		set_regulator_state_constraints(state,
+				&constraints->state_mem);
+
+	state = of_find_node_by_name(np, "regulator-state-disk");
+	if (state)
+		set_regulator_state_constraints(state,
+				&constraints->state_disk);
+
+	state = of_find_node_by_name(np, "regulator-state-standby");
+	if (state)
+		set_regulator_state_constraints(state,
+				&constraints->state_standby);
 }
 
 /**
-- 
1.7.0.4ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] Parse missing regulator constraints from device tree blob
@ 2014-01-17 15:04 Saurabh Singh
  0 siblings, 0 replies; 6+ messages in thread
From: Saurabh Singh @ 2014-01-17 15:04 UTC (permalink / raw)
  To: Mark Brown, rob.herring
  Cc: Mark Rutland, lgirdwood, grant.likely, linux-kernel, devicetree,
	celinux-dev, SREEVATSA D B, Praveen BP

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=windows-1252, Size: 2507 bytes --]

Hi Mark,

> No, please do as I asked and follow the process in SubmittingPatches - as I
> said the format things are sent in is very important for the tooling.  Pasting
> the patch into a mail after some other text definitely doesn't give a mail in
> the format covered in SubmittingPatches.  If in doubt send the mail to
> yourself and then compare it with other patches sent to the list and test by
> applying with git am and make sure the patch and changelog come out OK.

Ok, I have created the patch with guidelines, which I will be sending in a separate mail 
Also, this time I have tested my patch it by "git am".

> > +- regulator-valid-modes-mask: valid operations for regulator on
> > +particular machine
> 
> This is not adequately documented, what are "valid operations" and how
> would they be encoded?

Provide the information in documentation, and provide better abstraction so as to hide
linux internals in device tree.

> > +- regulator-input-uv: regulator input voltage, only if supply is
> > +another regulator
> 
> Why provide a property for this, surely if there is another regulator we can
> just find out from that regulator what voltage it is outputting?

Valid point! , removed from the code.

> > +- regulator-initial-mode: default mode to set on startup
> 
> It is not documented what a mode is here or how one would specify it in the
> property.
> 
> > +- regulator-initial-state: suspend state to set at init
> 
> Again, no semantics are provided for this.

Added documentation with example

> I am very nervous about the idea of putting this stuff into DT.  This matches
> less and less well with modern system designs which are becoming more and
> more dynamic, and of course the concepts of suspending to memory, disk
> and standby are unclear and fluid - what is the difference between memory
> and standby for example?
> 
> I'd be interested to know if there are real systems that need this and can't
> figure out what to do dynamically.

We often use suspend to memory  in our mobile domain and is much useful.
Suspend to disk could be useful for special cases of hibernate like debugging.
Couldn't find the use of standby constraint, but I added in code so as to provide completeness to the framework. 

Please let me know your feedback.

Regards,
Saurabh Singh Sengar
Lead Engineer
Samsung R&D Institute
India
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Parse missing regulator constraints from device tree blob
  2014-01-16 13:43 Saurabh Singh
@ 2014-01-16 14:07 ` Mark Brown
  0 siblings, 0 replies; 6+ messages in thread
From: Mark Brown @ 2014-01-16 14:07 UTC (permalink / raw)
  To: Saurabh Singh
  Cc: Mark Rutland, lgirdwood, grant.likely, rob.herring, linux-kernel,
	devicetree, celinux-dev, SREEVATSA D B, Praveen BP

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On Thu, Jan 16, 2014 at 01:43:23PM +0000, Saurabh Singh wrote:
> Hi Mark,
> 
> New patch incorporating your suggestions is given below.
> 
> > * None of these properties are documented. Documentation is required so
> >   that the contract is defined. That allows people to learn how to use
> >   the properties, and makes clear what we can and cannot change
> >   kernel-side.
> Done.  The documentation is in the patch below.

Please send patches using the process in SubmittingPatches, the
formatting of the submission is very important for tools like git am
which people use to work with patches.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Parse missing regulator constraints from device tree blob
@ 2014-01-16 13:43 Saurabh Singh
  2014-01-16 14:07 ` Mark Brown
  0 siblings, 1 reply; 6+ messages in thread
From: Saurabh Singh @ 2014-01-16 13:43 UTC (permalink / raw)
  To: Mark Rutland
  Cc: lgirdwood, broonie, grant.likely, rob.herring, linux-kernel,
	devicetree, celinux-dev, SREEVATSA D B, Praveen BP

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=windows-1252, Size: 6205 bytes --]

Hi Mark,

New patch incorporating your suggestions is given below.

> * None of these properties are documented. Documentation is required so
>   that the contract is defined. That allows people to learn how to use
>   the properties, and makes clear what we can and cannot change
>   kernel-side.
Done.  The documentation is in the patch below.

> * It leaks Linux internal details (e.g. suspend_state_t values,
>   valid_mode_mask) without any attempt at abstraction, in violation of
>   dt principles.
Unlike valid_ops_mask, valid_mode_mask cannot be derived from the other settings.
It depends on the hardware (regulator) capability. So, it has to be specified in DT blob.

> * Accessors are used poorly. Endianness conversion is done manually
>   rather than being left to accessors, and property lengths aren't
>   checked.
Used the accessors for u32 and bool.

> 	u32 uv;
> 	of_property_read_u32(np, "regulator-state-uv", &uv);
> 
> However, as far as I can see this value should come from an input supply
> anyway.
This is not input supply. This is operating voltage to be set when device suspends.

diffstat for this patch is:
 Documentation/devicetree/bindings/regulator/regulator.txt |   19 ++++++
 drivers/regulator/of_regulator.c                          |   41 ++++++++++++++
 2 files changed, 60 insertions(+)

To apply the patch, in the root of a kernel tree use:
patch -p1 < of_regulator.patch

Please let me know any feedback you have on this patch or the approach used.

Regards,
=====================
Saurabh Singh Sengar
Lead Engineer
Samsung R&D Institute
India
Samsung
=====================
Signed-off-by: Saurabh Singh Sengar <saurabh1.s@samsung.com>

--------------------------------------------------------------------------------
diff -uprN -X linux-3.12.6-vanilla/Documentation/dontdiff linux-3.12.6-vanilla/Documentation/devicetree/bindings/regulator/regulator.txt linux-3.12.6/Documentation/devicetree/bindings/regulator/regulator.txt
--- linux-3.12.6-vanilla/Documentation/devicetree/bindings/regulator/regulator.txt	2013-12-20 21:21:33.000000000 +0530
+++ linux-3.12.6/Documentation/devicetree/bindings/regulator/regulator.txt	2014-01-16 18:47:17.708608811 +0530
@@ -14,6 +14,17 @@ Optional properties:
 - regulator-ramp-delay: ramp delay for regulator(in uV/uS)
   For hardwares which support disabling ramp rate, it should be explicitly
   intialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay.
+- regulator-valid-modes-mask: valid operations for regulator on particular machine
+- regulator-input-uv: regulator input voltage, only if supply is another regulator
+- regulator-initial-mode: default mode to set on startup
+- regulator-initial-state: suspend state to set at init
+- regulator-state-mem, regulator-state-disk, regulator-state-standby:
+	defines regulator suspend to memory, suspend to disk (hibernate) and standby respectively.
+	have following sub-constarints:
+	- regulator-state-uv: suspend voltage
+	- regulator-state-mode: suspend regulator operating mode
+	- regulator-state-enabled: is regulator enabled in this suspend state
+	- regulator-state-disabled: is the regulator disbled in this suspend state
 
 Deprecated properties:
 - regulator-compatible: If a regulator chip contains multiple
@@ -29,6 +40,14 @@ Example:
 		regulator-max-microvolt = <2500000>;
 		regulator-always-on;
 		vin-supply = <&vin>;
+		regulator-valid-modes-mask = <REGULATOR_MODE_FAST>;
+		regulator-initial-mode = <REGULATOR_MODE_STANDBY>;
+		regulator-initial-state = <PM_SUSPEND_MEM>;
+		regulator-state-mem {
+			regulator-state-mode = <REGULATOR_MODE_IDLE>;
+			regulator-state-enabled;
+		};
+
 	};
 
 Regulator Consumers:
diff -uprN -X linux-3.12.6-vanilla/Documentation/dontdiff linux-3.12.6-vanilla/drivers/regulator/of_regulator.c linux-3.12.6/drivers/regulator/of_regulator.c
--- linux-3.12.6-vanilla/drivers/regulator/of_regulator.c	2013-12-20 21:21:33.000000000 +0530
+++ linux-3.12.6/drivers/regulator/of_regulator.c	2014-01-16 18:45:44.135928414 +0530
@@ -16,11 +16,27 @@
 #include <linux/regulator/machine.h>
 #include <linux/regulator/of_regulator.h>
 
+/**
+ * set_regulator_state_constraints - set regulator state for low power system states
+ * @np: device node for the low power regulator state
+ * @regulator_state: regulator_state structure need to be filled
+ */
+static void set_regulator_state_constraints(struct device_node *np,
+		struct regulator_state *state)
+{
+	of_property_read_u32(np, "regulator-state-uv", &state->uV);
+	of_property_read_u32(np, "regulator-state-mode", &state->mode);
+	state->enabled = of_property_read_bool(np, "regulator-state-enabled");
+	state->disabled = of_property_read_bool(np, "regulator-state-disabled");
+}
+
+
 static void of_get_regulation_constraints(struct device_node *np,
 					struct regulator_init_data **init_data)
 {
 	const __be32 *min_uV, *max_uV, *uV_offset;
 	const __be32 *min_uA, *max_uA, *ramp_delay;
+	struct device_node *state;
 	struct property *prop;
 	struct regulation_constraints *constraints = &(*init_data)->constraints;
 
@@ -73,6 +89,31 @@ static void of_get_regulation_constraint
 		else
 			constraints->ramp_disable = true;
 	}
+
+	of_property_read_u32(np, "regulator-valid-modes-mask",
+					&constraints->valid_modes_mask);
+	of_property_read_u32(np, "regulator-input-uv",
+					&constraints->input_uV);
+	of_property_read_u32(np, "regulator-initial-mode",
+					&constraints->initial_mode);
+	of_property_read_u32(np, "regulator-initial-state",
+					&constraints->initial_state);
+
+	/* regulator state during low power system states */
+	state = of_find_node_by_name(np, "regulator-state-mem");
+	if (state)
+		set_regulator_state_constraints(state,
+				&constraints->state_mem);
+
+	state = of_find_node_by_name(np, "regulator-state-disk");
+	if (state)
+		set_regulator_state_constraints(state,
+				&constraints->state_disk);
+
+	state = of_find_node_by_name(np, "regulator-state-standby");
+	if (state)
+		set_regulator_state_constraints(state,
+				&constraints->state_standby);
 }
 
 /**ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Parse missing regulator constraints from device tree blob
  2014-01-16  6:34 Saurabh Singh
@ 2014-01-16 10:28 ` Mark Rutland
  0 siblings, 0 replies; 6+ messages in thread
From: Mark Rutland @ 2014-01-16 10:28 UTC (permalink / raw)
  To: Saurabh Singh
  Cc: lgirdwood, broonie, grant.likely, rob.herring, linux-kernel,
	devicetree, celinux-dev, srevatsa, bp.praveen

Hi,

On Thu, Jan 16, 2014 at 06:34:46AM +0000, Saurabh Singh wrote:
> This patch adds support for parsing following regulator contraints from device tree blob.
> 1. valid modes mask (valid_modes_mask)
> 2. input microvolt(input_uV)
> 3. initial mode (initial_mode)
> 4. initial state (initial_state)
> 5. state mem (state_mem)
> 6. state disk (state_disk)
> 7. state standby (state_standby)
> 
> This patch is currently against a linux 3.12.6 kernel.
> 
> diffstat for this patch is:
>  of_regulator.c |   63 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 63 insertions(+)
> 
> To apply the patch, in the root of a kernel tree use:
> patch -p1 < of_regulator.patch
> 
> Please let me know any feedback you have on this patch or the approach used.

There are several issues with this patch:

* None of these properties are documented. Documentation is required so
  that the contract is defined. That allows people to learn how to use
  the properties, and makes clear what we can and cannot change
  kernel-side.

* It leaks Linux internal details (e.g. suspend_state_t values,
  valid_mode_mask) without any attempt at abstraction, in violation of
  dt principles.

* Accessors are used poorly. Endianness conversion is done manually
  rather than being left to accessors, and property lengths aren't
  checked.

> 
> Regards,
> =====================
> Saurabh Singh Sengar
> Lead Engineer
> Samsung R&D Institute
> India
> Samsung
> =====================
> Signed-off-by: Saurabh Singh Sengar <saurabh1.s@samsung.com>
> 
> --------------------------------------------------------------------------------
> --- linux-3.12.6/drivers/regulator/of_regulator.c.orig	2014-01-08 17:19:43.085903573 +0530
> +++ linux-3.12.6/drivers/regulator/of_regulator.c	2014-01-15 20:12:22.146543128 +0530
> @@ -16,11 +16,40 @@
>  #include <linux/regulator/machine.h>
>  #include <linux/regulator/of_regulator.h>
>  
> +/**
> + * set_regulator_state_constraints - set regulator state for low power system states
> + * @np: device node for the low power regulator state
> + * @regulator_state: regulator_state structure need to be filled
> + */
> +static void set_regulator_state_constraints(struct device_node *np,
> +		struct regulator_state *regulator_state)
> +{
> +	const __be32 *uV, *mode;
> +
> +	uV = of_get_property(np, "regulator-state-uV", NULL);

Typically properties are all lower-case.

> +	if (uV)
> +		regulator_state->uV = be32_to_cpu(*uV);

As an example, to use accessors correctly, here you should have:

	u32 uv;
	of_property_read_u32(np, "regulator-state-uv", &uv);

However, as far as I can see this value should come from an input supply
anyway.

Thanks,
Mark.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH] Parse missing regulator constraints from device tree blob
@ 2014-01-16  6:34 Saurabh Singh
  2014-01-16 10:28 ` Mark Rutland
  0 siblings, 1 reply; 6+ messages in thread
From: Saurabh Singh @ 2014-01-16  6:34 UTC (permalink / raw)
  To: lgirdwood, broonie, grant.likely, rob.herring, linux-kernel,
	devicetree, celinux-dev
  Cc: srevatsa, bp.praveen

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=windows-1252, Size: 3857 bytes --]

This patch adds support for parsing following regulator contraints from device tree blob.
1. valid modes mask (valid_modes_mask)
2. input microvolt(input_uV)
3. initial mode (initial_mode)
4. initial state (initial_state)
5. state mem (state_mem)
6. state disk (state_disk)
7. state standby (state_standby)

This patch is currently against a linux 3.12.6 kernel.

diffstat for this patch is:
 of_regulator.c |   63 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

To apply the patch, in the root of a kernel tree use:
patch -p1 < of_regulator.patch

Please let me know any feedback you have on this patch or the approach used.

Regards,
=====================
Saurabh Singh Sengar
Lead Engineer
Samsung R&D Institute
India
Samsung
=====================
Signed-off-by: Saurabh Singh Sengar <saurabh1.s@samsung.com>

--------------------------------------------------------------------------------
--- linux-3.12.6/drivers/regulator/of_regulator.c.orig	2014-01-08 17:19:43.085903573 +0530
+++ linux-3.12.6/drivers/regulator/of_regulator.c	2014-01-15 20:12:22.146543128 +0530
@@ -16,11 +16,40 @@
 #include <linux/regulator/machine.h>
 #include <linux/regulator/of_regulator.h>
 
+/**
+ * set_regulator_state_constraints - set regulator state for low power system states
+ * @np: device node for the low power regulator state
+ * @regulator_state: regulator_state structure need to be filled
+ */
+static void set_regulator_state_constraints(struct device_node *np,
+		struct regulator_state *regulator_state)
+{
+	const __be32 *uV, *mode;
+
+	uV = of_get_property(np, "regulator-state-uV", NULL);
+	if (uV)
+		regulator_state->uV = be32_to_cpu(*uV);
+
+	mode = of_get_property(np, "regulator-state-mode", NULL);
+	if (mode)
+		regulator_state->mode = be32_to_cpu(*mode);
+
+	if (of_find_property(np, "regulator-state-enabled", NULL))
+		regulator_state->enabled = true;
+
+	if (of_find_property(np, "regulator-state-disabled", NULL))
+		regulator_state->disabled = true;
+}
+
+
 static void of_get_regulation_constraints(struct device_node *np,
 					struct regulator_init_data **init_data)
 {
 	const __be32 *min_uV, *max_uV, *uV_offset;
 	const __be32 *min_uA, *max_uA, *ramp_delay;
+	const __be32  *initial_mode, *initial_state;
+	const __be32  *input_uV, *valid_modes_mask;
+	struct device_node *state;
 	struct property *prop;
 	struct regulation_constraints *constraints = &(*init_data)->constraints;
 
@@ -73,6 +102,40 @@ static void of_get_regulation_constraint
 		else
 			constraints->ramp_disable = true;
 	}
+
+	valid_modes_mask = of_get_property(np,
+			"regulator-valid-modes-mask", NULL);
+	if (valid_modes_mask)
+		constraints->valid_modes_mask = be32_to_cpu(*valid_modes_mask);
+
+	input_uV = of_get_property(np, "regulator-input-microvolt", NULL);
+	if (input_uV)
+		constraints->input_uV = be32_to_cpu(*input_uV);
+
+	initial_mode = of_get_property(np, "regulator-initial-mode", NULL);
+	if (initial_mode)
+		constraints->initial_mode = be32_to_cpu(*initial_mode);
+
+	initial_state = of_get_property(np, "regulator-initial-state", NULL);
+	if (initial_state)
+		constraints->initial_state = be32_to_cpu(*initial_state);
+
+	/* regulator state during low power system states */
+	state = of_find_node_by_name(np, "regulator-state-mem");
+	if (state)
+		set_regulator_state_constraints(state,
+				&constraints->state_mem);
+
+	state = of_find_node_by_name(np, "regulator-state-disk");
+	if (state)
+		set_regulator_state_constraints(state,
+				&constraints->state_disk);
+
+	state = of_find_node_by_name(np, "regulator-state-standby");
+	if (state)
+		set_regulator_state_constraints(state,
+				&constraints->state_standby);
+
 }
 
 /**ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-01-17 15:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-17 15:11 [PATCH] Parse missing regulator constraints from device tree blob Saurabh Singh
  -- strict thread matches above, loose matches on Subject: below --
2014-01-17 15:04 Saurabh Singh
2014-01-16 13:43 Saurabh Singh
2014-01-16 14:07 ` Mark Brown
2014-01-16  6:34 Saurabh Singh
2014-01-16 10:28 ` Mark Rutland

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).