Re: [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data

2011-09-16 Thread Rajendra Nayak 

On Thursday 15 September 2011 07:14 PM, Mark Brown wrote:

On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote:


  .../devicetree/bindings/regulator/regulator.txt|   37 +
  drivers/of/Kconfig |6 ++
  drivers/of/Makefile|1 +
  drivers/of/of_regulator.c  |   85 
  include/linux/of_regulator.h   |   23 +


Don't go hiding the bindings for things away from the code they're
binding.  Bindings for the regualtor API are a regulator API thing and
should be part of the regulator API code.


Sure, Grant seems to think so too, so I'll just move these into
drivers/regulator/




+Required properties:
+- compatible: Must be regulator;


Is this idiomatic or should we just have a helper that parses a big list
of properties from the device node?


I will just be dropping this and use compatible
to specify the specific device type like regulator-twl or 
regulator-fixed.





+- mode-fast: boolean, Can handle fast changes in its load
+- mode-normal: boolean, Normal regulator power supply mode
+- mode-idle: boolean, Can be more efficient during light loads
+- mode-standby: boolean, Can be most efficient during light loads


I guess these are actually permissions to set the given modes?  The
documentation should be clearer.


Ok




+- apply-uV: apply uV constraint if min == max


This seems a bit Linux/runtime policy specific (especially the last
bit).


So these bindings should be defined differently?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data

2011-09-16 Thread Rajendra Nayak 

On Friday 16 September 2011 03:42 AM, Grant Likely wrote:

On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote:

The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure passed from device tree.
'consumer_supplies' which is part of regulator_init_data is not extracted
as the regulator consumer mappings are passed through DT differently,
implemented in subsequent patches.

Also add documentation for regulator bindings to be used to pass
regulator_init_data struct information from device tree.

Signed-off-by: Rajendra Nayakrna...@ti.com
---
  .../devicetree/bindings/regulator/regulator.txt|   37 +
  drivers/of/Kconfig |6 ++
  drivers/of/Makefile|1 +
  drivers/of/of_regulator.c  |   85 


I originally put the DT stuff under drivers/of for i2c and spi because
there was resistance from driver subsystem maintainers to having code
for something that was powerpc only.  Now that it is no longer the
case, I recommend putting this code under drivers/regulator.


sure, will move these in drivers/regulator.




  include/linux/of_regulator.h   |   23 +
  5 files changed, 152 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
  create mode 100644 drivers/of/of_regulator.c
  create mode 100644 include/linux/of_regulator.h

diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt 
b/Documentation/devicetree/bindings/regulator/regulator.txt
new file mode 100644
index 000..001e5ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -0,0 +1,37 @@
+Voltage/Current Regulators
+
+Required properties:
+- compatible: Must be regulator;


A regulator compatible doesn't actually help much.  Compatible is
for specifying the specific device, not for trying to describe what
kind of device it is.  Instead, specific regulator bindings can adopt
  extend this binding.


yeah, will have a compatible for each specific device.




+
+Optional properties:
+- supply-regulator: Name of the parent regulator


If this is a reference to another regulator node then don't use names.
Use phandles instead.  In which case it should probably be named
something like regulator-parent (similar to interrupt parent).

However, I can imagine it possible for a regulator to have multiple
parents.  It may just be better to go with something like the gpio
scheme ofphandle gpio-specifier  list of entries.  Or maybe just a
list of phandles would be sufficient.


Ok, I can use phandles instead of the name, and have a list to specify
multiple parents.
The linux regulator framework though limits to just one parent I guess.




+- min-uV: smallest voltage consumers may set
+- max-uV: largest voltage consumers may set
+- uV-offset: Offset applied to voltages from consumer to compensate for 
voltage drops
+- min-uA: smallest current consumers may set
+- max-uA: largest current consumers may set
+- mode-fast: boolean, Can handle fast changes in its load
+- mode-normal: boolean, Normal regulator power supply mode
+- mode-idle: boolean, Can be more efficient during light loads
+- mode-standby: boolean, Can be most efficient during light loads
+- change-voltage: boolean, Output voltage can be changed by software
+- change-current: boolean, Output current can be chnaged by software
+- change-mode: boolean, Operating mode can be changed by software
+- change-status: boolean, Enable/Disable control for regulator exists
+- change-drms: boolean, Dynamic regulator mode switching is enabled
+- input-uV: Input voltage for regulator when supplied by another regulator
+- initial-mode: Mode to set at startup
+- always-on: boolean, regulator should never be disabled
+- boot-on: bootloader/firmware enabled regulator
+- apply-uV: apply uV constraint if min == max


To avoid collisions, I'd prefix all of these with a common prefix.
Something like regulator-*.


Ok.



These map 1:1 to how Linux currently implements regulators; which
isn't exactly bad, but it means that even if Linux changes, we're
still have to support this binding.  Does this represent the best
layout for high level description of regulators?


I guess, except for some like apply-uV, which like Mark pointed
out are very linux/runtime policy specific.
Mark, what do you think?




+
+Example:
+
+   xyz-regulator: regulator@0 {
+   compatible = regulator;
+   min-uV =100;
+   max-uV =250;
+   mode-fast;
+   change-voltage;
+   always-on;
+   };
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index b3bfea5..296b96d 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -87,4 +87,10 @@ config OF_PCI_IRQ
help
  OpenFirmware PCI IRQ routing helpers

+config OF_REGULATOR
+   def_bool y
+   depends

Re: [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data

2011-09-16 Thread Mark Brown 
On Fri, Sep 16, 2011 at 12:45:55PM +0530, Rajendra Nayak wrote:
 On Thursday 15 September 2011 07:14 PM, Mark Brown wrote:
 On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote:

 +- apply-uV: apply uV constraint if min == max

 This seems a bit Linux/runtime policy specific (especially the last
 bit).

 So these bindings should be defined differently?

If at all.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data

2011-09-16 Thread Mark Brown 
On Fri, Sep 16, 2011 at 12:54:18PM +0530, Rajendra Nayak wrote:
 On Friday 16 September 2011 03:42 AM, Grant Likely wrote:

 However, I can imagine it possible for a regulator to have multiple
 parents.  It may just be better to go with something like the gpio
 scheme ofphandle gpio-specifier  list of entries.  Or maybe just a
 list of phandles would be sufficient.

 Ok, I can use phandles instead of the name, and have a list to specify
 multiple parents.
 The linux regulator framework though limits to just one parent I guess.

I think if we've got multiple parents they should be listed as named
supplies rather than as parents since it's probably important which is
which.  In fact we probably want to list all parents as supplies since
that's what they are, they just have special handling in the code due to
the recursion.

 These map 1:1 to how Linux currently implements regulators; which
 isn't exactly bad, but it means that even if Linux changes, we're
 still have to support this binding.  Does this represent the best
 layout for high level description of regulators?

 I guess, except for some like apply-uV, which like Mark pointed
 out are very linux/runtime policy specific.
 Mark, what do you think?

Yes, overall this feels far too direct.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data

2011-09-15 Thread Rajendra Nayak 
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure passed from device tree.
'consumer_supplies' which is part of regulator_init_data is not extracted
as the regulator consumer mappings are passed through DT differently,
implemented in subsequent patches.

Also add documentation for regulator bindings to be used to pass
regulator_init_data struct information from device tree.

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 .../devicetree/bindings/regulator/regulator.txt|   37 +
 drivers/of/Kconfig |6 ++
 drivers/of/Makefile|1 +
 drivers/of/of_regulator.c  |   85 
 include/linux/of_regulator.h   |   23 +
 5 files changed, 152 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
 create mode 100644 drivers/of/of_regulator.c
 create mode 100644 include/linux/of_regulator.h

diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt 
b/Documentation/devicetree/bindings/regulator/regulator.txt
new file mode 100644
index 000..001e5ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -0,0 +1,37 @@
+Voltage/Current Regulators
+
+Required properties:
+- compatible: Must be regulator;
+
+Optional properties:
+- supply-regulator: Name of the parent regulator
+- min-uV: smallest voltage consumers may set
+- max-uV: largest voltage consumers may set
+- uV-offset: Offset applied to voltages from consumer to compensate for 
voltage drops
+- min-uA: smallest current consumers may set
+- max-uA: largest current consumers may set
+- mode-fast: boolean, Can handle fast changes in its load
+- mode-normal: boolean, Normal regulator power supply mode
+- mode-idle: boolean, Can be more efficient during light loads
+- mode-standby: boolean, Can be most efficient during light loads
+- change-voltage: boolean, Output voltage can be changed by software
+- change-current: boolean, Output current can be chnaged by software
+- change-mode: boolean, Operating mode can be changed by software
+- change-status: boolean, Enable/Disable control for regulator exists
+- change-drms: boolean, Dynamic regulator mode switching is enabled
+- input-uV: Input voltage for regulator when supplied by another regulator
+- initial-mode: Mode to set at startup
+- always-on: boolean, regulator should never be disabled
+- boot-on: bootloader/firmware enabled regulator
+- apply-uV: apply uV constraint if min == max
+
+Example:
+
+   xyz-regulator: regulator@0 {
+   compatible = regulator;
+   min-uV = 100;
+   max-uV = 250;
+   mode-fast;
+   change-voltage;
+   always-on;
+   };
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index b3bfea5..296b96d 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -87,4 +87,10 @@ config OF_PCI_IRQ
help
  OpenFirmware PCI IRQ routing helpers
 
+config OF_REGULATOR
+   def_bool y
+   depends on REGULATOR
+   help
+ OpenFirmware regulator framework helpers
+
 endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 74b959c..bea2852 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SPI)  += of_spi.o
 obj-$(CONFIG_OF_MDIO)  += of_mdio.o
 obj-$(CONFIG_OF_PCI)   += of_pci.o
 obj-$(CONFIG_OF_PCI_IRQ)  += of_pci_irq.o
+obj-$(CONFIG_OF_REGULATOR) += of_regulator.o
diff --git a/drivers/of/of_regulator.c b/drivers/of/of_regulator.c
new file mode 100644
index 000..f01d275
--- /dev/null
+++ b/drivers/of/of_regulator.c
@@ -0,0 +1,85 @@
+/*
+ * OF helpers for regulator framework
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Rajendra Nayak rna...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/slab.h
+#include linux/of.h
+#include linux/regulator/machine.h
+
+static void of_get_regulation_constraints(struct device_node *np,
+   struct regulator_init_data **init_data)
+{
+   unsigned int valid_modes_mask = 0, valid_ops_mask = 0;
+
+   of_property_read_u32(np, min-uV, (*init_data)-constraints.min_uV);
+   of_property_read_u32(np, max-uV, (*init_data)-constraints.max_uV);
+   of_property_read_u32(np, uV-offset, 
(*init_data)-constraints.uV_offset);
+   of_property_read_u32(np, min-uA, (*init_data)-constraints.min_uA);
+   of_property_read_u32(np, max-uA, (*init_data)-constraints.max_uA);
+
+   /* valid modes mask */
+   if (of_find_property(np, mode-fast, NULL))
+   valid_modes_mask |= REGULATOR_MODE_FAST;
+

Re: [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data

2011-09-15 Thread Mark Brown 
On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote:

  .../devicetree/bindings/regulator/regulator.txt|   37 +
  drivers/of/Kconfig |6 ++
  drivers/of/Makefile|1 +
  drivers/of/of_regulator.c  |   85 
 
  include/linux/of_regulator.h   |   23 +

Don't go hiding the bindings for things away from the code they're
binding.  Bindings for the regualtor API are a regulator API thing and
should be part of the regulator API code.

 +Required properties:
 +- compatible: Must be regulator;

Is this idiomatic or should we just have a helper that parses a big list
of properties from the device node?

 +- mode-fast: boolean, Can handle fast changes in its load
 +- mode-normal: boolean, Normal regulator power supply mode
 +- mode-idle: boolean, Can be more efficient during light loads
 +- mode-standby: boolean, Can be most efficient during light loads

I guess these are actually permissions to set the given modes?  The
documentation should be clearer.

 +- apply-uV: apply uV constraint if min == max

This seems a bit Linux/runtime policy specific (especially the last
bit).
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data

2011-09-15 Thread Rob Herring 
On 09/15/2011 08:44 AM, Mark Brown wrote:
 On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote:
 
  .../devicetree/bindings/regulator/regulator.txt|   37 +
  drivers/of/Kconfig |6 ++
  drivers/of/Makefile|1 +
  drivers/of/of_regulator.c  |   85 
 
  include/linux/of_regulator.h   |   23 +
 
 Don't go hiding the bindings for things away from the code they're
 binding.  Bindings for the regualtor API are a regulator API thing and
 should be part of the regulator API code.
 

Agreed, but FYI not all subsystem maintainers agree. Moving of_i2c.c
into i2c was rejected.

Rob

 +Required properties:
 +- compatible: Must be regulator;
 
 Is this idiomatic or should we just have a helper that parses a big list
 of properties from the device node?
 
 +- mode-fast: boolean, Can handle fast changes in its load
 +- mode-normal: boolean, Normal regulator power supply mode
 +- mode-idle: boolean, Can be more efficient during light loads
 +- mode-standby: boolean, Can be most efficient during light loads
 
 I guess these are actually permissions to set the given modes?  The
 documentation should be clearer.
 
 +- apply-uV: apply uV constraint if min == max
 
 This seems a bit Linux/runtime policy specific (especially the last
 bit).
 ___
 devicetree-discuss mailing list
 devicetree-disc...@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/devicetree-discuss

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data

2011-09-15 Thread Rob Herring 
On 09/15/2011 06:21 AM, Rajendra Nayak wrote:
 The helper routine is meant to be used by regulator drivers
 to extract the regulator_init_data structure passed from device tree.
 'consumer_supplies' which is part of regulator_init_data is not extracted
 as the regulator consumer mappings are passed through DT differently,
 implemented in subsequent patches.
 
 Also add documentation for regulator bindings to be used to pass
 regulator_init_data struct information from device tree.
 
 Signed-off-by: Rajendra Nayak rna...@ti.com
 ---
  .../devicetree/bindings/regulator/regulator.txt|   37 +
  drivers/of/Kconfig |6 ++
  drivers/of/Makefile|1 +
  drivers/of/of_regulator.c  |   85 
 
  include/linux/of_regulator.h   |   23 +
  5 files changed, 152 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
  create mode 100644 drivers/of/of_regulator.c
  create mode 100644 include/linux/of_regulator.h
 
 diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt 
 b/Documentation/devicetree/bindings/regulator/regulator.txt
 new file mode 100644
 index 000..001e5ce
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/regulator/regulator.txt
 @@ -0,0 +1,37 @@
 +Voltage/Current Regulators
 +
 +Required properties:
 +- compatible: Must be regulator;

This is way too generic. compatible is not for matching a class of
devices. It is for matching a specific piece of h/w. So I would expect
names like wolfson,wm8350-dcdc.


 +
 +Optional properties:
 +- supply-regulator: Name of the parent regulator
 +- min-uV: smallest voltage consumers may set
 +- max-uV: largest voltage consumers may set
 +- uV-offset: Offset applied to voltages from consumer to compensate for 
 voltage drops
 +- min-uA: smallest current consumers may set
 +- max-uA: largest current consumers may set
 +- mode-fast: boolean, Can handle fast changes in its load
 +- mode-normal: boolean, Normal regulator power supply mode
 +- mode-idle: boolean, Can be more efficient during light loads
 +- mode-standby: boolean, Can be most efficient during light loads
 +- change-voltage: boolean, Output voltage can be changed by software
 +- change-current: boolean, Output current can be chnaged by software
 +- change-mode: boolean, Operating mode can be changed by software
 +- change-status: boolean, Enable/Disable control for regulator exists
 +- change-drms: boolean, Dynamic regulator mode switching is enabled
 +- input-uV: Input voltage for regulator when supplied by another regulator
 +- initial-mode: Mode to set at startup
 +- always-on: boolean, regulator should never be disabled
 +- boot-on: bootloader/firmware enabled regulator
 +- apply-uV: apply uV constraint if min == max
 +
 +Example:
 +
 + xyz-regulator: regulator@0 {
 + compatible = regulator;
 + min-uV = 100;
 + max-uV = 250;
 + mode-fast;
 + change-voltage;
 + always-on;
 + };

You need to show how a node references the regulator.

Rob

 diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
 index b3bfea5..296b96d 100644
 --- a/drivers/of/Kconfig
 +++ b/drivers/of/Kconfig
 @@ -87,4 +87,10 @@ config OF_PCI_IRQ
   help
 OpenFirmware PCI IRQ routing helpers
  
 +config OF_REGULATOR
 + def_bool y
 + depends on REGULATOR
 + help
 +   OpenFirmware regulator framework helpers
 +
  endmenu # OF
 diff --git a/drivers/of/Makefile b/drivers/of/Makefile
 index 74b959c..bea2852 100644
 --- a/drivers/of/Makefile
 +++ b/drivers/of/Makefile
 @@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SPI)+= of_spi.o
  obj-$(CONFIG_OF_MDIO)+= of_mdio.o
  obj-$(CONFIG_OF_PCI) += of_pci.o
  obj-$(CONFIG_OF_PCI_IRQ)  += of_pci_irq.o
 +obj-$(CONFIG_OF_REGULATOR) += of_regulator.o
 diff --git a/drivers/of/of_regulator.c b/drivers/of/of_regulator.c
 new file mode 100644
 index 000..f01d275
 --- /dev/null
 +++ b/drivers/of/of_regulator.c
 @@ -0,0 +1,85 @@
 +/*
 + * OF helpers for regulator framework
 + *
 + * Copyright (C) 2011 Texas Instruments, Inc.
 + * Rajendra Nayak rna...@ti.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + */
 +
 +#include linux/slab.h
 +#include linux/of.h
 +#include linux/regulator/machine.h
 +
 +static void of_get_regulation_constraints(struct device_node *np,
 + struct regulator_init_data **init_data)
 +{
 + unsigned int valid_modes_mask = 0, valid_ops_mask = 0;
 +
 + of_property_read_u32(np, min-uV, (*init_data)-constraints.min_uV);
 + of_property_read_u32(np, max-uV, (*init_data)-constraints.max_uV);
 +

Re: [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data

2011-09-15 Thread Grant Likely 
On Thu, Sep 15, 2011 at 04:51:59PM +0530, Rajendra Nayak wrote:
 The helper routine is meant to be used by regulator drivers
 to extract the regulator_init_data structure passed from device tree.
 'consumer_supplies' which is part of regulator_init_data is not extracted
 as the regulator consumer mappings are passed through DT differently,
 implemented in subsequent patches.
 
 Also add documentation for regulator bindings to be used to pass
 regulator_init_data struct information from device tree.
 
 Signed-off-by: Rajendra Nayak rna...@ti.com
 ---
  .../devicetree/bindings/regulator/regulator.txt|   37 +
  drivers/of/Kconfig |6 ++
  drivers/of/Makefile|1 +
  drivers/of/of_regulator.c  |   85 
 

I originally put the DT stuff under drivers/of for i2c and spi because
there was resistance from driver subsystem maintainers to having code
for something that was powerpc only.  Now that it is no longer the
case, I recommend putting this code under drivers/regulator.

  include/linux/of_regulator.h   |   23 +
  5 files changed, 152 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
  create mode 100644 drivers/of/of_regulator.c
  create mode 100644 include/linux/of_regulator.h
 
 diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt 
 b/Documentation/devicetree/bindings/regulator/regulator.txt
 new file mode 100644
 index 000..001e5ce
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/regulator/regulator.txt
 @@ -0,0 +1,37 @@
 +Voltage/Current Regulators
 +
 +Required properties:
 +- compatible: Must be regulator;

A regulator compatible doesn't actually help much.  Compatible is
for specifying the specific device, not for trying to describe what
kind of device it is.  Instead, specific regulator bindings can adopt
 extend this binding.

 +
 +Optional properties:
 +- supply-regulator: Name of the parent regulator

If this is a reference to another regulator node then don't use names.
Use phandles instead.  In which case it should probably be named
something like regulator-parent (similar to interrupt parent).

However, I can imagine it possible for a regulator to have multiple
parents.  It may just be better to go with something like the gpio
scheme of phandle gpio-specifier list of entries.  Or maybe just a
list of phandles would be sufficient.

 +- min-uV: smallest voltage consumers may set
 +- max-uV: largest voltage consumers may set
 +- uV-offset: Offset applied to voltages from consumer to compensate for 
 voltage drops
 +- min-uA: smallest current consumers may set
 +- max-uA: largest current consumers may set
 +- mode-fast: boolean, Can handle fast changes in its load
 +- mode-normal: boolean, Normal regulator power supply mode
 +- mode-idle: boolean, Can be more efficient during light loads
 +- mode-standby: boolean, Can be most efficient during light loads
 +- change-voltage: boolean, Output voltage can be changed by software
 +- change-current: boolean, Output current can be chnaged by software
 +- change-mode: boolean, Operating mode can be changed by software
 +- change-status: boolean, Enable/Disable control for regulator exists
 +- change-drms: boolean, Dynamic regulator mode switching is enabled
 +- input-uV: Input voltage for regulator when supplied by another regulator
 +- initial-mode: Mode to set at startup
 +- always-on: boolean, regulator should never be disabled
 +- boot-on: bootloader/firmware enabled regulator
 +- apply-uV: apply uV constraint if min == max

To avoid collisions, I'd prefix all of these with a common prefix.
Something like regulator-*.

These map 1:1 to how Linux currently implements regulators; which
isn't exactly bad, but it means that even if Linux changes, we're
still have to support this binding.  Does this represent the best
layout for high level description of regulators?

 +
 +Example:
 +
 + xyz-regulator: regulator@0 {
 + compatible = regulator;
 + min-uV = 100;
 + max-uV = 250;
 + mode-fast;
 + change-voltage;
 + always-on;
 + };
 diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
 index b3bfea5..296b96d 100644
 --- a/drivers/of/Kconfig
 +++ b/drivers/of/Kconfig
 @@ -87,4 +87,10 @@ config OF_PCI_IRQ
   help
 OpenFirmware PCI IRQ routing helpers
  
 +config OF_REGULATOR
 + def_bool y
 + depends on REGULATOR
 + help
 +   OpenFirmware regulator framework helpers
 +
  endmenu # OF
 diff --git a/drivers/of/Makefile b/drivers/of/Makefile
 index 74b959c..bea2852 100644
 --- a/drivers/of/Makefile
 +++ b/drivers/of/Makefile
 @@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SPI)+= of_spi.o
  obj-$(CONFIG_OF_MDIO)+= of_mdio.o
  obj-$(CONFIG_OF_PCI) += of_pci.o
  obj-$(CONFIG_OF_PCI_IRQ)  += of_pci_irq.o