* [PATCH 0/9] Device tree support for regulators
@ 2011-09-27 10:12 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: broonie, grant.likely
Cc: devicetree-discuss, linux-omap, linux-arm-kernel, tony, lrg,
b-cousson, patches, Rajendra Nayak
Hi Mark, Grant,
This is a respin of my RFC series I posted sometime back
and is now based on top of the latest omap i2c-twl support
series posted by Benoit
git://gitorious.org/omap-pm/linux.git for_3.2/4_omap_dt_i2c_twl
some changes done since the RFC:
1. twl driver fixed to remove hardcoded board params
2. regulator helpers moved from drivers/of to drivers/regulator
3. Better compatible definitions for specific device type
4. twl regulator driver doing internal table lookup based on
compatible rather then pdev->id
5. Seperate fixed voltage regulator bindings defined
6. Changed the way devices associate with regulators
i.e using <name>-supply = <®ulator-phandle>;
regards,
Rajendra
Rajendra Nayak (9):
regulator: twl: Remove hardcoded board constraints from driver
regulator: helper routine to extract regulator_init_data
omap4: sdp: Pass regulator data from dt
regulator: twl: Make twl-regulator driver extract data from DT
regulator: helper routine to extract fixed_voltage_config
regulator: make fixed regulator driver extract data from dt
omap4: panda: Pass regulator data from DT
regulator: helper to extract regulator node based on supply name
regulator: map consumer regulator based on device tree
.../bindings/regulator/fixed-regulator.txt | 24 ++++
.../devicetree/bindings/regulator/regulator.txt | 42 +++++++
.../bindings/regulator/twl-regulator.txt | 60 +++++++++
arch/arm/boot/dts/omap4-panda.dts | 54 ++++++++
arch/arm/boot/dts/omap4-sdp.dts | 64 ++++++++++
drivers/regulator/Kconfig | 7 +
drivers/regulator/Makefile | 1 +
drivers/regulator/core.c | 14 ++
drivers/regulator/fixed.c | 54 ++++++++-
drivers/regulator/of_regulator.c | 127 ++++++++++++++++++++
drivers/regulator/twl-regulator.c | 125 ++++++++++++--------
include/linux/regulator/driver.h | 3 +
include/linux/regulator/fixed.h | 6 +-
include/linux/regulator/machine.h | 12 +-
include/linux/regulator/of_regulator.h | 28 +++++
15 files changed, 562 insertions(+), 59 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/fixed-regulator.txt
create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
create mode 100644 Documentation/devicetree/bindings/regulator/twl-regulator.txt
create mode 100644 drivers/regulator/of_regulator.c
create mode 100644 include/linux/regulator/of_regulator.h
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 0/9] Device tree support for regulators
@ 2011-09-27 10:12 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mark, Grant,
This is a respin of my RFC series I posted sometime back
and is now based on top of the latest omap i2c-twl support
series posted by Benoit
git://gitorious.org/omap-pm/linux.git for_3.2/4_omap_dt_i2c_twl
some changes done since the RFC:
1. twl driver fixed to remove hardcoded board params
2. regulator helpers moved from drivers/of to drivers/regulator
3. Better compatible definitions for specific device type
4. twl regulator driver doing internal table lookup based on
compatible rather then pdev->id
5. Seperate fixed voltage regulator bindings defined
6. Changed the way devices associate with regulators
i.e using <name>-supply = <®ulator-phandle>;
regards,
Rajendra
Rajendra Nayak (9):
regulator: twl: Remove hardcoded board constraints from driver
regulator: helper routine to extract regulator_init_data
omap4: sdp: Pass regulator data from dt
regulator: twl: Make twl-regulator driver extract data from DT
regulator: helper routine to extract fixed_voltage_config
regulator: make fixed regulator driver extract data from dt
omap4: panda: Pass regulator data from DT
regulator: helper to extract regulator node based on supply name
regulator: map consumer regulator based on device tree
.../bindings/regulator/fixed-regulator.txt | 24 ++++
.../devicetree/bindings/regulator/regulator.txt | 42 +++++++
.../bindings/regulator/twl-regulator.txt | 60 +++++++++
arch/arm/boot/dts/omap4-panda.dts | 54 ++++++++
arch/arm/boot/dts/omap4-sdp.dts | 64 ++++++++++
drivers/regulator/Kconfig | 7 +
drivers/regulator/Makefile | 1 +
drivers/regulator/core.c | 14 ++
drivers/regulator/fixed.c | 54 ++++++++-
drivers/regulator/of_regulator.c | 127 ++++++++++++++++++++
drivers/regulator/twl-regulator.c | 125 ++++++++++++--------
include/linux/regulator/driver.h | 3 +
include/linux/regulator/fixed.h | 6 +-
include/linux/regulator/machine.h | 12 +-
include/linux/regulator/of_regulator.h | 28 +++++
15 files changed, 562 insertions(+), 59 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/fixed-regulator.txt
create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
create mode 100644 Documentation/devicetree/bindings/regulator/twl-regulator.txt
create mode 100644 drivers/regulator/of_regulator.c
create mode 100644 include/linux/regulator/of_regulator.h
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 1/9] regulator: twl: Remove hardcoded board constraints from driver
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-27 10:12 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: broonie, grant.likely
Cc: devicetree-discuss, linux-omap, linux-arm-kernel, tony, lrg,
b-cousson, patches, Rajendra Nayak
Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
each regulator from the twl driver and let the boards pass it.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
drivers/regulator/twl-regulator.c | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c b/drivers/regulator/twl-regulator.c
index ee8747f..f696287 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -1027,14 +1027,6 @@ static int __devinit twlreg_probe(struct platform_device *pdev)
/* copy the features into regulator data */
info->features = (unsigned long)initdata->driver_data;
- /* Constrain board-specific capabilities according to what
- * this driver and the chip itself can actually do.
- */
- c = &initdata->constraints;
- c->valid_modes_mask &= REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY;
- c->valid_ops_mask &= REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS;
switch (pdev->id) {
case TWL4030_REG_VIO:
case TWL4030_REG_VDD1:
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 1/9] regulator: twl: Remove hardcoded board constraints from driver
@ 2011-09-27 10:12 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
each regulator from the twl driver and let the boards pass it.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
drivers/regulator/twl-regulator.c | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c b/drivers/regulator/twl-regulator.c
index ee8747f..f696287 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -1027,14 +1027,6 @@ static int __devinit twlreg_probe(struct platform_device *pdev)
/* copy the features into regulator data */
info->features = (unsigned long)initdata->driver_data;
- /* Constrain board-specific capabilities according to what
- * this driver and the chip itself can actually do.
- */
- c = &initdata->constraints;
- c->valid_modes_mask &= REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY;
- c->valid_ops_mask &= REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS;
switch (pdev->id) {
case TWL4030_REG_VIO:
case TWL4030_REG_VDD1:
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-27 10:12 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: broonie, grant.likely
Cc: devicetree-discuss, linux-omap, linux-arm-kernel, tony, lrg,
b-cousson, patches, Rajendra Nayak
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure from the data
that is 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 <rnayak@ti.com>
---
.../devicetree/bindings/regulator/regulator.txt | 42 +++++++++
drivers/regulator/Kconfig | 7 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/of_regulator.c | 88 ++++++++++++++++++++
include/linux/regulator/machine.h | 12 ++--
include/linux/regulator/of_regulator.h | 21 +++++
6 files changed, 165 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
create mode 100644 drivers/regulator/of_regulator.c
create mode 100644 include/linux/regulator/of_regulator.h
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
new file mode 100644
index 0000000..91b8d8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -0,0 +1,42 @@
+Voltage/Current Regulators
+
+Optional properties:
+- regulator-supplies: Names of the regulator supplies
+- regulator-min-uV: smallest voltage consumers may set
+- regulator-max-uV: largest voltage consumers may set
+- regulator-uV-offset: Offset applied to voltages to compensate for voltage drops
+- regulator-min-uA: smallest current consumers may set
+- regulator-max-uA: largest current consumers may set
+- regulator-change-voltage: boolean, Output voltage can be changed by software
+- regulator-change-current: boolean, Output current can be chnaged by software
+- regulator-change-mode: boolean, Operating mode can be changed by software
+- regulator-change-status: boolean, Enable/Disable control for regulator exists
+- regulator-change-drms: boolean, Dynamic regulator mode switching is enabled
+- regulator-mode-fast: boolean, allow/set fast mode for the regulator
+- regulator-mode-normal: boolean, allow/set normal mode for the regulator
+- regulator-mode-idle: boolean, allow/set idle mode for the regulator
+- regulator-mode-standby: boolean, allow/set standby mode for the regulator
+- regulator-input-uV: Input voltage for regulator when supplied by another regulator
+- regulator-always-on: boolean, regulator should never be disabled
+- regulator-boot-on: bootloader/firmware enabled regulator
+
+Example:
+
+ xyzreg: regulator@0 {
+ regulator-min-uV = <1000000>;
+ regulator-max-uV = <2500000>;
+ regulator-mode-fast;
+ regulator-change-voltage;
+ regulator-always-on;
+ };
+
+Example of a device node referencing a regulator node:
+
+ devicenode: node@0x0 {
+ ...
+ ...
+ <name>-supply = <&xyzreg>;
+ };
+
+ where <name> is the supply name or regulator id passed
+ as part of regulator_get(dev, <name>);
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c7fd2c0..2b684aa 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -64,6 +64,13 @@ config REGULATOR_USERSPACE_CONSUMER
If unsure, say no.
+config OF_REGULATOR
+ tristate "OF regulator helpers"
+ depends on OF
+ help
+ OpenFirmware regulator framework helper routines that can
+ used by regulator drivers to extract data from device tree.
+
config REGULATOR_BQ24022
tristate "TI bq24022 Dual Input 1-Cell Li-Ion Charger IC"
help
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 040d5aa..e6bc009 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_REGULATOR) += core.o dummy.o
obj-$(CONFIG_REGULATOR_FIXED_VOLTAGE) += fixed.o
obj-$(CONFIG_REGULATOR_VIRTUAL_CONSUMER) += virtual.o
obj-$(CONFIG_REGULATOR_USERSPACE_CONSUMER) += userspace-consumer.o
+obj-$(CONFIG_OF_REGULATOR) += of_regulator.o
obj-$(CONFIG_REGULATOR_AD5398) += ad5398.o
obj-$(CONFIG_REGULATOR_BQ24022) += bq24022.o
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
new file mode 100644
index 0000000..7fa63ff
--- /dev/null
+++ b/drivers/regulator/of_regulator.c
@@ -0,0 +1,88 @@
+/*
+ * OF helpers for regulator framework
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Rajendra Nayak <rnayak@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, "regulator-min-uV",
+ &(*init_data)->constraints.min_uV);
+ of_property_read_u32(np, "regulator-max-uV",
+ &(*init_data)->constraints.max_uV);
+ of_property_read_u32(np, "regulator-uV-offset",
+ &(*init_data)->constraints.uV_offset);
+ of_property_read_u32(np, "regulator-min-uA",
+ &(*init_data)->constraints.min_uA);
+ of_property_read_u32(np, "regulator-max-uA",
+ &(*init_data)->constraints.max_uA);
+ of_property_read_u32(np, "regulator-input-uV",
+ &(*init_data)->constraints.input_uV);
+
+ /* valid modes mask */
+ if (of_find_property(np, "regulator-mode-fast", NULL))
+ valid_modes_mask |= REGULATOR_MODE_FAST;
+ if (of_find_property(np, "regulator-mode-normal", NULL))
+ valid_modes_mask |= REGULATOR_MODE_NORMAL;
+ if (of_find_property(np, "regulator-mode-idle", NULL))
+ valid_modes_mask |= REGULATOR_MODE_IDLE;
+ if (of_find_property(np, "regulator-mode-standby", NULL))
+ valid_modes_mask |= REGULATOR_MODE_STANDBY;
+
+ /* valid ops mask */
+ if (of_find_property(np, "regulator-change-voltage", NULL))
+ valid_ops_mask |= REGULATOR_CHANGE_VOLTAGE;
+ if (of_find_property(np, "regulator-change-current", NULL))
+ valid_ops_mask |= REGULATOR_CHANGE_CURRENT;
+ if (of_find_property(np, "regulator-change-mode", NULL))
+ valid_ops_mask |= REGULATOR_CHANGE_MODE;
+ if (of_find_property(np, "regulator-change-status", NULL))
+ valid_ops_mask |= REGULATOR_CHANGE_STATUS;
+
+ (*init_data)->constraints.valid_modes_mask = valid_modes_mask;
+ (*init_data)->constraints.valid_ops_mask = valid_ops_mask;
+
+ if (of_find_property(np, "regulator-always-on", NULL))
+ (*init_data)->constraints.always_on = true;
+ if (of_find_property(np, "regulator-boot-on", NULL))
+ (*init_data)->constraints.boot_on = true;
+}
+
+/**
+ * of_get_regulator_init_data - extract regulator_init_data structure info
+ * @dev: device requesting for regulator_init_data
+ *
+ * Populates regulator_init_data structure by extracting data from device
+ * tree node, returns a pointer to the populated struture or NULL if memory
+ * alloc fails.
+ */
+struct regulator_init_data *of_get_regulator_init_data(struct device *dev)
+{
+ struct regulator_init_data *init_data;
+
+ if (!dev->of_node)
+ return NULL;
+
+ init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
+ GFP_KERNEL);
+ if (!init_data)
+ return NULL; /* Out of memory? */
+
+ init_data->supply_regulator = (char *)of_get_property(dev->of_node,
+ "regulator-supplies", NULL);
+ of_get_regulation_constraints(dev->of_node, &init_data);
+ return init_data;
+}
diff --git a/include/linux/regulator/machine.h b/include/linux/regulator/machine.h
index ce3127a..d2d921b 100644
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -98,14 +98,14 @@ struct regulation_constraints {
char *name;
/* voltage output range (inclusive) - for voltage control */
- int min_uV;
- int max_uV;
+ u32 min_uV;
+ u32 max_uV;
- int uV_offset;
+ u32 uV_offset;
/* current output range (inclusive) - for current control */
- int min_uA;
- int max_uA;
+ u32 min_uA;
+ u32 max_uA;
/* valid regulator operating modes for this machine */
unsigned int valid_modes_mask;
@@ -114,7 +114,7 @@ struct regulation_constraints {
unsigned int valid_ops_mask;
/* regulator input voltage - only if supply is another regulator */
- int input_uV;
+ u32 input_uV;
/* regulator suspend states for global PMIC STANDBY/HIBERNATE */
struct regulator_state state_disk;
diff --git a/include/linux/regulator/of_regulator.h b/include/linux/regulator/of_regulator.h
new file mode 100644
index 0000000..3f63be9
--- /dev/null
+++ b/include/linux/regulator/of_regulator.h
@@ -0,0 +1,21 @@
+/*
+ * OpenFirmware regulator support routines
+ *
+ */
+
+#ifndef __LINUX_OF_REG_H
+#define __LINUX_OF_REG_H
+
+#if defined(CONFIG_OF_REGULATOR)
+extern struct regulator_init_data
+ *of_get_regulator_init_data(struct device *dev);
+#else
+static inline struct regulator_init_data
+ *of_get_regulator_init_data(struct device_node *np)
+{
+ return NULL;
+}
+#endif /* CONFIG_OF_REGULATOR */
+
+#endif /* __LINUX_OF_REG_H */
+
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-09-27 10:12 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: linux-arm-kernel
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure from the data
that is 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 <rnayak@ti.com>
---
.../devicetree/bindings/regulator/regulator.txt | 42 +++++++++
drivers/regulator/Kconfig | 7 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/of_regulator.c | 88 ++++++++++++++++++++
include/linux/regulator/machine.h | 12 ++--
include/linux/regulator/of_regulator.h | 21 +++++
6 files changed, 165 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
create mode 100644 drivers/regulator/of_regulator.c
create mode 100644 include/linux/regulator/of_regulator.h
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
new file mode 100644
index 0000000..91b8d8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -0,0 +1,42 @@
+Voltage/Current Regulators
+
+Optional properties:
+- regulator-supplies: Names of the regulator supplies
+- regulator-min-uV: smallest voltage consumers may set
+- regulator-max-uV: largest voltage consumers may set
+- regulator-uV-offset: Offset applied to voltages to compensate for voltage drops
+- regulator-min-uA: smallest current consumers may set
+- regulator-max-uA: largest current consumers may set
+- regulator-change-voltage: boolean, Output voltage can be changed by software
+- regulator-change-current: boolean, Output current can be chnaged by software
+- regulator-change-mode: boolean, Operating mode can be changed by software
+- regulator-change-status: boolean, Enable/Disable control for regulator exists
+- regulator-change-drms: boolean, Dynamic regulator mode switching is enabled
+- regulator-mode-fast: boolean, allow/set fast mode for the regulator
+- regulator-mode-normal: boolean, allow/set normal mode for the regulator
+- regulator-mode-idle: boolean, allow/set idle mode for the regulator
+- regulator-mode-standby: boolean, allow/set standby mode for the regulator
+- regulator-input-uV: Input voltage for regulator when supplied by another regulator
+- regulator-always-on: boolean, regulator should never be disabled
+- regulator-boot-on: bootloader/firmware enabled regulator
+
+Example:
+
+ xyzreg: regulator at 0 {
+ regulator-min-uV = <1000000>;
+ regulator-max-uV = <2500000>;
+ regulator-mode-fast;
+ regulator-change-voltage;
+ regulator-always-on;
+ };
+
+Example of a device node referencing a regulator node:
+
+ devicenode: node at 0x0 {
+ ...
+ ...
+ <name>-supply = <&xyzreg>;
+ };
+
+ where <name> is the supply name or regulator id passed
+ as part of regulator_get(dev, <name>);
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c7fd2c0..2b684aa 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -64,6 +64,13 @@ config REGULATOR_USERSPACE_CONSUMER
If unsure, say no.
+config OF_REGULATOR
+ tristate "OF regulator helpers"
+ depends on OF
+ help
+ OpenFirmware regulator framework helper routines that can
+ used by regulator drivers to extract data from device tree.
+
config REGULATOR_BQ24022
tristate "TI bq24022 Dual Input 1-Cell Li-Ion Charger IC"
help
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 040d5aa..e6bc009 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_REGULATOR) += core.o dummy.o
obj-$(CONFIG_REGULATOR_FIXED_VOLTAGE) += fixed.o
obj-$(CONFIG_REGULATOR_VIRTUAL_CONSUMER) += virtual.o
obj-$(CONFIG_REGULATOR_USERSPACE_CONSUMER) += userspace-consumer.o
+obj-$(CONFIG_OF_REGULATOR) += of_regulator.o
obj-$(CONFIG_REGULATOR_AD5398) += ad5398.o
obj-$(CONFIG_REGULATOR_BQ24022) += bq24022.o
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
new file mode 100644
index 0000000..7fa63ff
--- /dev/null
+++ b/drivers/regulator/of_regulator.c
@@ -0,0 +1,88 @@
+/*
+ * OF helpers for regulator framework
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Rajendra Nayak <rnayak@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, "regulator-min-uV",
+ &(*init_data)->constraints.min_uV);
+ of_property_read_u32(np, "regulator-max-uV",
+ &(*init_data)->constraints.max_uV);
+ of_property_read_u32(np, "regulator-uV-offset",
+ &(*init_data)->constraints.uV_offset);
+ of_property_read_u32(np, "regulator-min-uA",
+ &(*init_data)->constraints.min_uA);
+ of_property_read_u32(np, "regulator-max-uA",
+ &(*init_data)->constraints.max_uA);
+ of_property_read_u32(np, "regulator-input-uV",
+ &(*init_data)->constraints.input_uV);
+
+ /* valid modes mask */
+ if (of_find_property(np, "regulator-mode-fast", NULL))
+ valid_modes_mask |= REGULATOR_MODE_FAST;
+ if (of_find_property(np, "regulator-mode-normal", NULL))
+ valid_modes_mask |= REGULATOR_MODE_NORMAL;
+ if (of_find_property(np, "regulator-mode-idle", NULL))
+ valid_modes_mask |= REGULATOR_MODE_IDLE;
+ if (of_find_property(np, "regulator-mode-standby", NULL))
+ valid_modes_mask |= REGULATOR_MODE_STANDBY;
+
+ /* valid ops mask */
+ if (of_find_property(np, "regulator-change-voltage", NULL))
+ valid_ops_mask |= REGULATOR_CHANGE_VOLTAGE;
+ if (of_find_property(np, "regulator-change-current", NULL))
+ valid_ops_mask |= REGULATOR_CHANGE_CURRENT;
+ if (of_find_property(np, "regulator-change-mode", NULL))
+ valid_ops_mask |= REGULATOR_CHANGE_MODE;
+ if (of_find_property(np, "regulator-change-status", NULL))
+ valid_ops_mask |= REGULATOR_CHANGE_STATUS;
+
+ (*init_data)->constraints.valid_modes_mask = valid_modes_mask;
+ (*init_data)->constraints.valid_ops_mask = valid_ops_mask;
+
+ if (of_find_property(np, "regulator-always-on", NULL))
+ (*init_data)->constraints.always_on = true;
+ if (of_find_property(np, "regulator-boot-on", NULL))
+ (*init_data)->constraints.boot_on = true;
+}
+
+/**
+ * of_get_regulator_init_data - extract regulator_init_data structure info
+ * @dev: device requesting for regulator_init_data
+ *
+ * Populates regulator_init_data structure by extracting data from device
+ * tree node, returns a pointer to the populated struture or NULL if memory
+ * alloc fails.
+ */
+struct regulator_init_data *of_get_regulator_init_data(struct device *dev)
+{
+ struct regulator_init_data *init_data;
+
+ if (!dev->of_node)
+ return NULL;
+
+ init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
+ GFP_KERNEL);
+ if (!init_data)
+ return NULL; /* Out of memory? */
+
+ init_data->supply_regulator = (char *)of_get_property(dev->of_node,
+ "regulator-supplies", NULL);
+ of_get_regulation_constraints(dev->of_node, &init_data);
+ return init_data;
+}
diff --git a/include/linux/regulator/machine.h b/include/linux/regulator/machine.h
index ce3127a..d2d921b 100644
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -98,14 +98,14 @@ struct regulation_constraints {
char *name;
/* voltage output range (inclusive) - for voltage control */
- int min_uV;
- int max_uV;
+ u32 min_uV;
+ u32 max_uV;
- int uV_offset;
+ u32 uV_offset;
/* current output range (inclusive) - for current control */
- int min_uA;
- int max_uA;
+ u32 min_uA;
+ u32 max_uA;
/* valid regulator operating modes for this machine */
unsigned int valid_modes_mask;
@@ -114,7 +114,7 @@ struct regulation_constraints {
unsigned int valid_ops_mask;
/* regulator input voltage - only if supply is another regulator */
- int input_uV;
+ u32 input_uV;
/* regulator suspend states for global PMIC STANDBY/HIBERNATE */
struct regulator_state state_disk;
diff --git a/include/linux/regulator/of_regulator.h b/include/linux/regulator/of_regulator.h
new file mode 100644
index 0000000..3f63be9
--- /dev/null
+++ b/include/linux/regulator/of_regulator.h
@@ -0,0 +1,21 @@
+/*
+ * OpenFirmware regulator support routines
+ *
+ */
+
+#ifndef __LINUX_OF_REG_H
+#define __LINUX_OF_REG_H
+
+#if defined(CONFIG_OF_REGULATOR)
+extern struct regulator_init_data
+ *of_get_regulator_init_data(struct device *dev);
+#else
+static inline struct regulator_init_data
+ *of_get_regulator_init_data(struct device_node *np)
+{
+ return NULL;
+}
+#endif /* CONFIG_OF_REGULATOR */
+
+#endif /* __LINUX_OF_REG_H */
+
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 3/9] omap4: sdp: Pass regulator data from dt
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-27 10:12 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: broonie, grant.likely
Cc: devicetree-discuss, linux-omap, linux-arm-kernel, tony, lrg,
b-cousson, patches, Rajendra Nayak
Pass adjustable regulator information for omap4sdp from device tree so the
regulator driver can then use the regulator helper
routine to extract and use them during the driver probe().
Also add documentation for TWL regulator specific bindings.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
.../bindings/regulator/twl-regulator.txt | 60 ++++++++++++++++++
arch/arm/boot/dts/omap4-sdp.dts | 64 ++++++++++++++++++++
2 files changed, 124 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/twl-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
new file mode 100644
index 0000000..7b809ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -0,0 +1,60 @@
+TWL family of regulators
+
+Required properties:
+- compatible:
+ - "ti,twl4030" for twl4030 regulators
+ - "ti,twl6025" for twl6025 regulators
+ - "ti,twl6030" for twl6030 regulators
+
+Additionally compatible can be used to specify the
+exact regulator/ldo instance like
+For twl6030 regulators/LDO's
+- compatible:
+ - "ti,twl6030-vaux1" for VAUX1 LDO
+ - "ti,twl6030-vaux2" for VAUX2 LDO
+ - "ti,twl6030-vaux3" for VAUX3 LDO
+ - "ti,twl6030-vmmc" for VMMC LDO
+ - "ti,twl6030-vpp" for VPP LDO
+ - "ti,twl6030-vusim" for VUSIM LDO
+For twl6025 regulators/LDO's
+- compatible:
+ - "ti,twl6025-ldo1" for LDO1 LDO
+ - "ti,twl6025-ldo2" for LDO2 LDO
+ - "ti,twl6025-ldo3" for LDO3 LDO
+ - "ti,twl6025-ldo4" for LDO4 LDO
+ - "ti,twl6025-ldo5" for LDO5 LDO
+ - "ti,twl6025-ldo6" for LDO6 LDO
+ - "ti,twl6025-ldo7" for LDO7 LDO
+ - "ti,twl6025-ldoln" for LDOLN LDO
+ - "ti,twl6025-ldousb" for LDOUSB LDO
+For twl4030 regulators/LDO's
+- compatible:
+ - "ti,twl4030-vaux1" for VAUX1 LDO
+ - "ti,twl4030-vaux2" for VAUX2 LDO
+ - "ti,twl5030-vaux2" for VAUX2 LDO
+ - "ti,twl4030-vaux3" for VAUX3 LDO
+ - "ti,twl4030-vaux4" for VAUX4 LDO
+ - "ti,twl4030-vmmc1" for VMMC1 LDO
+ - "ti,twl4030-vmmc2" for VMMC2 LDO
+ - "ti,twl4030-vpll1" for VPLL1 LDO
+ - "ti,twl4030-vpll2" for VPLL2 LDO
+ - "ti,twl4030-vsim" for VSIM LDO
+ - "ti,twl4030-vdac" for VDAC LDO
+ - "ti,twl4030-vintana2" for VINTANA2 LDO
+ - "ti,twl4030-vio" for VIO LDO
+ - "ti,twl4030-vdd1" for VDD1 LDO
+ - "ti,twl4030-vdd2" for VDD2 LDO
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+
+ xyz: regulator@0 {
+ compatible = "ti,twl6030-vaux1","ti,twl6030";
+ regulator-min_uV = <1000000>;
+ regulator-max_uV = <3000000>;
+ regulator-more-normal;
+ regulator-mode-standby;
+ regulator-change-voltage;
+ };
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 2990841..edbf77e 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -48,6 +48,70 @@
compatible = "ti,twl4030-rtc";
interrupts = <11>;
};
+
+ vaux1: regulator@0 {
+ compatible = "ti,twl6030-vaux1","ti,twl6030";
+ regulator-min-uV = <1000000>;
+ regulator-max-uV = <3000000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-voltage;
+ regulator-change-mode;
+ };
+
+ vaux2: regulator@1 {
+ compatible = "ti,twl6030-vaux2","ti,twl6030";
+ regulator-min-uV = <1200000>;
+ regulator-max-uV = <2800000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-mode;
+ regulator-change-status;
+ regulator-change-voltage;
+ };
+
+ vaux3: regulator@2 {
+ compatible = "ti,twl6030-vaux3","ti,twl6030";
+ regulator-min-uV = <1000000>;
+ regulator-max-uV = <3000000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-mode;
+ regulator-change-status;
+ regulator-change-voltage;
+ };
+
+ vmmc: regulator@3 {
+ compatible = "ti,twl6030-vmmc","ti,twl6030";
+ regulator-min-uV = <1200000>;
+ regulator-max-uV = <3000000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-mode;
+ regulator-change-status;
+ regulator-change-voltage;
+ };
+
+ vpp: regulator@4 {
+ compatible = "ti,twl6030-vpp","ti,twl6030";
+ regulator-min-uV = <1800000>;
+ regulator-max-uV = <2500000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-mode;
+ regulator-change-status;
+ regulator-change-voltage;
+ };
+
+ vusim: regulator@5 {
+ compatible = "ti,twl6030-vusim","ti,twl6030";
+ regulator-min-uV = <1200000>;
+ regulator-max-uV = <2900000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-voltage;
+ regulator-change-mode;
+ };
};
};
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 3/9] omap4: sdp: Pass regulator data from dt
@ 2011-09-27 10:12 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Pass adjustable regulator information for omap4sdp from device tree so the
regulator driver can then use the regulator helper
routine to extract and use them during the driver probe().
Also add documentation for TWL regulator specific bindings.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
.../bindings/regulator/twl-regulator.txt | 60 ++++++++++++++++++
arch/arm/boot/dts/omap4-sdp.dts | 64 ++++++++++++++++++++
2 files changed, 124 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/twl-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
new file mode 100644
index 0000000..7b809ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -0,0 +1,60 @@
+TWL family of regulators
+
+Required properties:
+- compatible:
+ - "ti,twl4030" for twl4030 regulators
+ - "ti,twl6025" for twl6025 regulators
+ - "ti,twl6030" for twl6030 regulators
+
+Additionally compatible can be used to specify the
+exact regulator/ldo instance like
+For twl6030 regulators/LDO's
+- compatible:
+ - "ti,twl6030-vaux1" for VAUX1 LDO
+ - "ti,twl6030-vaux2" for VAUX2 LDO
+ - "ti,twl6030-vaux3" for VAUX3 LDO
+ - "ti,twl6030-vmmc" for VMMC LDO
+ - "ti,twl6030-vpp" for VPP LDO
+ - "ti,twl6030-vusim" for VUSIM LDO
+For twl6025 regulators/LDO's
+- compatible:
+ - "ti,twl6025-ldo1" for LDO1 LDO
+ - "ti,twl6025-ldo2" for LDO2 LDO
+ - "ti,twl6025-ldo3" for LDO3 LDO
+ - "ti,twl6025-ldo4" for LDO4 LDO
+ - "ti,twl6025-ldo5" for LDO5 LDO
+ - "ti,twl6025-ldo6" for LDO6 LDO
+ - "ti,twl6025-ldo7" for LDO7 LDO
+ - "ti,twl6025-ldoln" for LDOLN LDO
+ - "ti,twl6025-ldousb" for LDOUSB LDO
+For twl4030 regulators/LDO's
+- compatible:
+ - "ti,twl4030-vaux1" for VAUX1 LDO
+ - "ti,twl4030-vaux2" for VAUX2 LDO
+ - "ti,twl5030-vaux2" for VAUX2 LDO
+ - "ti,twl4030-vaux3" for VAUX3 LDO
+ - "ti,twl4030-vaux4" for VAUX4 LDO
+ - "ti,twl4030-vmmc1" for VMMC1 LDO
+ - "ti,twl4030-vmmc2" for VMMC2 LDO
+ - "ti,twl4030-vpll1" for VPLL1 LDO
+ - "ti,twl4030-vpll2" for VPLL2 LDO
+ - "ti,twl4030-vsim" for VSIM LDO
+ - "ti,twl4030-vdac" for VDAC LDO
+ - "ti,twl4030-vintana2" for VINTANA2 LDO
+ - "ti,twl4030-vio" for VIO LDO
+ - "ti,twl4030-vdd1" for VDD1 LDO
+ - "ti,twl4030-vdd2" for VDD2 LDO
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+
+ xyz: regulator at 0 {
+ compatible = "ti,twl6030-vaux1","ti,twl6030";
+ regulator-min_uV = <1000000>;
+ regulator-max_uV = <3000000>;
+ regulator-more-normal;
+ regulator-mode-standby;
+ regulator-change-voltage;
+ };
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 2990841..edbf77e 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -48,6 +48,70 @@
compatible = "ti,twl4030-rtc";
interrupts = <11>;
};
+
+ vaux1: regulator at 0 {
+ compatible = "ti,twl6030-vaux1","ti,twl6030";
+ regulator-min-uV = <1000000>;
+ regulator-max-uV = <3000000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-voltage;
+ regulator-change-mode;
+ };
+
+ vaux2: regulator at 1 {
+ compatible = "ti,twl6030-vaux2","ti,twl6030";
+ regulator-min-uV = <1200000>;
+ regulator-max-uV = <2800000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-mode;
+ regulator-change-status;
+ regulator-change-voltage;
+ };
+
+ vaux3: regulator at 2 {
+ compatible = "ti,twl6030-vaux3","ti,twl6030";
+ regulator-min-uV = <1000000>;
+ regulator-max-uV = <3000000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-mode;
+ regulator-change-status;
+ regulator-change-voltage;
+ };
+
+ vmmc: regulator at 3 {
+ compatible = "ti,twl6030-vmmc","ti,twl6030";
+ regulator-min-uV = <1200000>;
+ regulator-max-uV = <3000000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-mode;
+ regulator-change-status;
+ regulator-change-voltage;
+ };
+
+ vpp: regulator at 4 {
+ compatible = "ti,twl6030-vpp","ti,twl6030";
+ regulator-min-uV = <1800000>;
+ regulator-max-uV = <2500000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-mode;
+ regulator-change-status;
+ regulator-change-voltage;
+ };
+
+ vusim: regulator at 5 {
+ compatible = "ti,twl6030-vusim","ti,twl6030";
+ regulator-min-uV = <1200000>;
+ regulator-max-uV = <2900000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-voltage;
+ regulator-change-mode;
+ };
};
};
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 4/9] regulator: twl: Make twl-regulator driver extract data from DT
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-27 10:12 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: broonie, grant.likely
Cc: devicetree-discuss, linux-omap, linux-arm-kernel, tony, lrg,
b-cousson, patches, Rajendra Nayak
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
drivers/regulator/twl-regulator.c | 117 ++++++++++++++++++++++++-------------
1 files changed, 76 insertions(+), 41 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c b/drivers/regulator/twl-regulator.c
index f696287..ddb5ad1 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -14,8 +14,10 @@
#include <linux/err.h>
#include <linux/delay.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
#include <linux/regulator/driver.h>
#include <linux/regulator/machine.h>
+#include <linux/regulator/of_regulator.h>
#include <linux/i2c/twl.h>
@@ -58,6 +60,9 @@ struct twlreg_info {
/* chip specific features */
unsigned long features;
+#ifdef CONFIG_OF
+ char compatible[128];
+#endif
};
@@ -839,13 +844,14 @@ static struct regulator_ops twlsmps_ops = {
TWL_FIXED_LDO(label, offset, mVolts, 0x0, turnon_delay, \
0x0, TWL6030, twl6030fixed_ops)
-#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf) { \
+#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf, comp) { \
.base = offset, \
.id = num, \
.table_len = ARRAY_SIZE(label##_VSEL_table), \
.table = label##_VSEL_table, \
.delay = turnon_delay, \
.remap = remap_conf, \
+ .compatible = comp, \
.desc = { \
.name = #label, \
.id = TWL4030_REG_##label, \
@@ -856,10 +862,11 @@ static struct regulator_ops twlsmps_ops = {
}, \
}
-#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts) { \
+#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts, comp) { \
.base = offset, \
.min_mV = min_mVolts, \
.max_mV = max_mVolts, \
+ .compatible = comp, \
.desc = { \
.name = #label, \
.id = TWL6030_REG_##label, \
@@ -870,10 +877,11 @@ static struct regulator_ops twlsmps_ops = {
}, \
}
-#define TWL6025_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts) { \
+#define TWL6025_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts, comp) { \
.base = offset, \
.min_mV = min_mVolts, \
.max_mV = max_mVolts, \
+ .compatible = comp, \
.desc = { \
.name = #label, \
.id = TWL6025_REG_##label, \
@@ -932,23 +940,23 @@ static struct regulator_ops twlsmps_ops = {
* software control over them after boot.
*/
static struct twlreg_info twl_regs[] = {
- TWL4030_ADJUSTABLE_LDO(VAUX1, 0x17, 1, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VAUX2_4030, 0x1b, 2, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VAUX2, 0x1b, 2, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VAUX3, 0x1f, 3, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VAUX4, 0x23, 4, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VMMC1, 0x27, 5, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VMMC2, 0x2b, 6, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VPLL1, 0x2f, 7, 100, 0x00),
- TWL4030_ADJUSTABLE_LDO(VPLL2, 0x33, 8, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VSIM, 0x37, 9, 100, 0x00),
- TWL4030_ADJUSTABLE_LDO(VDAC, 0x3b, 10, 100, 0x08),
+ TWL4030_ADJUSTABLE_LDO(VAUX1, 0x17, 1, 100, 0x08, "ti,twl4030-vaux1"),
+ TWL4030_ADJUSTABLE_LDO(VAUX2_4030, 0x1b, 2, 100, 0x08, "ti,twl4030-vaux2"),
+ TWL4030_ADJUSTABLE_LDO(VAUX2, 0x1b, 2, 100, 0x08, "ti,twl5030-vaux2"),
+ TWL4030_ADJUSTABLE_LDO(VAUX3, 0x1f, 3, 100, 0x08, "ti,twl4030-vaux3"),
+ TWL4030_ADJUSTABLE_LDO(VAUX4, 0x23, 4, 100, 0x08, "ti,twl4030-vaux4"),
+ TWL4030_ADJUSTABLE_LDO(VMMC1, 0x27, 5, 100, 0x08, "ti,twl4030-vmmc1"),
+ TWL4030_ADJUSTABLE_LDO(VMMC2, 0x2b, 6, 100, 0x08, "ti,twl4030-vmmc2"),
+ TWL4030_ADJUSTABLE_LDO(VPLL1, 0x2f, 7, 100, 0x00, "ti,twl4030-vpll1"),
+ TWL4030_ADJUSTABLE_LDO(VPLL2, 0x33, 8, 100, 0x08, "ti,twl4030-vpll2"),
+ TWL4030_ADJUSTABLE_LDO(VSIM, 0x37, 9, 100, 0x00, "ti,twl4030-vsim"),
+ TWL4030_ADJUSTABLE_LDO(VDAC, 0x3b, 10, 100, 0x08, "ti,twl4030-vdac"),
TWL4030_FIXED_LDO(VINTANA1, 0x3f, 1500, 11, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VINTANA2, 0x43, 12, 100, 0x08),
+ TWL4030_ADJUSTABLE_LDO(VINTANA2, 0x43, 12, 100, 0x08, "ti,twl4030-vintana2"),
TWL4030_FIXED_LDO(VINTDIG, 0x47, 1500, 13, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VIO, 0x4b, 14, 1000, 0x08),
- TWL4030_ADJUSTABLE_LDO(VDD1, 0x55, 15, 1000, 0x08),
- TWL4030_ADJUSTABLE_LDO(VDD2, 0x63, 16, 1000, 0x08),
+ TWL4030_ADJUSTABLE_LDO(VIO, 0x4b, 14, 1000, 0x08, "ti,twl4030-vio"),
+ TWL4030_ADJUSTABLE_LDO(VDD1, 0x55, 15, 1000, 0x08, "ti,twl4030-vdd1"),
+ TWL4030_ADJUSTABLE_LDO(VDD2, 0x63, 16, 1000, 0x08, "ti,twl4030-vdd2"),
TWL4030_FIXED_LDO(VUSB1V5, 0x71, 1500, 17, 100, 0x08),
TWL4030_FIXED_LDO(VUSB1V8, 0x74, 1800, 18, 100, 0x08),
TWL4030_FIXED_LDO(VUSB3V1, 0x77, 3100, 19, 150, 0x08),
@@ -957,12 +965,12 @@ static struct twlreg_info twl_regs[] = {
/* 6030 REG with base as PMC Slave Misc : 0x0030 */
/* Turnon-delay and remap configuration values for 6030 are not
verified since the specification is not public */
- TWL6030_ADJUSTABLE_LDO(VAUX1_6030, 0x54, 1000, 3300),
- TWL6030_ADJUSTABLE_LDO(VAUX2_6030, 0x58, 1000, 3300),
- TWL6030_ADJUSTABLE_LDO(VAUX3_6030, 0x5c, 1000, 3300),
- TWL6030_ADJUSTABLE_LDO(VMMC, 0x68, 1000, 3300),
- TWL6030_ADJUSTABLE_LDO(VPP, 0x6c, 1000, 3300),
- TWL6030_ADJUSTABLE_LDO(VUSIM, 0x74, 1000, 3300),
+ TWL6030_ADJUSTABLE_LDO(VAUX1_6030, 0x54, 1000, 3300, "ti,twl6030-vaux1"),
+ TWL6030_ADJUSTABLE_LDO(VAUX2_6030, 0x58, 1000, 3300, "ti,twl6030-vaux2"),
+ TWL6030_ADJUSTABLE_LDO(VAUX3_6030, 0x5c, 1000, 3300, "ti,twl6030-vaux3"),
+ TWL6030_ADJUSTABLE_LDO(VMMC, 0x68, 1000, 3300, "ti,twl6030-vmmc"),
+ TWL6030_ADJUSTABLE_LDO(VPP, 0x6c, 1000, 3300, "ti,twl6030-vpp"),
+ TWL6030_ADJUSTABLE_LDO(VUSIM, 0x74, 1000, 3300, "ti,twl6030-vusim"),
TWL6030_FIXED_LDO(VANA, 0x50, 2100, 0),
TWL6030_FIXED_LDO(VCXIO, 0x60, 1800, 0),
TWL6030_FIXED_LDO(VDAC, 0x64, 1800, 0),
@@ -970,15 +978,15 @@ static struct twlreg_info twl_regs[] = {
TWL6030_FIXED_RESOURCE(CLK32KG, 0x8C, 0),
/* 6025 are renamed compared to 6030 versions */
- TWL6025_ADJUSTABLE_LDO(LDO2, 0x54, 1000, 3300),
- TWL6025_ADJUSTABLE_LDO(LDO4, 0x58, 1000, 3300),
- TWL6025_ADJUSTABLE_LDO(LDO3, 0x5c, 1000, 3300),
- TWL6025_ADJUSTABLE_LDO(LDO5, 0x68, 1000, 3300),
- TWL6025_ADJUSTABLE_LDO(LDO1, 0x6c, 1000, 3300),
- TWL6025_ADJUSTABLE_LDO(LDO7, 0x74, 1000, 3300),
- TWL6025_ADJUSTABLE_LDO(LDO6, 0x60, 1000, 3300),
- TWL6025_ADJUSTABLE_LDO(LDOLN, 0x64, 1000, 3300),
- TWL6025_ADJUSTABLE_LDO(LDOUSB, 0x70, 1000, 3300),
+ TWL6025_ADJUSTABLE_LDO(LDO2, 0x54, 1000, 3300, "ti,twl6025-ldo2"),
+ TWL6025_ADJUSTABLE_LDO(LDO4, 0x58, 1000, 3300, "ti,twl6025-ldo4"),
+ TWL6025_ADJUSTABLE_LDO(LDO3, 0x5c, 1000, 3300, "ti,twl6025-ldo3"),
+ TWL6025_ADJUSTABLE_LDO(LDO5, 0x68, 1000, 3300, "ti,twl6025-ldo5"),
+ TWL6025_ADJUSTABLE_LDO(LDO1, 0x6c, 1000, 3300, "ti,twl6025-ldo1"),
+ TWL6025_ADJUSTABLE_LDO(LDO7, 0x74, 1000, 3300, "ti,twl6025-ldo7"),
+ TWL6025_ADJUSTABLE_LDO(LDO6, 0x60, 1000, 3300, "ti,twl6025-ldo6"),
+ TWL6025_ADJUSTABLE_LDO(LDOLN, 0x64, 1000, 3300, "ti,twl6025-ldoln"),
+ TWL6025_ADJUSTABLE_LDO(LDOUSB, 0x70, 1000, 3300, "ti,twl6025-ldousb"),
TWL6025_ADJUSTABLE_SMPS(SMPS3, 0x34),
TWL6025_ADJUSTABLE_SMPS(SMPS4, 0x10),
@@ -1011,16 +1019,27 @@ static int __devinit twlreg_probe(struct platform_device *pdev)
struct regulation_constraints *c;
struct regulator_dev *rdev;
- for (i = 0, info = NULL; i < ARRAY_SIZE(twl_regs); i++) {
- if (twl_regs[i].desc.id != pdev->id)
- continue;
- info = twl_regs + i;
- break;
+ if (pdev->dev.of_node) { /* dt based lookup */
+ for (i = 0, info = NULL; i < ARRAY_SIZE(twl_regs); i++) {
+ if (!of_device_is_compatible(pdev->dev.of_node,
+ twl_regs[i].compatible))
+ continue;
+ info = twl_regs + i;
+ break;
+ }
+ initdata = of_get_regulator_init_data(&pdev->dev);
+ } else { /* pdev->id based lookup */
+ for (i = 0, info = NULL; i < ARRAY_SIZE(twl_regs); i++) {
+ if (twl_regs[i].desc.id != pdev->id)
+ continue;
+ info = twl_regs + i;
+ break;
+ }
+ initdata = pdev->dev.platform_data;
}
if (!info)
return -ENODEV;
- initdata = pdev->dev.platform_data;
if (!initdata)
return -EINVAL;
@@ -1093,14 +1112,30 @@ static int __devexit twlreg_remove(struct platform_device *pdev)
MODULE_ALIAS("platform:twl_reg");
+#if defined(CONFIG_OF)
+static const struct of_device_id twl_of_match[] __devinitconst = {
+ { .compatible = "ti,twl6030" },
+ { .compatible = "ti,twl6025" },
+ { .compatible = "ti,twl5030" },
+ { .compatible = "ti,twl4030" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, twl_of_match);
+#else
+#define twl_of_match NULL
+#endif
+
static struct platform_driver twlreg_driver = {
.probe = twlreg_probe,
.remove = __devexit_p(twlreg_remove),
/* NOTE: short name, to work around driver model truncation of
* "twl_regulator.12" (and friends) to "twl_regulator.1".
*/
- .driver.name = "twl_reg",
- .driver.owner = THIS_MODULE,
+ .driver = {
+ .name = "twl_reg",
+ .owner = THIS_MODULE,
+ .of_match_table = twl_of_match,
+ },
};
static int __init twlreg_init(void)
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 4/9] regulator: twl: Make twl-regulator driver extract data from DT
@ 2011-09-27 10:12 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
drivers/regulator/twl-regulator.c | 117 ++++++++++++++++++++++++-------------
1 files changed, 76 insertions(+), 41 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c b/drivers/regulator/twl-regulator.c
index f696287..ddb5ad1 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -14,8 +14,10 @@
#include <linux/err.h>
#include <linux/delay.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
#include <linux/regulator/driver.h>
#include <linux/regulator/machine.h>
+#include <linux/regulator/of_regulator.h>
#include <linux/i2c/twl.h>
@@ -58,6 +60,9 @@ struct twlreg_info {
/* chip specific features */
unsigned long features;
+#ifdef CONFIG_OF
+ char compatible[128];
+#endif
};
@@ -839,13 +844,14 @@ static struct regulator_ops twlsmps_ops = {
TWL_FIXED_LDO(label, offset, mVolts, 0x0, turnon_delay, \
0x0, TWL6030, twl6030fixed_ops)
-#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf) { \
+#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf, comp) { \
.base = offset, \
.id = num, \
.table_len = ARRAY_SIZE(label##_VSEL_table), \
.table = label##_VSEL_table, \
.delay = turnon_delay, \
.remap = remap_conf, \
+ .compatible = comp, \
.desc = { \
.name = #label, \
.id = TWL4030_REG_##label, \
@@ -856,10 +862,11 @@ static struct regulator_ops twlsmps_ops = {
}, \
}
-#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts) { \
+#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts, comp) { \
.base = offset, \
.min_mV = min_mVolts, \
.max_mV = max_mVolts, \
+ .compatible = comp, \
.desc = { \
.name = #label, \
.id = TWL6030_REG_##label, \
@@ -870,10 +877,11 @@ static struct regulator_ops twlsmps_ops = {
}, \
}
-#define TWL6025_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts) { \
+#define TWL6025_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts, comp) { \
.base = offset, \
.min_mV = min_mVolts, \
.max_mV = max_mVolts, \
+ .compatible = comp, \
.desc = { \
.name = #label, \
.id = TWL6025_REG_##label, \
@@ -932,23 +940,23 @@ static struct regulator_ops twlsmps_ops = {
* software control over them after boot.
*/
static struct twlreg_info twl_regs[] = {
- TWL4030_ADJUSTABLE_LDO(VAUX1, 0x17, 1, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VAUX2_4030, 0x1b, 2, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VAUX2, 0x1b, 2, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VAUX3, 0x1f, 3, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VAUX4, 0x23, 4, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VMMC1, 0x27, 5, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VMMC2, 0x2b, 6, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VPLL1, 0x2f, 7, 100, 0x00),
- TWL4030_ADJUSTABLE_LDO(VPLL2, 0x33, 8, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VSIM, 0x37, 9, 100, 0x00),
- TWL4030_ADJUSTABLE_LDO(VDAC, 0x3b, 10, 100, 0x08),
+ TWL4030_ADJUSTABLE_LDO(VAUX1, 0x17, 1, 100, 0x08, "ti,twl4030-vaux1"),
+ TWL4030_ADJUSTABLE_LDO(VAUX2_4030, 0x1b, 2, 100, 0x08, "ti,twl4030-vaux2"),
+ TWL4030_ADJUSTABLE_LDO(VAUX2, 0x1b, 2, 100, 0x08, "ti,twl5030-vaux2"),
+ TWL4030_ADJUSTABLE_LDO(VAUX3, 0x1f, 3, 100, 0x08, "ti,twl4030-vaux3"),
+ TWL4030_ADJUSTABLE_LDO(VAUX4, 0x23, 4, 100, 0x08, "ti,twl4030-vaux4"),
+ TWL4030_ADJUSTABLE_LDO(VMMC1, 0x27, 5, 100, 0x08, "ti,twl4030-vmmc1"),
+ TWL4030_ADJUSTABLE_LDO(VMMC2, 0x2b, 6, 100, 0x08, "ti,twl4030-vmmc2"),
+ TWL4030_ADJUSTABLE_LDO(VPLL1, 0x2f, 7, 100, 0x00, "ti,twl4030-vpll1"),
+ TWL4030_ADJUSTABLE_LDO(VPLL2, 0x33, 8, 100, 0x08, "ti,twl4030-vpll2"),
+ TWL4030_ADJUSTABLE_LDO(VSIM, 0x37, 9, 100, 0x00, "ti,twl4030-vsim"),
+ TWL4030_ADJUSTABLE_LDO(VDAC, 0x3b, 10, 100, 0x08, "ti,twl4030-vdac"),
TWL4030_FIXED_LDO(VINTANA1, 0x3f, 1500, 11, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VINTANA2, 0x43, 12, 100, 0x08),
+ TWL4030_ADJUSTABLE_LDO(VINTANA2, 0x43, 12, 100, 0x08, "ti,twl4030-vintana2"),
TWL4030_FIXED_LDO(VINTDIG, 0x47, 1500, 13, 100, 0x08),
- TWL4030_ADJUSTABLE_LDO(VIO, 0x4b, 14, 1000, 0x08),
- TWL4030_ADJUSTABLE_LDO(VDD1, 0x55, 15, 1000, 0x08),
- TWL4030_ADJUSTABLE_LDO(VDD2, 0x63, 16, 1000, 0x08),
+ TWL4030_ADJUSTABLE_LDO(VIO, 0x4b, 14, 1000, 0x08, "ti,twl4030-vio"),
+ TWL4030_ADJUSTABLE_LDO(VDD1, 0x55, 15, 1000, 0x08, "ti,twl4030-vdd1"),
+ TWL4030_ADJUSTABLE_LDO(VDD2, 0x63, 16, 1000, 0x08, "ti,twl4030-vdd2"),
TWL4030_FIXED_LDO(VUSB1V5, 0x71, 1500, 17, 100, 0x08),
TWL4030_FIXED_LDO(VUSB1V8, 0x74, 1800, 18, 100, 0x08),
TWL4030_FIXED_LDO(VUSB3V1, 0x77, 3100, 19, 150, 0x08),
@@ -957,12 +965,12 @@ static struct twlreg_info twl_regs[] = {
/* 6030 REG with base as PMC Slave Misc : 0x0030 */
/* Turnon-delay and remap configuration values for 6030 are not
verified since the specification is not public */
- TWL6030_ADJUSTABLE_LDO(VAUX1_6030, 0x54, 1000, 3300),
- TWL6030_ADJUSTABLE_LDO(VAUX2_6030, 0x58, 1000, 3300),
- TWL6030_ADJUSTABLE_LDO(VAUX3_6030, 0x5c, 1000, 3300),
- TWL6030_ADJUSTABLE_LDO(VMMC, 0x68, 1000, 3300),
- TWL6030_ADJUSTABLE_LDO(VPP, 0x6c, 1000, 3300),
- TWL6030_ADJUSTABLE_LDO(VUSIM, 0x74, 1000, 3300),
+ TWL6030_ADJUSTABLE_LDO(VAUX1_6030, 0x54, 1000, 3300, "ti,twl6030-vaux1"),
+ TWL6030_ADJUSTABLE_LDO(VAUX2_6030, 0x58, 1000, 3300, "ti,twl6030-vaux2"),
+ TWL6030_ADJUSTABLE_LDO(VAUX3_6030, 0x5c, 1000, 3300, "ti,twl6030-vaux3"),
+ TWL6030_ADJUSTABLE_LDO(VMMC, 0x68, 1000, 3300, "ti,twl6030-vmmc"),
+ TWL6030_ADJUSTABLE_LDO(VPP, 0x6c, 1000, 3300, "ti,twl6030-vpp"),
+ TWL6030_ADJUSTABLE_LDO(VUSIM, 0x74, 1000, 3300, "ti,twl6030-vusim"),
TWL6030_FIXED_LDO(VANA, 0x50, 2100, 0),
TWL6030_FIXED_LDO(VCXIO, 0x60, 1800, 0),
TWL6030_FIXED_LDO(VDAC, 0x64, 1800, 0),
@@ -970,15 +978,15 @@ static struct twlreg_info twl_regs[] = {
TWL6030_FIXED_RESOURCE(CLK32KG, 0x8C, 0),
/* 6025 are renamed compared to 6030 versions */
- TWL6025_ADJUSTABLE_LDO(LDO2, 0x54, 1000, 3300),
- TWL6025_ADJUSTABLE_LDO(LDO4, 0x58, 1000, 3300),
- TWL6025_ADJUSTABLE_LDO(LDO3, 0x5c, 1000, 3300),
- TWL6025_ADJUSTABLE_LDO(LDO5, 0x68, 1000, 3300),
- TWL6025_ADJUSTABLE_LDO(LDO1, 0x6c, 1000, 3300),
- TWL6025_ADJUSTABLE_LDO(LDO7, 0x74, 1000, 3300),
- TWL6025_ADJUSTABLE_LDO(LDO6, 0x60, 1000, 3300),
- TWL6025_ADJUSTABLE_LDO(LDOLN, 0x64, 1000, 3300),
- TWL6025_ADJUSTABLE_LDO(LDOUSB, 0x70, 1000, 3300),
+ TWL6025_ADJUSTABLE_LDO(LDO2, 0x54, 1000, 3300, "ti,twl6025-ldo2"),
+ TWL6025_ADJUSTABLE_LDO(LDO4, 0x58, 1000, 3300, "ti,twl6025-ldo4"),
+ TWL6025_ADJUSTABLE_LDO(LDO3, 0x5c, 1000, 3300, "ti,twl6025-ldo3"),
+ TWL6025_ADJUSTABLE_LDO(LDO5, 0x68, 1000, 3300, "ti,twl6025-ldo5"),
+ TWL6025_ADJUSTABLE_LDO(LDO1, 0x6c, 1000, 3300, "ti,twl6025-ldo1"),
+ TWL6025_ADJUSTABLE_LDO(LDO7, 0x74, 1000, 3300, "ti,twl6025-ldo7"),
+ TWL6025_ADJUSTABLE_LDO(LDO6, 0x60, 1000, 3300, "ti,twl6025-ldo6"),
+ TWL6025_ADJUSTABLE_LDO(LDOLN, 0x64, 1000, 3300, "ti,twl6025-ldoln"),
+ TWL6025_ADJUSTABLE_LDO(LDOUSB, 0x70, 1000, 3300, "ti,twl6025-ldousb"),
TWL6025_ADJUSTABLE_SMPS(SMPS3, 0x34),
TWL6025_ADJUSTABLE_SMPS(SMPS4, 0x10),
@@ -1011,16 +1019,27 @@ static int __devinit twlreg_probe(struct platform_device *pdev)
struct regulation_constraints *c;
struct regulator_dev *rdev;
- for (i = 0, info = NULL; i < ARRAY_SIZE(twl_regs); i++) {
- if (twl_regs[i].desc.id != pdev->id)
- continue;
- info = twl_regs + i;
- break;
+ if (pdev->dev.of_node) { /* dt based lookup */
+ for (i = 0, info = NULL; i < ARRAY_SIZE(twl_regs); i++) {
+ if (!of_device_is_compatible(pdev->dev.of_node,
+ twl_regs[i].compatible))
+ continue;
+ info = twl_regs + i;
+ break;
+ }
+ initdata = of_get_regulator_init_data(&pdev->dev);
+ } else { /* pdev->id based lookup */
+ for (i = 0, info = NULL; i < ARRAY_SIZE(twl_regs); i++) {
+ if (twl_regs[i].desc.id != pdev->id)
+ continue;
+ info = twl_regs + i;
+ break;
+ }
+ initdata = pdev->dev.platform_data;
}
if (!info)
return -ENODEV;
- initdata = pdev->dev.platform_data;
if (!initdata)
return -EINVAL;
@@ -1093,14 +1112,30 @@ static int __devexit twlreg_remove(struct platform_device *pdev)
MODULE_ALIAS("platform:twl_reg");
+#if defined(CONFIG_OF)
+static const struct of_device_id twl_of_match[] __devinitconst = {
+ { .compatible = "ti,twl6030" },
+ { .compatible = "ti,twl6025" },
+ { .compatible = "ti,twl5030" },
+ { .compatible = "ti,twl4030" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, twl_of_match);
+#else
+#define twl_of_match NULL
+#endif
+
static struct platform_driver twlreg_driver = {
.probe = twlreg_probe,
.remove = __devexit_p(twlreg_remove),
/* NOTE: short name, to work around driver model truncation of
* "twl_regulator.12" (and friends) to "twl_regulator.1".
*/
- .driver.name = "twl_reg",
- .driver.owner = THIS_MODULE,
+ .driver = {
+ .name = "twl_reg",
+ .owner = THIS_MODULE,
+ .of_match_table = twl_of_match,
+ },
};
static int __init twlreg_init(void)
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 5/9] regulator: helper routine to extract fixed_voltage_config
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-27 10:12 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: broonie, grant.likely
Cc: devicetree-discuss, linux-omap, linux-arm-kernel, tony, lrg,
b-cousson, patches, Rajendra Nayak
The helper routine of_get_fixed_voltage_config() extracts
fixed_voltage_config structure contents from device tree.
Also add documenation for additional bindings for fixed
regulators that can be passed through dt.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
.../bindings/regulator/fixed-regulator.txt | 24 +++++++++++++
drivers/regulator/fixed.c | 36 ++++++++++++++++++++
include/linux/regulator/fixed.h | 6 ++--
3 files changed, 63 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/fixed-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
new file mode 100644
index 0000000..a204cbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
@@ -0,0 +1,24 @@
+Fixed Voltage regulators
+
+Required properties:
+- compatible: Must be "regulator-fixed";
+
+Optional properties:
+- regulator-fixed-supply: Name of the regulator supply
+- regulator-fixed-microvolts: Output voltage of regulator
+- regulator-fixed-gpio: gpio to use for enable control
+- regulator-fixed-startup-delay: startup time in microseconds
+- regulator-fixed-enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low
+- regulator-fixed-enabled-at-boot: 1 = yes, 0 = no
+
+Example:
+
+ abc: fixedregulator@0 {
+ compatible = "regulator-fixed";
+ regulator-fixed-supply = "fixed-supply";
+ regulator-fixed-microvolts = <1800000>;
+ regulator-fixed-gpio = <43>;
+ regulator-fixed-startup-delay = <70000>;
+ regulator-fixed-enable-high;
+ regulator-fixed-enabled-at-boot;
+ };
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index 2fe9d99..c09f791 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -26,6 +26,8 @@
#include <linux/gpio.h>
#include <linux/delay.h>
#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/regulator/of_regulator.h>
struct fixed_voltage_data {
struct regulator_desc desc;
@@ -37,6 +39,40 @@ struct fixed_voltage_data {
bool is_enabled;
};
+
+/**
+ * of_get_fixed_voltage_config - extract fixed_voltage_config structure info
+ * @dev: device requesting for fixed_voltage_config
+ *
+ * Populates fixed_voltage_config structure by extracting data from device
+ * tree node, returns a pointer to the populated structure of NULL if memory
+ * alloc fails.
+ */
+struct fixed_voltage_config *of_get_fixed_voltage_config(struct device *dev)
+{
+ struct fixed_voltage_config *config;
+ struct device_node *np = dev->of_node;
+
+ config = devm_kzalloc(dev, sizeof(struct fixed_voltage_config), GFP_KERNEL);
+ if (!config)
+ return NULL;
+
+ config->supply_name = (char *)of_get_property(np,
+ "regulator-fixed-supply", NULL);
+ of_property_read_u32(np, "regulator-fixed-microvolts",
+ &config->microvolts);
+ of_property_read_u32(np, "regulator-fixed-gpio", &config->gpio);
+ of_property_read_u32(np, "regulator-fixed-startup-delay",
+ &config->startup_delay);
+ if (of_find_property(np, "regulator-fixed-enable-high", NULL))
+ config->enable_high = true;
+ if (of_find_property(np, "regulator-fixed-enabled-at-boot", NULL))
+ config->enabled_at_boot = true;
+ config->init_data = of_get_regulator_init_data(dev);
+
+ return config;
+}
+
static int fixed_voltage_is_enabled(struct regulator_dev *dev)
{
struct fixed_voltage_data *data = rdev_get_drvdata(dev);
diff --git a/include/linux/regulator/fixed.h b/include/linux/regulator/fixed.h
index ffd7d50..bb762cf 100644
--- a/include/linux/regulator/fixed.h
+++ b/include/linux/regulator/fixed.h
@@ -40,9 +40,9 @@ struct regulator_init_data;
*/
struct fixed_voltage_config {
const char *supply_name;
- int microvolts;
- int gpio;
- unsigned startup_delay;
+ u32 microvolts;
+ u32 gpio;
+ u32 startup_delay;
unsigned enable_high:1;
unsigned enabled_at_boot:1;
struct regulator_init_data *init_data;
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 5/9] regulator: helper routine to extract fixed_voltage_config
@ 2011-09-27 10:12 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: linux-arm-kernel
The helper routine of_get_fixed_voltage_config() extracts
fixed_voltage_config structure contents from device tree.
Also add documenation for additional bindings for fixed
regulators that can be passed through dt.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
.../bindings/regulator/fixed-regulator.txt | 24 +++++++++++++
drivers/regulator/fixed.c | 36 ++++++++++++++++++++
include/linux/regulator/fixed.h | 6 ++--
3 files changed, 63 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/fixed-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
new file mode 100644
index 0000000..a204cbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
@@ -0,0 +1,24 @@
+Fixed Voltage regulators
+
+Required properties:
+- compatible: Must be "regulator-fixed";
+
+Optional properties:
+- regulator-fixed-supply: Name of the regulator supply
+- regulator-fixed-microvolts: Output voltage of regulator
+- regulator-fixed-gpio: gpio to use for enable control
+- regulator-fixed-startup-delay: startup time in microseconds
+- regulator-fixed-enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low
+- regulator-fixed-enabled-at-boot: 1 = yes, 0 = no
+
+Example:
+
+ abc: fixedregulator at 0 {
+ compatible = "regulator-fixed";
+ regulator-fixed-supply = "fixed-supply";
+ regulator-fixed-microvolts = <1800000>;
+ regulator-fixed-gpio = <43>;
+ regulator-fixed-startup-delay = <70000>;
+ regulator-fixed-enable-high;
+ regulator-fixed-enabled-at-boot;
+ };
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index 2fe9d99..c09f791 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -26,6 +26,8 @@
#include <linux/gpio.h>
#include <linux/delay.h>
#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/regulator/of_regulator.h>
struct fixed_voltage_data {
struct regulator_desc desc;
@@ -37,6 +39,40 @@ struct fixed_voltage_data {
bool is_enabled;
};
+
+/**
+ * of_get_fixed_voltage_config - extract fixed_voltage_config structure info
+ * @dev: device requesting for fixed_voltage_config
+ *
+ * Populates fixed_voltage_config structure by extracting data from device
+ * tree node, returns a pointer to the populated structure of NULL if memory
+ * alloc fails.
+ */
+struct fixed_voltage_config *of_get_fixed_voltage_config(struct device *dev)
+{
+ struct fixed_voltage_config *config;
+ struct device_node *np = dev->of_node;
+
+ config = devm_kzalloc(dev, sizeof(struct fixed_voltage_config), GFP_KERNEL);
+ if (!config)
+ return NULL;
+
+ config->supply_name = (char *)of_get_property(np,
+ "regulator-fixed-supply", NULL);
+ of_property_read_u32(np, "regulator-fixed-microvolts",
+ &config->microvolts);
+ of_property_read_u32(np, "regulator-fixed-gpio", &config->gpio);
+ of_property_read_u32(np, "regulator-fixed-startup-delay",
+ &config->startup_delay);
+ if (of_find_property(np, "regulator-fixed-enable-high", NULL))
+ config->enable_high = true;
+ if (of_find_property(np, "regulator-fixed-enabled-at-boot", NULL))
+ config->enabled_at_boot = true;
+ config->init_data = of_get_regulator_init_data(dev);
+
+ return config;
+}
+
static int fixed_voltage_is_enabled(struct regulator_dev *dev)
{
struct fixed_voltage_data *data = rdev_get_drvdata(dev);
diff --git a/include/linux/regulator/fixed.h b/include/linux/regulator/fixed.h
index ffd7d50..bb762cf 100644
--- a/include/linux/regulator/fixed.h
+++ b/include/linux/regulator/fixed.h
@@ -40,9 +40,9 @@ struct regulator_init_data;
*/
struct fixed_voltage_config {
const char *supply_name;
- int microvolts;
- int gpio;
- unsigned startup_delay;
+ u32 microvolts;
+ u32 gpio;
+ u32 startup_delay;
unsigned enable_high:1;
unsigned enabled_at_boot:1;
struct regulator_init_data *init_data;
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 6/9] regulator: make fixed regulator driver extract data from dt
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-27 10:12 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: broonie, grant.likely
Cc: devicetree-discuss, linux-omap, linux-arm-kernel, tony, lrg,
b-cousson, patches, Rajendra Nayak
Modify the fixed regulator driver to extract fixed_voltage_config from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
drivers/regulator/fixed.c | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index c09f791..0a9a10d 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -140,10 +140,15 @@ static struct regulator_ops fixed_voltage_ops = {
static int __devinit reg_fixed_voltage_probe(struct platform_device *pdev)
{
- struct fixed_voltage_config *config = pdev->dev.platform_data;
+ struct fixed_voltage_config *config;
struct fixed_voltage_data *drvdata;
int ret;
+ if (pdev->dev.of_node)
+ config = of_get_fixed_voltage_config(&pdev->dev);
+ else
+ config = pdev->dev.platform_data;
+
drvdata = kzalloc(sizeof(struct fixed_voltage_data), GFP_KERNEL);
if (drvdata == NULL) {
dev_err(&pdev->dev, "Failed to allocate device data\n");
@@ -252,12 +257,23 @@ static int __devexit reg_fixed_voltage_remove(struct platform_device *pdev)
return 0;
}
+#if defined(CONFIG_OF)
+static const struct of_device_id fixed_of_match[] __devinitconst = {
+ { .compatible = "regulator-fixed", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, fixed_of_match);
+#else
+#define fixed_of_match NULL
+#endif
+
static struct platform_driver regulator_fixed_voltage_driver = {
.probe = reg_fixed_voltage_probe,
.remove = __devexit_p(reg_fixed_voltage_remove),
.driver = {
.name = "reg-fixed-voltage",
.owner = THIS_MODULE,
+ .of_match_table = fixed_of_match,
},
};
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 6/9] regulator: make fixed regulator driver extract data from dt
@ 2011-09-27 10:12 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Modify the fixed regulator driver to extract fixed_voltage_config from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
drivers/regulator/fixed.c | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index c09f791..0a9a10d 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -140,10 +140,15 @@ static struct regulator_ops fixed_voltage_ops = {
static int __devinit reg_fixed_voltage_probe(struct platform_device *pdev)
{
- struct fixed_voltage_config *config = pdev->dev.platform_data;
+ struct fixed_voltage_config *config;
struct fixed_voltage_data *drvdata;
int ret;
+ if (pdev->dev.of_node)
+ config = of_get_fixed_voltage_config(&pdev->dev);
+ else
+ config = pdev->dev.platform_data;
+
drvdata = kzalloc(sizeof(struct fixed_voltage_data), GFP_KERNEL);
if (drvdata == NULL) {
dev_err(&pdev->dev, "Failed to allocate device data\n");
@@ -252,12 +257,23 @@ static int __devexit reg_fixed_voltage_remove(struct platform_device *pdev)
return 0;
}
+#if defined(CONFIG_OF)
+static const struct of_device_id fixed_of_match[] __devinitconst = {
+ { .compatible = "regulator-fixed", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, fixed_of_match);
+#else
+#define fixed_of_match NULL
+#endif
+
static struct platform_driver regulator_fixed_voltage_driver = {
.probe = reg_fixed_voltage_probe,
.remove = __devexit_p(reg_fixed_voltage_remove),
.driver = {
.name = "reg-fixed-voltage",
.owner = THIS_MODULE,
+ .of_match_table = fixed_of_match,
},
};
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 7/9] omap4: panda: Pass regulator data from DT
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-27 10:12 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: broonie, grant.likely
Cc: devicetree-discuss, linux-omap, linux-arm-kernel, tony, lrg,
b-cousson, patches, Rajendra Nayak
Pass the fixed and adjustable voltage regulator information for
omap4panda board from device tree.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/boot/dts/omap4-panda.dts | 54 +++++++++++++++++++++++++++++++++++++
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index 2c6ce2b..045dbfc 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -48,6 +48,60 @@
compatible = "ti,twl4030-rtc";
interrupts = <11>;
};
+
+ vwl1271: fixedregulator@0 {
+ compatible = "regulator-fixed";
+ regulator-fixed-supply = "vwl1271";
+ regulator-fixed-microvolts = <1800000>;
+ regulator-fixed-gpio = <43>;
+ regulator-fixed-startup-delay = <70000>;
+ regulator-fixed-enable-high;
+ regulator-fixed-enabled-at-boot;
+ };
+
+ vaux2: regulator@0 {
+ compatible = "ti,twl6030-vaux2","ti,twl6030";
+ regulator-min-uV = <1200000>;
+ regulator-max-uV = <2800000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-mode;
+ regulator-change-status;
+ regulator-change-voltage;
+ };
+
+ vaux3: regulator@1 {
+ compatible = "ti,twl6030-vaux3","ti,twl6030";
+ regulator-min-uV = <1000000>;
+ regulator-max-uV = <3000000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-mode;
+ regulator-change-status;
+ regulator-change-voltage;
+ };
+
+ vmmc: regulator@2 {
+ compatible = "ti,twl6030-vmmc","ti,twl6030";
+ regulator-min-uV = <1200000>;
+ regulator-max-uV = <3000000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-mode;
+ regulator-change-status;
+ regulator-change-voltage;
+ };
+
+ vpp: regulator@3 {
+ compatible = "ti,twl6030-vpp","ti,twl6030";
+ regulator-min-uV = <1800000>;
+ regulator-max-uV = <2500000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-mode;
+ regulator-change-status;
+ regulator-change-voltage;
+ };
};
};
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 7/9] omap4: panda: Pass regulator data from DT
@ 2011-09-27 10:12 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Pass the fixed and adjustable voltage regulator information for
omap4panda board from device tree.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/boot/dts/omap4-panda.dts | 54 +++++++++++++++++++++++++++++++++++++
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index 2c6ce2b..045dbfc 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -48,6 +48,60 @@
compatible = "ti,twl4030-rtc";
interrupts = <11>;
};
+
+ vwl1271: fixedregulator at 0 {
+ compatible = "regulator-fixed";
+ regulator-fixed-supply = "vwl1271";
+ regulator-fixed-microvolts = <1800000>;
+ regulator-fixed-gpio = <43>;
+ regulator-fixed-startup-delay = <70000>;
+ regulator-fixed-enable-high;
+ regulator-fixed-enabled-at-boot;
+ };
+
+ vaux2: regulator at 0 {
+ compatible = "ti,twl6030-vaux2","ti,twl6030";
+ regulator-min-uV = <1200000>;
+ regulator-max-uV = <2800000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-mode;
+ regulator-change-status;
+ regulator-change-voltage;
+ };
+
+ vaux3: regulator at 1 {
+ compatible = "ti,twl6030-vaux3","ti,twl6030";
+ regulator-min-uV = <1000000>;
+ regulator-max-uV = <3000000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-mode;
+ regulator-change-status;
+ regulator-change-voltage;
+ };
+
+ vmmc: regulator at 2 {
+ compatible = "ti,twl6030-vmmc","ti,twl6030";
+ regulator-min-uV = <1200000>;
+ regulator-max-uV = <3000000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-mode;
+ regulator-change-status;
+ regulator-change-voltage;
+ };
+
+ vpp: regulator at 3 {
+ compatible = "ti,twl6030-vpp","ti,twl6030";
+ regulator-min-uV = <1800000>;
+ regulator-max-uV = <2500000>;
+ regulator-mode-normal;
+ regulator-mode-standby;
+ regulator-change-mode;
+ regulator-change-status;
+ regulator-change-voltage;
+ };
};
};
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 8/9] regulator: helper to extract regulator node based on supply name
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-27 10:12 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: broonie, grant.likely
Cc: devicetree-discuss, linux-omap, linux-arm-kernel, tony, lrg,
b-cousson, patches, Rajendra Nayak
Device nodes in DT can associate themselves with one or more
regulators by providing a list of phandles (to regulator nodes)
and corresponding supply names.
For Example:
devicenode: node@0x0 {
...
...
vmmc-supply = <®ulator1>;
vpll-supply = <®ulator1>;
};
The driver would then do a regulator_get(dev, "vmmc"); to get
regulator1 and do a regulator_get(dev, "vpll"); to get
regulator2.
of_get_regulator() extracts the regulator node for a given
device, based on the supply name.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
drivers/regulator/of_regulator.c | 39 ++++++++++++++++++++++++++++++++
include/linux/regulator/of_regulator.h | 7 +++++
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 7fa63ff..49dd105 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -14,6 +14,45 @@
#include <linux/of.h>
#include <linux/regulator/machine.h>
+
+/**
+ * of_get_regulator - get a regulator device node based on supply name
+ * @dev: Device pointer for the consumer (of regulator) device
+ * @supply: regulator supply name
+ *
+ * Extract the regulator device node corresponding to the supply name.
+ * retruns the device node corresponding to the regulator if found, else
+ * returns NULL.
+ */
+struct device_node *of_get_regulator(struct device *dev, const char *supply)
+{
+ struct device_node *regnode = NULL;
+ u32 reghandle;
+ char prop_name[32]; /* 32 is max size of property name */
+ const void *prop;
+ int sz;
+
+ if (!dev)
+ return NULL;
+
+ dev_dbg(dev, "Looking up %s-supply from device tree\n", supply);
+
+ snprintf(prop_name, 32, "%s-supply", supply);
+
+ prop = of_get_property(dev->of_node, prop_name, &sz);
+ if (!prop || sz < 4)
+ return NULL;
+
+ reghandle = be32_to_cpup(prop);
+ regnode = of_find_node_by_phandle(reghandle);
+ if (!regnode) {
+ pr_warn("%s: %s property in node %s references invalid phandle",
+ __func__, prop_name, dev->of_node->full_name);
+ return NULL;
+ }
+ return regnode;
+}
+
static void of_get_regulation_constraints(struct device_node *np,
struct regulator_init_data **init_data)
{
diff --git a/include/linux/regulator/of_regulator.h b/include/linux/regulator/of_regulator.h
index 3f63be9..edaba1a 100644
--- a/include/linux/regulator/of_regulator.h
+++ b/include/linux/regulator/of_regulator.h
@@ -9,12 +9,19 @@
#if defined(CONFIG_OF_REGULATOR)
extern struct regulator_init_data
*of_get_regulator_init_data(struct device *dev);
+extern struct device_node *of_get_regulator(struct device *dev,
+ const char *supply);
#else
static inline struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np)
{
return NULL;
}
+static inline struct device_node *of_get_regulator(struct device *dev,
+ const char *id)
+{
+ return NULL;
+}
#endif /* CONFIG_OF_REGULATOR */
#endif /* __LINUX_OF_REG_H */
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 8/9] regulator: helper to extract regulator node based on supply name
@ 2011-09-27 10:12 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Device nodes in DT can associate themselves with one or more
regulators by providing a list of phandles (to regulator nodes)
and corresponding supply names.
For Example:
devicenode: node at 0x0 {
...
...
vmmc-supply = <®ulator1>;
vpll-supply = <®ulator1>;
};
The driver would then do a regulator_get(dev, "vmmc"); to get
regulator1 and do a regulator_get(dev, "vpll"); to get
regulator2.
of_get_regulator() extracts the regulator node for a given
device, based on the supply name.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
drivers/regulator/of_regulator.c | 39 ++++++++++++++++++++++++++++++++
include/linux/regulator/of_regulator.h | 7 +++++
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 7fa63ff..49dd105 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -14,6 +14,45 @@
#include <linux/of.h>
#include <linux/regulator/machine.h>
+
+/**
+ * of_get_regulator - get a regulator device node based on supply name
+ * @dev: Device pointer for the consumer (of regulator) device
+ * @supply: regulator supply name
+ *
+ * Extract the regulator device node corresponding to the supply name.
+ * retruns the device node corresponding to the regulator if found, else
+ * returns NULL.
+ */
+struct device_node *of_get_regulator(struct device *dev, const char *supply)
+{
+ struct device_node *regnode = NULL;
+ u32 reghandle;
+ char prop_name[32]; /* 32 is max size of property name */
+ const void *prop;
+ int sz;
+
+ if (!dev)
+ return NULL;
+
+ dev_dbg(dev, "Looking up %s-supply from device tree\n", supply);
+
+ snprintf(prop_name, 32, "%s-supply", supply);
+
+ prop = of_get_property(dev->of_node, prop_name, &sz);
+ if (!prop || sz < 4)
+ return NULL;
+
+ reghandle = be32_to_cpup(prop);
+ regnode = of_find_node_by_phandle(reghandle);
+ if (!regnode) {
+ pr_warn("%s: %s property in node %s references invalid phandle",
+ __func__, prop_name, dev->of_node->full_name);
+ return NULL;
+ }
+ return regnode;
+}
+
static void of_get_regulation_constraints(struct device_node *np,
struct regulator_init_data **init_data)
{
diff --git a/include/linux/regulator/of_regulator.h b/include/linux/regulator/of_regulator.h
index 3f63be9..edaba1a 100644
--- a/include/linux/regulator/of_regulator.h
+++ b/include/linux/regulator/of_regulator.h
@@ -9,12 +9,19 @@
#if defined(CONFIG_OF_REGULATOR)
extern struct regulator_init_data
*of_get_regulator_init_data(struct device *dev);
+extern struct device_node *of_get_regulator(struct device *dev,
+ const char *supply);
#else
static inline struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np)
{
return NULL;
}
+static inline struct device_node *of_get_regulator(struct device *dev,
+ const char *id)
+{
+ return NULL;
+}
#endif /* CONFIG_OF_REGULATOR */
#endif /* __LINUX_OF_REG_H */
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 9/9] regulator: map consumer regulator based on device tree
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-27 10:12 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: broonie, grant.likely
Cc: devicetree-discuss, linux-omap, linux-arm-kernel, tony, lrg,
b-cousson, patches, Rajendra Nayak
Look up the regulator for a given consumer from device tree, during
a regulator_get(). If not found fallback and lookup through
the regulator_map_list instead.
Devices can associate with one or more regulators by providing a
list of phandles and supply names.
For Example:
devicenode: node@0x0 {
...
...
vmmc-supply = <®ulator1>;
vpll-supply = <®ulator2>;
};
When a device driver calls a regulator_get, specifying the
supply name, the phandle and eventually the regulator node
is extracted from the device node.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
drivers/regulator/core.c | 14 ++++++++++++++
include/linux/regulator/driver.h | 3 +++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index d8e6a42..47b851c 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -25,9 +25,11 @@
#include <linux/mutex.h>
#include <linux/suspend.h>
#include <linux/delay.h>
+#include <linux/of.h>
#include <linux/regulator/consumer.h>
#include <linux/regulator/driver.h>
#include <linux/regulator/machine.h>
+#include <linux/regulator/of_regulator.h>
#define CREATE_TRACE_POINTS
#include <trace/events/regulator.h>
@@ -1155,6 +1157,7 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
struct regulator_map *map;
struct regulator *regulator = ERR_PTR(-ENODEV);
const char *devname = NULL;
+ struct device_node *node;
int ret;
if (id == NULL) {
@@ -1167,6 +1170,15 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
mutex_lock(®ulator_list_mutex);
+ if (dev->of_node) {
+ node = of_get_regulator(dev, id);
+ if (!node)
+ goto retry; /* fallback and chk regulator_map_list */
+ list_for_each_entry(rdev, ®ulator_list, list)
+ if (node == rdev->node)
+ goto found;
+ }
+retry:
list_for_each_entry(map, ®ulator_map_list, list) {
/* If the mapping has a device set up it must match */
if (map->dev_name &&
@@ -2619,6 +2631,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
rdev->reg_data = driver_data;
rdev->owner = regulator_desc->owner;
rdev->desc = regulator_desc;
+ if (dev && dev->of_node)
+ rdev->node = dev->of_node;
INIT_LIST_HEAD(&rdev->consumer_list);
INIT_LIST_HEAD(&rdev->list);
BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 1a80bc7..4aebbf5 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -196,6 +196,9 @@ struct regulator_dev {
struct mutex mutex; /* consumer lock */
struct module *owner;
struct device dev;
+#ifdef CONFIG_OF
+ struct device_node *node;
+#endif
struct regulation_constraints *constraints;
struct regulator *supply; /* for tree */
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH 9/9] regulator: map consumer regulator based on device tree
@ 2011-09-27 10:12 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 10:12 UTC (permalink / raw)
To: linux-arm-kernel
Look up the regulator for a given consumer from device tree, during
a regulator_get(). If not found fallback and lookup through
the regulator_map_list instead.
Devices can associate with one or more regulators by providing a
list of phandles and supply names.
For Example:
devicenode: node at 0x0 {
...
...
vmmc-supply = <®ulator1>;
vpll-supply = <®ulator2>;
};
When a device driver calls a regulator_get, specifying the
supply name, the phandle and eventually the regulator node
is extracted from the device node.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
drivers/regulator/core.c | 14 ++++++++++++++
include/linux/regulator/driver.h | 3 +++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index d8e6a42..47b851c 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -25,9 +25,11 @@
#include <linux/mutex.h>
#include <linux/suspend.h>
#include <linux/delay.h>
+#include <linux/of.h>
#include <linux/regulator/consumer.h>
#include <linux/regulator/driver.h>
#include <linux/regulator/machine.h>
+#include <linux/regulator/of_regulator.h>
#define CREATE_TRACE_POINTS
#include <trace/events/regulator.h>
@@ -1155,6 +1157,7 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
struct regulator_map *map;
struct regulator *regulator = ERR_PTR(-ENODEV);
const char *devname = NULL;
+ struct device_node *node;
int ret;
if (id == NULL) {
@@ -1167,6 +1170,15 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
mutex_lock(®ulator_list_mutex);
+ if (dev->of_node) {
+ node = of_get_regulator(dev, id);
+ if (!node)
+ goto retry; /* fallback and chk regulator_map_list */
+ list_for_each_entry(rdev, ®ulator_list, list)
+ if (node == rdev->node)
+ goto found;
+ }
+retry:
list_for_each_entry(map, ®ulator_map_list, list) {
/* If the mapping has a device set up it must match */
if (map->dev_name &&
@@ -2619,6 +2631,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
rdev->reg_data = driver_data;
rdev->owner = regulator_desc->owner;
rdev->desc = regulator_desc;
+ if (dev && dev->of_node)
+ rdev->node = dev->of_node;
INIT_LIST_HEAD(&rdev->consumer_list);
INIT_LIST_HEAD(&rdev->list);
BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 1a80bc7..4aebbf5 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -196,6 +196,9 @@ struct regulator_dev {
struct mutex mutex; /* consumer lock */
struct module *owner;
struct device dev;
+#ifdef CONFIG_OF
+ struct device_node *node;
+#endif
struct regulation_constraints *constraints;
struct regulator *supply; /* for tree */
--
1.7.1
^ permalink raw reply related [flat|nested] 114+ messages in thread
* Re: [PATCH 1/9] regulator: twl: Remove hardcoded board constraints from driver
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-27 11:37 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 11:37 UTC (permalink / raw)
To: Rajendra Nayak
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
On Tue, Sep 27, 2011 at 03:42:44PM +0530, Rajendra Nayak wrote:
> Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
> each regulator from the twl driver and let the boards pass it.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> - /* Constrain board-specific capabilities according to what
> - * this driver and the chip itself can actually do.
> - */
> - c = &initdata->constraints;
> - c->valid_modes_mask &= REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY;
> - c->valid_ops_mask &= REGULATOR_CHANGE_VOLTAGE
> - | REGULATOR_CHANGE_MODE
> - | REGULATOR_CHANGE_STATUS;
This isn't actually hard coding constraints, this is restricting the
constraints passed in further rather than adding new ones.
However should be fine:
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 1/9] regulator: twl: Remove hardcoded board constraints from driver
@ 2011-09-27 11:37 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 11:37 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 27, 2011 at 03:42:44PM +0530, Rajendra Nayak wrote:
> Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
> each regulator from the twl driver and let the boards pass it.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> - /* Constrain board-specific capabilities according to what
> - * this driver and the chip itself can actually do.
> - */
> - c = &initdata->constraints;
> - c->valid_modes_mask &= REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY;
> - c->valid_ops_mask &= REGULATOR_CHANGE_VOLTAGE
> - | REGULATOR_CHANGE_MODE
> - | REGULATOR_CHANGE_STATUS;
This isn't actually hard coding constraints, this is restricting the
constraints passed in further rather than adding new ones.
However should be fine:
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-27 12:10 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 12:10 UTC (permalink / raw)
To: Rajendra Nayak
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
> + init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
> + GFP_KERNEL);
> + if (!init_data)
> + return NULL; /* Out of memory? */
This means that the init data will be kept around for the entire
lifetime of the device rather than being discarded.
> + init_data->supply_regulator = (char *)of_get_property(dev->of_node,
> + "regulator-supplies", NULL);
I'd expect that in the device tree world the supply regulator would
reference the node for that regulator.
> /* voltage output range (inclusive) - for voltage control */
> - int min_uV;
> - int max_uV;
> + u32 min_uV;
> + u32 max_uV;
>
> - int uV_offset;
> + u32 uV_offset;
>
> /* current output range (inclusive) - for current control */
> - int min_uA;
> - int max_uA;
> + u32 min_uA;
> + u32 max_uA;
Hrm, I think loosing the signs here is bad karma - negative voltages do
exist after all.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-09-27 12:10 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 12:10 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
> + init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
> + GFP_KERNEL);
> + if (!init_data)
> + return NULL; /* Out of memory? */
This means that the init data will be kept around for the entire
lifetime of the device rather than being discarded.
> + init_data->supply_regulator = (char *)of_get_property(dev->of_node,
> + "regulator-supplies", NULL);
I'd expect that in the device tree world the supply regulator would
reference the node for that regulator.
> /* voltage output range (inclusive) - for voltage control */
> - int min_uV;
> - int max_uV;
> + u32 min_uV;
> + u32 max_uV;
>
> - int uV_offset;
> + u32 uV_offset;
>
> /* current output range (inclusive) - for current control */
> - int min_uA;
> - int max_uA;
> + u32 min_uA;
> + u32 max_uA;
Hrm, I think loosing the signs here is bad karma - negative voltages do
exist after all.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 4/9] regulator: twl: Make twl-regulator driver extract data from DT
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-27 12:14 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 12:14 UTC (permalink / raw)
To: Rajendra Nayak
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
On Tue, Sep 27, 2011 at 03:42:47PM +0530, Rajendra Nayak wrote:
> +#ifdef CONFIG_OF
> + char compatible[128];
> +#endif
Might it not be better to just make this a pointer to const char?
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 4/9] regulator: twl: Make twl-regulator driver extract data from DT
@ 2011-09-27 12:14 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 12:14 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 27, 2011 at 03:42:47PM +0530, Rajendra Nayak wrote:
> +#ifdef CONFIG_OF
> + char compatible[128];
> +#endif
Might it not be better to just make this a pointer to const char?
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 5/9] regulator: helper routine to extract fixed_voltage_config
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-27 12:16 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 12:16 UTC (permalink / raw)
To: Rajendra Nayak
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
On Tue, Sep 27, 2011 at 03:42:48PM +0530, Rajendra Nayak wrote:
> The helper routine of_get_fixed_voltage_config() extracts
> fixed_voltage_config structure contents from device tree.
>
> Also add documenation for additional bindings for fixed
> regulators that can be passed through dt.
Why not just add device tree support into the driver directly?
> +Optional properties:
> +- regulator-fixed-supply: Name of the regulator supply
This is going to be confusing with respect to the generic regulator
supply property.
> +- regulator-fixed-enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low
Word wrap for legibility please.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 5/9] regulator: helper routine to extract fixed_voltage_config
@ 2011-09-27 12:16 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 12:16 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 27, 2011 at 03:42:48PM +0530, Rajendra Nayak wrote:
> The helper routine of_get_fixed_voltage_config() extracts
> fixed_voltage_config structure contents from device tree.
>
> Also add documenation for additional bindings for fixed
> regulators that can be passed through dt.
Why not just add device tree support into the driver directly?
> +Optional properties:
> +- regulator-fixed-supply: Name of the regulator supply
This is going to be confusing with respect to the generic regulator
supply property.
> +- regulator-fixed-enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low
Word wrap for legibility please.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 8/9] regulator: helper to extract regulator node based on supply name
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-27 12:21 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 12:21 UTC (permalink / raw)
To: Rajendra Nayak
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
> + if (!dev)
> + return NULL;
So how do we handle CPUs? cpufreq is one of the most active users of
regulators...
> + snprintf(prop_name, 32, "%s-supply", supply);
> +
> + prop = of_get_property(dev->of_node, prop_name, &sz);
> + if (!prop || sz < 4)
> + return NULL;
sz < 4? Magic! :)
> +extern struct device_node *of_get_regulator(struct device *dev,
> + const char *supply);
This shouldn't be part of the public API, it should be transparently
handled within the core.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 8/9] regulator: helper to extract regulator node based on supply name
@ 2011-09-27 12:21 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 12:21 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
> + if (!dev)
> + return NULL;
So how do we handle CPUs? cpufreq is one of the most active users of
regulators...
> + snprintf(prop_name, 32, "%s-supply", supply);
> +
> + prop = of_get_property(dev->of_node, prop_name, &sz);
> + if (!prop || sz < 4)
> + return NULL;
sz < 4? Magic! :)
> +extern struct device_node *of_get_regulator(struct device *dev,
> + const char *supply);
This shouldn't be part of the public API, it should be transparently
handled within the core.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 9/9] regulator: map consumer regulator based on device tree
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-27 12:23 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 12:23 UTC (permalink / raw)
To: Rajendra Nayak
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
On Tue, Sep 27, 2011 at 03:42:52PM +0530, Rajendra Nayak wrote:
> Look up the regulator for a given consumer from device tree, during
> a regulator_get(). If not found fallback and lookup through
> the regulator_map_list instead.
As with the fixed voltage regulator patch just use the code along with
adding it, no need to split it just makes it harder to review.
> + if (dev->of_node) {
> + node = of_get_regulator(dev, id);
> + if (!node)
> + goto retry; /* fallback and chk regulator_map_list */
> + list_for_each_entry(rdev, ®ulator_list, list)
> + if (node == rdev->node)
> + goto found;
> + }
> +retry:
retry is a confusing name for the target, we don't ever actually retry
using it. Given the simplicity of the code I'd be inclined to just
intert the if (!node) check.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 9/9] regulator: map consumer regulator based on device tree
@ 2011-09-27 12:23 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 12:23 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 27, 2011 at 03:42:52PM +0530, Rajendra Nayak wrote:
> Look up the regulator for a given consumer from device tree, during
> a regulator_get(). If not found fallback and lookup through
> the regulator_map_list instead.
As with the fixed voltage regulator patch just use the code along with
adding it, no need to split it just makes it harder to review.
> + if (dev->of_node) {
> + node = of_get_regulator(dev, id);
> + if (!node)
> + goto retry; /* fallback and chk regulator_map_list */
> + list_for_each_entry(rdev, ®ulator_list, list)
> + if (node == rdev->node)
> + goto found;
> + }
> +retry:
retry is a confusing name for the target, we don't ever actually retry
using it. Given the simplicity of the code I'd be inclined to just
intert the if (!node) check.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 1/9] regulator: twl: Remove hardcoded board constraints from driver
2011-09-27 11:37 ` Mark Brown
@ 2011-09-27 14:47 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 14:47 UTC (permalink / raw)
To: Mark Brown
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
On Tuesday 27 September 2011 05:07 PM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:44PM +0530, Rajendra Nayak wrote:
>> Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
>> each regulator from the twl driver and let the boards pass it.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>
>
>> - /* Constrain board-specific capabilities according to what
>> - * this driver and the chip itself can actually do.
>> - */
>> - c =&initdata->constraints;
>> - c->valid_modes_mask&= REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY;
>> - c->valid_ops_mask&= REGULATOR_CHANGE_VOLTAGE
>> - | REGULATOR_CHANGE_MODE
>> - | REGULATOR_CHANGE_STATUS;
>
> This isn't actually hard coding constraints, this is restricting the
> constraints passed in further rather than adding new ones.
>
> However should be fine:
>
> Acked-by: Mark Brown<broonie@opensource.wolfsonmicro.com>
Thanks.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 1/9] regulator: twl: Remove hardcoded board constraints from driver
@ 2011-09-27 14:47 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 14:47 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 27 September 2011 05:07 PM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:44PM +0530, Rajendra Nayak wrote:
>> Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
>> each regulator from the twl driver and let the boards pass it.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>
>
>> - /* Constrain board-specific capabilities according to what
>> - * this driver and the chip itself can actually do.
>> - */
>> - c =&initdata->constraints;
>> - c->valid_modes_mask&= REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY;
>> - c->valid_ops_mask&= REGULATOR_CHANGE_VOLTAGE
>> - | REGULATOR_CHANGE_MODE
>> - | REGULATOR_CHANGE_STATUS;
>
> This isn't actually hard coding constraints, this is restricting the
> constraints passed in further rather than adding new ones.
>
> However should be fine:
>
> Acked-by: Mark Brown<broonie@opensource.wolfsonmicro.com>
Thanks.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-09-27 12:10 ` Mark Brown
@ 2011-09-27 14:48 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 14:48 UTC (permalink / raw)
To: Mark Brown
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
On Tuesday 27 September 2011 05:40 PM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
>
>> + init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
>> + GFP_KERNEL);
>> + if (!init_data)
>> + return NULL; /* Out of memory? */
>
> This means that the init data will be kept around for the entire
> lifetime of the device rather than being discarded.
Wasn't it the same while this was passed around as platform_data?
>
>> + init_data->supply_regulator = (char *)of_get_property(dev->of_node,
>> + "regulator-supplies", NULL);
>
> I'd expect that in the device tree world the supply regulator would
> reference the node for that regulator.
You mean using phandles? Thats what Grant proposed too but
I thought you instead had an inclination towards names? Or maybe
I misunderstood.
>
>> /* voltage output range (inclusive) - for voltage control */
>> - int min_uV;
>> - int max_uV;
>> + u32 min_uV;
>> + u32 max_uV;
>>
>> - int uV_offset;
>> + u32 uV_offset;
>>
>> /* current output range (inclusive) - for current control */
>> - int min_uA;
>> - int max_uA;
>> + u32 min_uA;
>> + u32 max_uA;
>
> Hrm, I think loosing the signs here is bad karma - negative voltages do
> exist after all.
Oops.. they do? didn't know about that.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-09-27 14:48 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 14:48 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 27 September 2011 05:40 PM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
>
>> + init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
>> + GFP_KERNEL);
>> + if (!init_data)
>> + return NULL; /* Out of memory? */
>
> This means that the init data will be kept around for the entire
> lifetime of the device rather than being discarded.
Wasn't it the same while this was passed around as platform_data?
>
>> + init_data->supply_regulator = (char *)of_get_property(dev->of_node,
>> + "regulator-supplies", NULL);
>
> I'd expect that in the device tree world the supply regulator would
> reference the node for that regulator.
You mean using phandles? Thats what Grant proposed too but
I thought you instead had an inclination towards names? Or maybe
I misunderstood.
>
>> /* voltage output range (inclusive) - for voltage control */
>> - int min_uV;
>> - int max_uV;
>> + u32 min_uV;
>> + u32 max_uV;
>>
>> - int uV_offset;
>> + u32 uV_offset;
>>
>> /* current output range (inclusive) - for current control */
>> - int min_uA;
>> - int max_uA;
>> + u32 min_uA;
>> + u32 max_uA;
>
> Hrm, I think loosing the signs here is bad karma - negative voltages do
> exist after all.
Oops.. they do? didn't know about that.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 4/9] regulator: twl: Make twl-regulator driver extract data from DT
2011-09-27 12:14 ` Mark Brown
@ 2011-09-27 14:48 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 14:48 UTC (permalink / raw)
To: Mark Brown
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
On Tuesday 27 September 2011 05:44 PM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:47PM +0530, Rajendra Nayak wrote:
>
>> +#ifdef CONFIG_OF
>> + char compatible[128];
>> +#endif
>
> Might it not be better to just make this a pointer to const char?
Yes, my bad.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 4/9] regulator: twl: Make twl-regulator driver extract data from DT
@ 2011-09-27 14:48 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 14:48 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 27 September 2011 05:44 PM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:47PM +0530, Rajendra Nayak wrote:
>
>> +#ifdef CONFIG_OF
>> + char compatible[128];
>> +#endif
>
> Might it not be better to just make this a pointer to const char?
Yes, my bad.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 5/9] regulator: helper routine to extract fixed_voltage_config
2011-09-27 12:16 ` Mark Brown
@ 2011-09-27 14:49 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 14:49 UTC (permalink / raw)
To: Mark Brown
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
On Tuesday 27 September 2011 05:46 PM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:48PM +0530, Rajendra Nayak wrote:
>> The helper routine of_get_fixed_voltage_config() extracts
>> fixed_voltage_config structure contents from device tree.
>>
>> Also add documenation for additional bindings for fixed
>> regulators that can be passed through dt.
>
> Why not just add device tree support into the driver directly?
Ok, will do.
>
>> +Optional properties:
>> +- regulator-fixed-supply: Name of the regulator supply
>
> This is going to be confusing with respect to the generic regulator
> supply property.
Yes, I guess. Any suggestions on how to make it less
confusing? :-)
>
>> +- regulator-fixed-enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low
>
> Word wrap for legibility please.
Ok.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 5/9] regulator: helper routine to extract fixed_voltage_config
@ 2011-09-27 14:49 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 14:49 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 27 September 2011 05:46 PM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:48PM +0530, Rajendra Nayak wrote:
>> The helper routine of_get_fixed_voltage_config() extracts
>> fixed_voltage_config structure contents from device tree.
>>
>> Also add documenation for additional bindings for fixed
>> regulators that can be passed through dt.
>
> Why not just add device tree support into the driver directly?
Ok, will do.
>
>> +Optional properties:
>> +- regulator-fixed-supply: Name of the regulator supply
>
> This is going to be confusing with respect to the generic regulator
> supply property.
Yes, I guess. Any suggestions on how to make it less
confusing? :-)
>
>> +- regulator-fixed-enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low
>
> Word wrap for legibility please.
Ok.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 8/9] regulator: helper to extract regulator node based on supply name
2011-09-27 12:21 ` Mark Brown
@ 2011-09-27 14:49 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 14:49 UTC (permalink / raw)
To: Mark Brown
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
>
>> + if (!dev)
>> + return NULL;
>
> So how do we handle CPUs? cpufreq is one of the most active users of
> regulators...
Hmm, never thought of it :(
Maybe I should associate a supply name with all
regulators and then lookup from the global registered
list.
>
>> + snprintf(prop_name, 32, "%s-supply", supply);
>> +
>> + prop = of_get_property(dev->of_node, prop_name,&sz);
>> + if (!prop || sz< 4)
>> + return NULL;
>
> sz< 4? Magic! :)
Its the valid phandle size.
I guess I need a sz != 4
>
>> +extern struct device_node *of_get_regulator(struct device *dev,
>> + const char *supply);
>
> This shouldn't be part of the public API, it should be transparently
> handled within the core.
agreed.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 8/9] regulator: helper to extract regulator node based on supply name
@ 2011-09-27 14:49 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 14:49 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
>
>> + if (!dev)
>> + return NULL;
>
> So how do we handle CPUs? cpufreq is one of the most active users of
> regulators...
Hmm, never thought of it :(
Maybe I should associate a supply name with all
regulators and then lookup from the global registered
list.
>
>> + snprintf(prop_name, 32, "%s-supply", supply);
>> +
>> + prop = of_get_property(dev->of_node, prop_name,&sz);
>> + if (!prop || sz< 4)
>> + return NULL;
>
> sz< 4? Magic! :)
Its the valid phandle size.
I guess I need a sz != 4
>
>> +extern struct device_node *of_get_regulator(struct device *dev,
>> + const char *supply);
>
> This shouldn't be part of the public API, it should be transparently
> handled within the core.
agreed.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 9/9] regulator: map consumer regulator based on device tree
2011-09-27 12:23 ` Mark Brown
@ 2011-09-27 14:49 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 14:49 UTC (permalink / raw)
To: Mark Brown
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
On Tuesday 27 September 2011 05:53 PM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:52PM +0530, Rajendra Nayak wrote:
>> Look up the regulator for a given consumer from device tree, during
>> a regulator_get(). If not found fallback and lookup through
>> the regulator_map_list instead.
>
> As with the fixed voltage regulator patch just use the code along with
> adding it, no need to split it just makes it harder to review.
Ok.
>
>> + if (dev->of_node) {
>> + node = of_get_regulator(dev, id);
>> + if (!node)
>> + goto retry; /* fallback and chk regulator_map_list */
>> + list_for_each_entry(rdev,®ulator_list, list)
>> + if (node == rdev->node)
>> + goto found;
>> + }
>> +retry:
>
> retry is a confusing name for the target, we don't ever actually retry
> using it. Given the simplicity of the code I'd be inclined to just
> intert the if (!node) check.
Ok.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 9/9] regulator: map consumer regulator based on device tree
@ 2011-09-27 14:49 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-27 14:49 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 27 September 2011 05:53 PM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:52PM +0530, Rajendra Nayak wrote:
>> Look up the regulator for a given consumer from device tree, during
>> a regulator_get(). If not found fallback and lookup through
>> the regulator_map_list instead.
>
> As with the fixed voltage regulator patch just use the code along with
> adding it, no need to split it just makes it harder to review.
Ok.
>
>> + if (dev->of_node) {
>> + node = of_get_regulator(dev, id);
>> + if (!node)
>> + goto retry; /* fallback and chk regulator_map_list */
>> + list_for_each_entry(rdev,®ulator_list, list)
>> + if (node == rdev->node)
>> + goto found;
>> + }
>> +retry:
>
> retry is a confusing name for the target, we don't ever actually retry
> using it. Given the simplicity of the code I'd be inclined to just
> intert the if (!node) check.
Ok.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-09-27 14:48 ` Rajendra Nayak
@ 2011-09-27 15:05 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 15:05 UTC (permalink / raw)
To: Rajendra Nayak
Cc: patches-QSEj5FYQhm4dnm+yROfE0A, tony-4v6yS6AI5VpBDgjK7y7TUQ,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-omap-u79uwXL29TY76Z2rM5mHXA, lrg-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Tue, Sep 27, 2011 at 08:18:04PM +0530, Rajendra Nayak wrote:
> On Tuesday 27 September 2011 05:40 PM, Mark Brown wrote:
> >On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
> >>+ init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
> >>+ GFP_KERNEL);
> >>+ if (!init_data)
> >>+ return NULL; /* Out of memory? */
> >This means that the init data will be kept around for the entire
> >lifetime of the device rather than being discarded.
> Wasn't it the same while this was passed around as platform_data?
It was in the past but I remember fixing it at some point. Perhaps I'm
imagining things.
> >>+ init_data->supply_regulator = (char *)of_get_property(dev->of_node,
> >>+ "regulator-supplies", NULL);
> >I'd expect that in the device tree world the supply regulator would
> >reference the node for that regulator.
> You mean using phandles? Thats what Grant proposed too but
> I thought you instead had an inclination towards names? Or maybe
> I misunderstood.
They need both. We need to reference the device that provides the
supply and use a name to say which of the potentially multiple supplies
on the consumer device is which.
> >Hrm, I think loosing the signs here is bad karma - negative voltages do
> >exist after all.
> Oops.. they do? didn't know about that.
Yup, ground is just a reference point.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-09-27 15:05 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 15:05 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 27, 2011 at 08:18:04PM +0530, Rajendra Nayak wrote:
> On Tuesday 27 September 2011 05:40 PM, Mark Brown wrote:
> >On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
> >>+ init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
> >>+ GFP_KERNEL);
> >>+ if (!init_data)
> >>+ return NULL; /* Out of memory? */
> >This means that the init data will be kept around for the entire
> >lifetime of the device rather than being discarded.
> Wasn't it the same while this was passed around as platform_data?
It was in the past but I remember fixing it at some point. Perhaps I'm
imagining things.
> >>+ init_data->supply_regulator = (char *)of_get_property(dev->of_node,
> >>+ "regulator-supplies", NULL);
> >I'd expect that in the device tree world the supply regulator would
> >reference the node for that regulator.
> You mean using phandles? Thats what Grant proposed too but
> I thought you instead had an inclination towards names? Or maybe
> I misunderstood.
They need both. We need to reference the device that provides the
supply and use a name to say which of the potentially multiple supplies
on the consumer device is which.
> >Hrm, I think loosing the signs here is bad karma - negative voltages do
> >exist after all.
> Oops.. they do? didn't know about that.
Yup, ground is just a reference point.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 5/9] regulator: helper routine to extract fixed_voltage_config
2011-09-27 14:49 ` Rajendra Nayak
@ 2011-09-27 16:13 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 16:13 UTC (permalink / raw)
To: Rajendra Nayak
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
On Tue, Sep 27, 2011 at 08:19:00PM +0530, Rajendra Nayak wrote:
> On Tuesday 27 September 2011 05:46 PM, Mark Brown wrote:
> >On Tue, Sep 27, 2011 at 03:42:48PM +0530, Rajendra Nayak wrote:
> >>+Optional properties:
> >>+- regulator-fixed-supply: Name of the regulator supply
> >This is going to be confusing with respect to the generic regulator
> >supply property.
> Yes, I guess. Any suggestions on how to make it less
> confusing? :-)
Call it display-name or something?
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 5/9] regulator: helper routine to extract fixed_voltage_config
@ 2011-09-27 16:13 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 16:13 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 27, 2011 at 08:19:00PM +0530, Rajendra Nayak wrote:
> On Tuesday 27 September 2011 05:46 PM, Mark Brown wrote:
> >On Tue, Sep 27, 2011 at 03:42:48PM +0530, Rajendra Nayak wrote:
> >>+Optional properties:
> >>+- regulator-fixed-supply: Name of the regulator supply
> >This is going to be confusing with respect to the generic regulator
> >supply property.
> Yes, I guess. Any suggestions on how to make it less
> confusing? :-)
Call it display-name or something?
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 8/9] regulator: helper to extract regulator node based on supply name
2011-09-27 14:49 ` Rajendra Nayak
@ 2011-09-27 18:59 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 18:59 UTC (permalink / raw)
To: Rajendra Nayak
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
On Tue, Sep 27, 2011 at 08:19:37PM +0530, Rajendra Nayak wrote:
> On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:
> >On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
> >>+ if (!dev)
> >>+ return NULL;
> >So how do we handle CPUs? cpufreq is one of the most active users of
> >regulators...
> Hmm, never thought of it :(
> Maybe I should associate a supply name with all
> regulators and then lookup from the global registered
> list.
I'm not sure how this should work in a device tree world, I'd *hope*
we'd get a device tree node for the CPU and could then just make this a
regular consumer thing but then the cpufreq drivers would need to be
updated to make use of it. The only reason we allow null devices right
now is the fact that cpufreq doesn't have a struct device it can use.
> >>+ snprintf(prop_name, 32, "%s-supply", supply);
> >>+
> >>+ prop = of_get_property(dev->of_node, prop_name,&sz);
> >>+ if (!prop || sz< 4)
> >>+ return NULL;
> >sz< 4? Magic! :)
> Its the valid phandle size.
> I guess I need a sz != 4
I think we need an of_get_phandle(), it'd be clearer what the check is,
more type safe and would avoid needing to replicate the check.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 8/9] regulator: helper to extract regulator node based on supply name
@ 2011-09-27 18:59 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-27 18:59 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 27, 2011 at 08:19:37PM +0530, Rajendra Nayak wrote:
> On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:
> >On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
> >>+ if (!dev)
> >>+ return NULL;
> >So how do we handle CPUs? cpufreq is one of the most active users of
> >regulators...
> Hmm, never thought of it :(
> Maybe I should associate a supply name with all
> regulators and then lookup from the global registered
> list.
I'm not sure how this should work in a device tree world, I'd *hope*
we'd get a device tree node for the CPU and could then just make this a
regular consumer thing but then the cpufreq drivers would need to be
updated to make use of it. The only reason we allow null devices right
now is the fact that cpufreq doesn't have a struct device it can use.
> >>+ snprintf(prop_name, 32, "%s-supply", supply);
> >>+
> >>+ prop = of_get_property(dev->of_node, prop_name,&sz);
> >>+ if (!prop || sz< 4)
> >>+ return NULL;
> >sz< 4? Magic! :)
> Its the valid phandle size.
> I guess I need a sz != 4
I think we need an of_get_phandle(), it'd be clearer what the check is,
more type safe and would avoid needing to replicate the check.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-09-27 15:05 ` Mark Brown
@ 2011-09-28 8:06 ` Cousson, Benoit
-1 siblings, 0 replies; 114+ messages in thread
From: Cousson, Benoit @ 2011-09-28 8:06 UTC (permalink / raw)
To: Nayak, Rajendra
Cc: patches, tony, devicetree-discuss, Mark Brown, grant.likely,
linux-omap, Girdwood, Liam, linux-arm-kernel
On 9/27/2011 5:05 PM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 08:18:04PM +0530, Rajendra Nayak wrote:
>> On Tuesday 27 September 2011 05:40 PM, Mark Brown wrote:
>>> On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
>
>>>> + init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
>>>> + GFP_KERNEL);
>>>> + if (!init_data)
>>>> + return NULL; /* Out of memory? */
>
>>> This means that the init data will be kept around for the entire
>>> lifetime of the device rather than being discarded.
>
>> Wasn't it the same while this was passed around as platform_data?
>
> It was in the past but I remember fixing it at some point. Perhaps I'm
> imagining things.
>
>>>> + init_data->supply_regulator = (char *)of_get_property(dev->of_node,
>>>> + "regulator-supplies", NULL);
>
>>> I'd expect that in the device tree world the supply regulator would
>>> reference the node for that regulator.
>
>> You mean using phandles? Thats what Grant proposed too but
>> I thought you instead had an inclination towards names? Or maybe
>> I misunderstood.
>
> They need both. We need to reference the device that provides the
> supply and use a name to say which of the potentially multiple supplies
> on the consumer device is which.
>
>>> Hrm, I think loosing the signs here is bad karma - negative voltages do
>>> exist after all.
>
>> Oops.. they do? didn't know about that.
>
> Yup, ground is just a reference point.
Yep, we do have a negative charge pump to generate -1.9v from 3.8v to
supply the audio power amplifier part in twl6040 for example.
Benoit
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-09-28 8:06 ` Cousson, Benoit
0 siblings, 0 replies; 114+ messages in thread
From: Cousson, Benoit @ 2011-09-28 8:06 UTC (permalink / raw)
To: linux-arm-kernel
On 9/27/2011 5:05 PM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 08:18:04PM +0530, Rajendra Nayak wrote:
>> On Tuesday 27 September 2011 05:40 PM, Mark Brown wrote:
>>> On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
>
>>>> + init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
>>>> + GFP_KERNEL);
>>>> + if (!init_data)
>>>> + return NULL; /* Out of memory? */
>
>>> This means that the init data will be kept around for the entire
>>> lifetime of the device rather than being discarded.
>
>> Wasn't it the same while this was passed around as platform_data?
>
> It was in the past but I remember fixing it at some point. Perhaps I'm
> imagining things.
>
>>>> + init_data->supply_regulator = (char *)of_get_property(dev->of_node,
>>>> + "regulator-supplies", NULL);
>
>>> I'd expect that in the device tree world the supply regulator would
>>> reference the node for that regulator.
>
>> You mean using phandles? Thats what Grant proposed too but
>> I thought you instead had an inclination towards names? Or maybe
>> I misunderstood.
>
> They need both. We need to reference the device that provides the
> supply and use a name to say which of the potentially multiple supplies
> on the consumer device is which.
>
>>> Hrm, I think loosing the signs here is bad karma - negative voltages do
>>> exist after all.
>
>> Oops.. they do? didn't know about that.
>
> Yup, ground is just a reference point.
Yep, we do have a negative charge pump to generate -1.9v from 3.8v to
supply the audio power amplifier part in twl6040 for example.
Benoit
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 8/9] regulator: helper to extract regulator node based on supply name
2011-09-27 18:59 ` Mark Brown
@ 2011-09-28 8:09 ` Cousson, Benoit
-1 siblings, 0 replies; 114+ messages in thread
From: Cousson, Benoit @ 2011-09-28 8:09 UTC (permalink / raw)
To: Mark Brown
Cc: patches, tony, devicetree-discuss, Nayak, Rajendra, grant.likely,
linux-omap, Girdwood, Liam, linux-arm-kernel
On 9/27/2011 8:59 PM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 08:19:37PM +0530, Rajendra Nayak wrote:
>> On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:
>>> On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
>
>>>> + if (!dev)
>>>> + return NULL;
>
>>> So how do we handle CPUs? cpufreq is one of the most active users of
>>> regulators...
>
>> Hmm, never thought of it :(
>> Maybe I should associate a supply name with all
>> regulators and then lookup from the global registered
>> list.
>
> I'm not sure how this should work in a device tree world, I'd *hope*
> we'd get a device tree node for the CPU and could then just make this a
> regular consumer thing but then the cpufreq drivers would need to be
> updated to make use of it. The only reason we allow null devices right
> now is the fact that cpufreq doesn't have a struct device it can use.
That's why we do have a MPU node in OMAP dts, in order to build an
omap_device that will be mainly used for the DVFS on the MPU.
And even before DT migration, we used to build statically some
omap_device to represent the various processors in the system (MPU, DSP,
CortexM3...).
Regards,
Benoit
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 8/9] regulator: helper to extract regulator node based on supply name
@ 2011-09-28 8:09 ` Cousson, Benoit
0 siblings, 0 replies; 114+ messages in thread
From: Cousson, Benoit @ 2011-09-28 8:09 UTC (permalink / raw)
To: linux-arm-kernel
On 9/27/2011 8:59 PM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 08:19:37PM +0530, Rajendra Nayak wrote:
>> On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:
>>> On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
>
>>>> + if (!dev)
>>>> + return NULL;
>
>>> So how do we handle CPUs? cpufreq is one of the most active users of
>>> regulators...
>
>> Hmm, never thought of it :(
>> Maybe I should associate a supply name with all
>> regulators and then lookup from the global registered
>> list.
>
> I'm not sure how this should work in a device tree world, I'd *hope*
> we'd get a device tree node for the CPU and could then just make this a
> regular consumer thing but then the cpufreq drivers would need to be
> updated to make use of it. The only reason we allow null devices right
> now is the fact that cpufreq doesn't have a struct device it can use.
That's why we do have a MPU node in OMAP dts, in order to build an
omap_device that will be mainly used for the DVFS on the MPU.
And even before DT migration, we used to build statically some
omap_device to represent the various processors in the system (MPU, DSP,
CortexM3...).
Regards,
Benoit
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 8/9] regulator: helper to extract regulator node based on supply name
2011-09-28 8:09 ` Cousson, Benoit
@ 2011-09-28 8:18 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-28 8:18 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Mark Brown, grant.likely, devicetree-discuss, linux-omap,
linux-arm-kernel, tony, Girdwood, Liam, patches
On Wednesday 28 September 2011 01:39 PM, Cousson, Benoit wrote:
> On 9/27/2011 8:59 PM, Mark Brown wrote:
>> On Tue, Sep 27, 2011 at 08:19:37PM +0530, Rajendra Nayak wrote:
>>> On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:
>>>> On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
>>
>>>>> + if (!dev)
>>>>> + return NULL;
>>
>>>> So how do we handle CPUs? cpufreq is one of the most active users of
>>>> regulators...
>>
>>> Hmm, never thought of it :(
>>> Maybe I should associate a supply name with all
>>> regulators and then lookup from the global registered
>>> list.
>>
>> I'm not sure how this should work in a device tree world, I'd *hope*
>> we'd get a device tree node for the CPU and could then just make this a
>> regular consumer thing but then the cpufreq drivers would need to be
>> updated to make use of it. The only reason we allow null devices right
>> now is the fact that cpufreq doesn't have a struct device it can use.
>
> That's why we do have a MPU node in OMAP dts, in order to build an
> omap_device that will be mainly used for the DVFS on the MPU.
>
> And even before DT migration, we used to build statically some
> omap_device to represent the various processors in the system (MPU, DSP,
> CortexM3...).
yes, but clearly not everyone seems to do this. and then there are
also these instances of board files requesting regulators without
associating them with any device :(
>
> Regards,
> Benoit
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 8/9] regulator: helper to extract regulator node based on supply name
@ 2011-09-28 8:18 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-28 8:18 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 28 September 2011 01:39 PM, Cousson, Benoit wrote:
> On 9/27/2011 8:59 PM, Mark Brown wrote:
>> On Tue, Sep 27, 2011 at 08:19:37PM +0530, Rajendra Nayak wrote:
>>> On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:
>>>> On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
>>
>>>>> + if (!dev)
>>>>> + return NULL;
>>
>>>> So how do we handle CPUs? cpufreq is one of the most active users of
>>>> regulators...
>>
>>> Hmm, never thought of it :(
>>> Maybe I should associate a supply name with all
>>> regulators and then lookup from the global registered
>>> list.
>>
>> I'm not sure how this should work in a device tree world, I'd *hope*
>> we'd get a device tree node for the CPU and could then just make this a
>> regular consumer thing but then the cpufreq drivers would need to be
>> updated to make use of it. The only reason we allow null devices right
>> now is the fact that cpufreq doesn't have a struct device it can use.
>
> That's why we do have a MPU node in OMAP dts, in order to build an
> omap_device that will be mainly used for the DVFS on the MPU.
>
> And even before DT migration, we used to build statically some
> omap_device to represent the various processors in the system (MPU, DSP,
> CortexM3...).
yes, but clearly not everyone seems to do this. and then there are
also these instances of board files requesting regulators without
associating them with any device :(
>
> Regards,
> Benoit
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 8/9] regulator: helper to extract regulator node based on supply name
2011-09-27 18:59 ` Mark Brown
@ 2011-09-28 10:56 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-28 10:56 UTC (permalink / raw)
To: Mark Brown
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
On Wednesday 28 September 2011 12:29 AM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 08:19:37PM +0530, Rajendra Nayak wrote:
>> On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:
>>> On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
>
>>>> + if (!dev)
>>>> + return NULL;
>
>>> So how do we handle CPUs? cpufreq is one of the most active users of
>>> regulators...
>
>> Hmm, never thought of it :(
>> Maybe I should associate a supply name with all
>> regulators and then lookup from the global registered
>> list.
>
> I'm not sure how this should work in a device tree world, I'd *hope*
> we'd get a device tree node for the CPU and could then just make this a
> regular consumer thing but then the cpufreq drivers would need to be
> updated to make use of it. The only reason we allow null devices right
> now is the fact that cpufreq doesn't have a struct device it can use.
>
>>>> + snprintf(prop_name, 32, "%s-supply", supply);
>>>> +
>>>> + prop = of_get_property(dev->of_node, prop_name,&sz);
>>>> + if (!prop || sz< 4)
>>>> + return NULL;
>
>>> sz< 4? Magic! :)
>
>> Its the valid phandle size.
>> I guess I need a sz != 4
>
> I think we need an of_get_phandle(), it'd be clearer what the check is,
> more type safe and would avoid needing to replicate the check.
Yes, there already seems to be one, of_parse_phandle() which I should
have used. thanks.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 8/9] regulator: helper to extract regulator node based on supply name
@ 2011-09-28 10:56 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-28 10:56 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 28 September 2011 12:29 AM, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 08:19:37PM +0530, Rajendra Nayak wrote:
>> On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:
>>> On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
>
>>>> + if (!dev)
>>>> + return NULL;
>
>>> So how do we handle CPUs? cpufreq is one of the most active users of
>>> regulators...
>
>> Hmm, never thought of it :(
>> Maybe I should associate a supply name with all
>> regulators and then lookup from the global registered
>> list.
>
> I'm not sure how this should work in a device tree world, I'd *hope*
> we'd get a device tree node for the CPU and could then just make this a
> regular consumer thing but then the cpufreq drivers would need to be
> updated to make use of it. The only reason we allow null devices right
> now is the fact that cpufreq doesn't have a struct device it can use.
>
>>>> + snprintf(prop_name, 32, "%s-supply", supply);
>>>> +
>>>> + prop = of_get_property(dev->of_node, prop_name,&sz);
>>>> + if (!prop || sz< 4)
>>>> + return NULL;
>
>>> sz< 4? Magic! :)
>
>> Its the valid phandle size.
>> I guess I need a sz != 4
>
> I think we need an of_get_phandle(), it'd be clearer what the check is,
> more type safe and would avoid needing to replicate the check.
Yes, there already seems to be one, of_parse_phandle() which I should
have used. thanks.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 8/9] regulator: helper to extract regulator node based on supply name
2011-09-28 8:09 ` Cousson, Benoit
@ 2011-09-28 12:26 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-28 12:26 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Nayak, Rajendra, grant.likely, devicetree-discuss, linux-omap,
linux-arm-kernel, tony, Girdwood, Liam, patches
On Wed, Sep 28, 2011 at 10:09:30AM +0200, Cousson, Benoit wrote:
> On 9/27/2011 8:59 PM, Mark Brown wrote:
> >I'm not sure how this should work in a device tree world, I'd *hope*
> >we'd get a device tree node for the CPU and could then just make this a
> >regular consumer thing but then the cpufreq drivers would need to be
> >updated to make use of it. The only reason we allow null devices right
> >now is the fact that cpufreq doesn't have a struct device it can use.
> That's why we do have a MPU node in OMAP dts, in order to build an
> omap_device that will be mainly used for the DVFS on the MPU.
> And even before DT migration, we used to build statically some
> omap_device to represent the various processors in the system (MPU,
> DSP, CortexM3...).
Yeah, but that's very OMAP specific - we don't have that in general (in
fact it's the only Linux platform I'm aware of that has a device for the
CPU).
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 8/9] regulator: helper to extract regulator node based on supply name
@ 2011-09-28 12:26 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-28 12:26 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Sep 28, 2011 at 10:09:30AM +0200, Cousson, Benoit wrote:
> On 9/27/2011 8:59 PM, Mark Brown wrote:
> >I'm not sure how this should work in a device tree world, I'd *hope*
> >we'd get a device tree node for the CPU and could then just make this a
> >regular consumer thing but then the cpufreq drivers would need to be
> >updated to make use of it. The only reason we allow null devices right
> >now is the fact that cpufreq doesn't have a struct device it can use.
> That's why we do have a MPU node in OMAP dts, in order to build an
> omap_device that will be mainly used for the DVFS on the MPU.
> And even before DT migration, we used to build statically some
> omap_device to represent the various processors in the system (MPU,
> DSP, CortexM3...).
Yeah, but that's very OMAP specific - we don't have that in general (in
fact it's the only Linux platform I'm aware of that has a device for the
CPU).
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-09-27 12:10 ` Mark Brown
@ 2011-09-30 1:24 ` Grant Likely
-1 siblings, 0 replies; 114+ messages in thread
From: Grant Likely @ 2011-09-30 1:24 UTC (permalink / raw)
To: Mark Brown
Cc: patches-QSEj5FYQhm4dnm+yROfE0A, tony-4v6yS6AI5VpBDgjK7y7TUQ,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-omap-u79uwXL29TY76Z2rM5mHXA, lrg-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Tue, Sep 27, 2011 at 01:10:04PM +0100, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
>
> > + init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
> > + GFP_KERNEL);
> > + if (!init_data)
> > + return NULL; /* Out of memory? */
>
> This means that the init data will be kept around for the entire
> lifetime of the device rather than being discarded.
>
> > + init_data->supply_regulator = (char *)of_get_property(dev->of_node,
> > + "regulator-supplies", NULL);
>
> I'd expect that in the device tree world the supply regulator would
> reference the node for that regulator.
Yes, I would expect the same.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-09-30 1:24 ` Grant Likely
0 siblings, 0 replies; 114+ messages in thread
From: Grant Likely @ 2011-09-30 1:24 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 27, 2011 at 01:10:04PM +0100, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
>
> > + init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
> > + GFP_KERNEL);
> > + if (!init_data)
> > + return NULL; /* Out of memory? */
>
> This means that the init data will be kept around for the entire
> lifetime of the device rather than being discarded.
>
> > + init_data->supply_regulator = (char *)of_get_property(dev->of_node,
> > + "regulator-supplies", NULL);
>
> I'd expect that in the device tree world the supply regulator would
> reference the node for that regulator.
Yes, I would expect the same.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 5/9] regulator: helper routine to extract fixed_voltage_config
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-30 1:26 ` Grant Likely
-1 siblings, 0 replies; 114+ messages in thread
From: Grant Likely @ 2011-09-30 1:26 UTC (permalink / raw)
To: Rajendra Nayak
Cc: patches-QSEj5FYQhm4dnm+yROfE0A, tony-4v6yS6AI5VpBDgjK7y7TUQ,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
linux-omap-u79uwXL29TY76Z2rM5mHXA, lrg-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Tue, Sep 27, 2011 at 03:42:48PM +0530, Rajendra Nayak wrote:
> The helper routine of_get_fixed_voltage_config() extracts
> fixed_voltage_config structure contents from device tree.
>
> Also add documenation for additional bindings for fixed
> regulators that can be passed through dt.
>
> Signed-off-by: Rajendra Nayak <rnayak-l0cyMroinI0@public.gmane.org>
> ---
> .../bindings/regulator/fixed-regulator.txt | 24 +++++++++++++
> drivers/regulator/fixed.c | 36 ++++++++++++++++++++
> include/linux/regulator/fixed.h | 6 ++--
> 3 files changed, 63 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/fixed-regulator.txt
>
> diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
> new file mode 100644
> index 0000000..a204cbd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
> @@ -0,0 +1,24 @@
> +Fixed Voltage regulators
> +
> +Required properties:
> +- compatible: Must be "regulator-fixed";
> +
> +Optional properties:
> +- regulator-fixed-supply: Name of the regulator supply
> +- regulator-fixed-microvolts: Output voltage of regulator
> +- regulator-fixed-gpio: gpio to use for enable control
> +- regulator-fixed-startup-delay: startup time in microseconds
> +- regulator-fixed-enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low
> +- regulator-fixed-enabled-at-boot: 1 = yes, 0 = no
> +
> +Example:
> +
> + abc: fixedregulator@0 {
> + compatible = "regulator-fixed";
> + regulator-fixed-supply = "fixed-supply";
> + regulator-fixed-microvolts = <1800000>;
> + regulator-fixed-gpio = <43>;
> + regulator-fixed-startup-delay = <70000>;
> + regulator-fixed-enable-high;
> + regulator-fixed-enabled-at-boot;
> + };
> diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
> index 2fe9d99..c09f791 100644
> --- a/drivers/regulator/fixed.c
> +++ b/drivers/regulator/fixed.c
> @@ -26,6 +26,8 @@
> #include <linux/gpio.h>
> #include <linux/delay.h>
> #include <linux/slab.h>
> +#include <linux/of.h>
> +#include <linux/regulator/of_regulator.h>
>
> struct fixed_voltage_data {
> struct regulator_desc desc;
> @@ -37,6 +39,40 @@ struct fixed_voltage_data {
> bool is_enabled;
> };
>
> +
> +/**
> + * of_get_fixed_voltage_config - extract fixed_voltage_config structure info
> + * @dev: device requesting for fixed_voltage_config
> + *
> + * Populates fixed_voltage_config structure by extracting data from device
> + * tree node, returns a pointer to the populated structure of NULL if memory
> + * alloc fails.
> + */
> +struct fixed_voltage_config *of_get_fixed_voltage_config(struct device *dev)
> +{
> + struct fixed_voltage_config *config;
> + struct device_node *np = dev->of_node;
> +
> + config = devm_kzalloc(dev, sizeof(struct fixed_voltage_config), GFP_KERNEL);
Nit: config = devm_kzalloc(dev, *config, GFP_KERNEL);
g.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 5/9] regulator: helper routine to extract fixed_voltage_config
@ 2011-09-30 1:26 ` Grant Likely
0 siblings, 0 replies; 114+ messages in thread
From: Grant Likely @ 2011-09-30 1:26 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 27, 2011 at 03:42:48PM +0530, Rajendra Nayak wrote:
> The helper routine of_get_fixed_voltage_config() extracts
> fixed_voltage_config structure contents from device tree.
>
> Also add documenation for additional bindings for fixed
> regulators that can be passed through dt.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> .../bindings/regulator/fixed-regulator.txt | 24 +++++++++++++
> drivers/regulator/fixed.c | 36 ++++++++++++++++++++
> include/linux/regulator/fixed.h | 6 ++--
> 3 files changed, 63 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/fixed-regulator.txt
>
> diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
> new file mode 100644
> index 0000000..a204cbd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
> @@ -0,0 +1,24 @@
> +Fixed Voltage regulators
> +
> +Required properties:
> +- compatible: Must be "regulator-fixed";
> +
> +Optional properties:
> +- regulator-fixed-supply: Name of the regulator supply
> +- regulator-fixed-microvolts: Output voltage of regulator
> +- regulator-fixed-gpio: gpio to use for enable control
> +- regulator-fixed-startup-delay: startup time in microseconds
> +- regulator-fixed-enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low
> +- regulator-fixed-enabled-at-boot: 1 = yes, 0 = no
> +
> +Example:
> +
> + abc: fixedregulator at 0 {
> + compatible = "regulator-fixed";
> + regulator-fixed-supply = "fixed-supply";
> + regulator-fixed-microvolts = <1800000>;
> + regulator-fixed-gpio = <43>;
> + regulator-fixed-startup-delay = <70000>;
> + regulator-fixed-enable-high;
> + regulator-fixed-enabled-at-boot;
> + };
> diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
> index 2fe9d99..c09f791 100644
> --- a/drivers/regulator/fixed.c
> +++ b/drivers/regulator/fixed.c
> @@ -26,6 +26,8 @@
> #include <linux/gpio.h>
> #include <linux/delay.h>
> #include <linux/slab.h>
> +#include <linux/of.h>
> +#include <linux/regulator/of_regulator.h>
>
> struct fixed_voltage_data {
> struct regulator_desc desc;
> @@ -37,6 +39,40 @@ struct fixed_voltage_data {
> bool is_enabled;
> };
>
> +
> +/**
> + * of_get_fixed_voltage_config - extract fixed_voltage_config structure info
> + * @dev: device requesting for fixed_voltage_config
> + *
> + * Populates fixed_voltage_config structure by extracting data from device
> + * tree node, returns a pointer to the populated structure of NULL if memory
> + * alloc fails.
> + */
> +struct fixed_voltage_config *of_get_fixed_voltage_config(struct device *dev)
> +{
> + struct fixed_voltage_config *config;
> + struct device_node *np = dev->of_node;
> +
> + config = devm_kzalloc(dev, sizeof(struct fixed_voltage_config), GFP_KERNEL);
Nit: config = devm_kzalloc(dev, *config, GFP_KERNEL);
g.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 6/9] regulator: make fixed regulator driver extract data from dt
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-30 1:34 ` Grant Likely
-1 siblings, 0 replies; 114+ messages in thread
From: Grant Likely @ 2011-09-30 1:34 UTC (permalink / raw)
To: Rajendra Nayak
Cc: broonie, devicetree-discuss, linux-omap, linux-arm-kernel, tony,
lrg, b-cousson, patches
On Tue, Sep 27, 2011 at 03:42:49PM +0530, Rajendra Nayak wrote:
> Modify the fixed regulator driver to extract fixed_voltage_config from
> device tree when passed, instead of getting it through platform_data
> structures (on non-DT builds)
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> drivers/regulator/fixed.c | 18 +++++++++++++++++-
> 1 files changed, 17 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
> index c09f791..0a9a10d 100644
> --- a/drivers/regulator/fixed.c
> +++ b/drivers/regulator/fixed.c
> @@ -140,10 +140,15 @@ static struct regulator_ops fixed_voltage_ops = {
>
> static int __devinit reg_fixed_voltage_probe(struct platform_device *pdev)
> {
> - struct fixed_voltage_config *config = pdev->dev.platform_data;
> + struct fixed_voltage_config *config;
This line doesn't actually need to change; just override it below if
the of_node is present.
> struct fixed_voltage_data *drvdata;
> int ret;
>
> + if (pdev->dev.of_node)
> + config = of_get_fixed_voltage_config(&pdev->dev);
> + else
> + config = pdev->dev.platform_data;
> +
> drvdata = kzalloc(sizeof(struct fixed_voltage_data), GFP_KERNEL);
> if (drvdata == NULL) {
> dev_err(&pdev->dev, "Failed to allocate device data\n");
> @@ -252,12 +257,23 @@ static int __devexit reg_fixed_voltage_remove(struct platform_device *pdev)
> return 0;
> }
>
> +#if defined(CONFIG_OF)
> +static const struct of_device_id fixed_of_match[] __devinitconst = {
> + { .compatible = "regulator-fixed", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, fixed_of_match);
> +#else
> +#define fixed_of_match NULL
> +#endif
> +
> static struct platform_driver regulator_fixed_voltage_driver = {
> .probe = reg_fixed_voltage_probe,
> .remove = __devexit_p(reg_fixed_voltage_remove),
> .driver = {
> .name = "reg-fixed-voltage",
> .owner = THIS_MODULE,
> + .of_match_table = fixed_of_match,
> },
> };
>
> --
> 1.7.1
>
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 6/9] regulator: make fixed regulator driver extract data from dt
@ 2011-09-30 1:34 ` Grant Likely
0 siblings, 0 replies; 114+ messages in thread
From: Grant Likely @ 2011-09-30 1:34 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 27, 2011 at 03:42:49PM +0530, Rajendra Nayak wrote:
> Modify the fixed regulator driver to extract fixed_voltage_config from
> device tree when passed, instead of getting it through platform_data
> structures (on non-DT builds)
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> drivers/regulator/fixed.c | 18 +++++++++++++++++-
> 1 files changed, 17 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
> index c09f791..0a9a10d 100644
> --- a/drivers/regulator/fixed.c
> +++ b/drivers/regulator/fixed.c
> @@ -140,10 +140,15 @@ static struct regulator_ops fixed_voltage_ops = {
>
> static int __devinit reg_fixed_voltage_probe(struct platform_device *pdev)
> {
> - struct fixed_voltage_config *config = pdev->dev.platform_data;
> + struct fixed_voltage_config *config;
This line doesn't actually need to change; just override it below if
the of_node is present.
> struct fixed_voltage_data *drvdata;
> int ret;
>
> + if (pdev->dev.of_node)
> + config = of_get_fixed_voltage_config(&pdev->dev);
> + else
> + config = pdev->dev.platform_data;
> +
> drvdata = kzalloc(sizeof(struct fixed_voltage_data), GFP_KERNEL);
> if (drvdata == NULL) {
> dev_err(&pdev->dev, "Failed to allocate device data\n");
> @@ -252,12 +257,23 @@ static int __devexit reg_fixed_voltage_remove(struct platform_device *pdev)
> return 0;
> }
>
> +#if defined(CONFIG_OF)
> +static const struct of_device_id fixed_of_match[] __devinitconst = {
> + { .compatible = "regulator-fixed", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, fixed_of_match);
> +#else
> +#define fixed_of_match NULL
> +#endif
> +
> static struct platform_driver regulator_fixed_voltage_driver = {
> .probe = reg_fixed_voltage_probe,
> .remove = __devexit_p(reg_fixed_voltage_remove),
> .driver = {
> .name = "reg-fixed-voltage",
> .owner = THIS_MODULE,
> + .of_match_table = fixed_of_match,
> },
> };
>
> --
> 1.7.1
>
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 8/9] regulator: helper to extract regulator node based on supply name
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-30 1:36 ` Grant Likely
-1 siblings, 0 replies; 114+ messages in thread
From: Grant Likely @ 2011-09-30 1:36 UTC (permalink / raw)
To: Rajendra Nayak
Cc: broonie, devicetree-discuss, linux-omap, linux-arm-kernel, tony,
lrg, b-cousson, patches
On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
> Device nodes in DT can associate themselves with one or more
> regulators by providing a list of phandles (to regulator nodes)
> and corresponding supply names.
>
> For Example:
> devicenode: node@0x0 {
> ...
> ...
> vmmc-supply = <®ulator1>;
> vpll-supply = <®ulator1>;
> };
>
> The driver would then do a regulator_get(dev, "vmmc"); to get
> regulator1 and do a regulator_get(dev, "vpll"); to get
> regulator2.
>
> of_get_regulator() extracts the regulator node for a given
> device, based on the supply name.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> drivers/regulator/of_regulator.c | 39 ++++++++++++++++++++++++++++++++
> include/linux/regulator/of_regulator.h | 7 +++++
> 2 files changed, 46 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
> index 7fa63ff..49dd105 100644
> --- a/drivers/regulator/of_regulator.c
> +++ b/drivers/regulator/of_regulator.c
> @@ -14,6 +14,45 @@
> #include <linux/of.h>
> #include <linux/regulator/machine.h>
>
> +
> +/**
> + * of_get_regulator - get a regulator device node based on supply name
> + * @dev: Device pointer for the consumer (of regulator) device
> + * @supply: regulator supply name
> + *
> + * Extract the regulator device node corresponding to the supply name.
> + * retruns the device node corresponding to the regulator if found, else
> + * returns NULL.
> + */
> +struct device_node *of_get_regulator(struct device *dev, const char *supply)
> +{
> + struct device_node *regnode = NULL;
> + u32 reghandle;
> + char prop_name[32]; /* 32 is max size of property name */
> + const void *prop;
> + int sz;
> +
> + if (!dev)
> + return NULL;
> +
> + dev_dbg(dev, "Looking up %s-supply from device tree\n", supply);
> +
> + snprintf(prop_name, 32, "%s-supply", supply);
> +
> + prop = of_get_property(dev->of_node, prop_name, &sz);
> + if (!prop || sz < 4)
> + return NULL;
> +
> + reghandle = be32_to_cpup(prop);
> + regnode = of_find_node_by_phandle(reghandle);
of_parse_phandle()
> + if (!regnode) {
> + pr_warn("%s: %s property in node %s references invalid phandle",
> + __func__, prop_name, dev->of_node->full_name);
> + return NULL;
> + }
> + return regnode;
> +}
> +
> static void of_get_regulation_constraints(struct device_node *np,
> struct regulator_init_data **init_data)
> {
> diff --git a/include/linux/regulator/of_regulator.h b/include/linux/regulator/of_regulator.h
> index 3f63be9..edaba1a 100644
> --- a/include/linux/regulator/of_regulator.h
> +++ b/include/linux/regulator/of_regulator.h
> @@ -9,12 +9,19 @@
> #if defined(CONFIG_OF_REGULATOR)
> extern struct regulator_init_data
> *of_get_regulator_init_data(struct device *dev);
> +extern struct device_node *of_get_regulator(struct device *dev,
> + const char *supply);
> #else
> static inline struct regulator_init_data
> *of_get_regulator_init_data(struct device_node *np)
> {
> return NULL;
> }
> +static inline struct device_node *of_get_regulator(struct device *dev,
> + const char *id)
> +{
> + return NULL;
> +}
> #endif /* CONFIG_OF_REGULATOR */
>
> #endif /* __LINUX_OF_REG_H */
> --
> 1.7.1
>
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 8/9] regulator: helper to extract regulator node based on supply name
@ 2011-09-30 1:36 ` Grant Likely
0 siblings, 0 replies; 114+ messages in thread
From: Grant Likely @ 2011-09-30 1:36 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
> Device nodes in DT can associate themselves with one or more
> regulators by providing a list of phandles (to regulator nodes)
> and corresponding supply names.
>
> For Example:
> devicenode: node at 0x0 {
> ...
> ...
> vmmc-supply = <®ulator1>;
> vpll-supply = <®ulator1>;
> };
>
> The driver would then do a regulator_get(dev, "vmmc"); to get
> regulator1 and do a regulator_get(dev, "vpll"); to get
> regulator2.
>
> of_get_regulator() extracts the regulator node for a given
> device, based on the supply name.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> drivers/regulator/of_regulator.c | 39 ++++++++++++++++++++++++++++++++
> include/linux/regulator/of_regulator.h | 7 +++++
> 2 files changed, 46 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
> index 7fa63ff..49dd105 100644
> --- a/drivers/regulator/of_regulator.c
> +++ b/drivers/regulator/of_regulator.c
> @@ -14,6 +14,45 @@
> #include <linux/of.h>
> #include <linux/regulator/machine.h>
>
> +
> +/**
> + * of_get_regulator - get a regulator device node based on supply name
> + * @dev: Device pointer for the consumer (of regulator) device
> + * @supply: regulator supply name
> + *
> + * Extract the regulator device node corresponding to the supply name.
> + * retruns the device node corresponding to the regulator if found, else
> + * returns NULL.
> + */
> +struct device_node *of_get_regulator(struct device *dev, const char *supply)
> +{
> + struct device_node *regnode = NULL;
> + u32 reghandle;
> + char prop_name[32]; /* 32 is max size of property name */
> + const void *prop;
> + int sz;
> +
> + if (!dev)
> + return NULL;
> +
> + dev_dbg(dev, "Looking up %s-supply from device tree\n", supply);
> +
> + snprintf(prop_name, 32, "%s-supply", supply);
> +
> + prop = of_get_property(dev->of_node, prop_name, &sz);
> + if (!prop || sz < 4)
> + return NULL;
> +
> + reghandle = be32_to_cpup(prop);
> + regnode = of_find_node_by_phandle(reghandle);
of_parse_phandle()
> + if (!regnode) {
> + pr_warn("%s: %s property in node %s references invalid phandle",
> + __func__, prop_name, dev->of_node->full_name);
> + return NULL;
> + }
> + return regnode;
> +}
> +
> static void of_get_regulation_constraints(struct device_node *np,
> struct regulator_init_data **init_data)
> {
> diff --git a/include/linux/regulator/of_regulator.h b/include/linux/regulator/of_regulator.h
> index 3f63be9..edaba1a 100644
> --- a/include/linux/regulator/of_regulator.h
> +++ b/include/linux/regulator/of_regulator.h
> @@ -9,12 +9,19 @@
> #if defined(CONFIG_OF_REGULATOR)
> extern struct regulator_init_data
> *of_get_regulator_init_data(struct device *dev);
> +extern struct device_node *of_get_regulator(struct device *dev,
> + const char *supply);
> #else
> static inline struct regulator_init_data
> *of_get_regulator_init_data(struct device_node *np)
> {
> return NULL;
> }
> +static inline struct device_node *of_get_regulator(struct device *dev,
> + const char *id)
> +{
> + return NULL;
> +}
> #endif /* CONFIG_OF_REGULATOR */
>
> #endif /* __LINUX_OF_REG_H */
> --
> 1.7.1
>
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 9/9] regulator: map consumer regulator based on device tree
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-30 1:38 ` Grant Likely
-1 siblings, 0 replies; 114+ messages in thread
From: Grant Likely @ 2011-09-30 1:38 UTC (permalink / raw)
To: Rajendra Nayak
Cc: patches-QSEj5FYQhm4dnm+yROfE0A, tony-4v6yS6AI5VpBDgjK7y7TUQ,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
linux-omap-u79uwXL29TY76Z2rM5mHXA, lrg-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Tue, Sep 27, 2011 at 03:42:52PM +0530, Rajendra Nayak wrote:
> Look up the regulator for a given consumer from device tree, during
> a regulator_get(). If not found fallback and lookup through
> the regulator_map_list instead.
>
> Devices can associate with one or more regulators by providing a
> list of phandles and supply names.
>
> For Example:
> devicenode: node@0x0 {
> ...
> ...
> vmmc-supply = <®ulator1>;
> vpll-supply = <®ulator2>;
> };
>
> When a device driver calls a regulator_get, specifying the
> supply name, the phandle and eventually the regulator node
> is extracted from the device node.
>
> Signed-off-by: Rajendra Nayak <rnayak-l0cyMroinI0@public.gmane.org>
> ---
> drivers/regulator/core.c | 14 ++++++++++++++
> include/linux/regulator/driver.h | 3 +++
> 2 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index d8e6a42..47b851c 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -25,9 +25,11 @@
> #include <linux/mutex.h>
> #include <linux/suspend.h>
> #include <linux/delay.h>
> +#include <linux/of.h>
> #include <linux/regulator/consumer.h>
> #include <linux/regulator/driver.h>
> #include <linux/regulator/machine.h>
> +#include <linux/regulator/of_regulator.h>
>
> #define CREATE_TRACE_POINTS
> #include <trace/events/regulator.h>
> @@ -1155,6 +1157,7 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
> struct regulator_map *map;
> struct regulator *regulator = ERR_PTR(-ENODEV);
> const char *devname = NULL;
> + struct device_node *node;
> int ret;
>
> if (id == NULL) {
> @@ -1167,6 +1170,15 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
>
> mutex_lock(®ulator_list_mutex);
>
> + if (dev->of_node) {
> + node = of_get_regulator(dev, id);
> + if (!node)
> + goto retry; /* fallback and chk regulator_map_list */
> + list_for_each_entry(rdev, ®ulator_list, list)
> + if (node == rdev->node)
> + goto found;
> + }
> +retry:
> list_for_each_entry(map, ®ulator_map_list, list) {
> /* If the mapping has a device set up it must match */
> if (map->dev_name &&
> @@ -2619,6 +2631,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> rdev->reg_data = driver_data;
> rdev->owner = regulator_desc->owner;
> rdev->desc = regulator_desc;
> + if (dev && dev->of_node)
> + rdev->node = dev->of_node;
> INIT_LIST_HEAD(&rdev->consumer_list);
> INIT_LIST_HEAD(&rdev->list);
> BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
> index 1a80bc7..4aebbf5 100644
> --- a/include/linux/regulator/driver.h
> +++ b/include/linux/regulator/driver.h
> @@ -196,6 +196,9 @@ struct regulator_dev {
> struct mutex mutex; /* consumer lock */
> struct module *owner;
> struct device dev;
> +#ifdef CONFIG_OF
> + struct device_node *node;
> +#endif
There is already an of_node pointer in regulator_dev->dev.of_node.
Why does another need to be added here?
g.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 9/9] regulator: map consumer regulator based on device tree
@ 2011-09-30 1:38 ` Grant Likely
0 siblings, 0 replies; 114+ messages in thread
From: Grant Likely @ 2011-09-30 1:38 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 27, 2011 at 03:42:52PM +0530, Rajendra Nayak wrote:
> Look up the regulator for a given consumer from device tree, during
> a regulator_get(). If not found fallback and lookup through
> the regulator_map_list instead.
>
> Devices can associate with one or more regulators by providing a
> list of phandles and supply names.
>
> For Example:
> devicenode: node at 0x0 {
> ...
> ...
> vmmc-supply = <®ulator1>;
> vpll-supply = <®ulator2>;
> };
>
> When a device driver calls a regulator_get, specifying the
> supply name, the phandle and eventually the regulator node
> is extracted from the device node.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> drivers/regulator/core.c | 14 ++++++++++++++
> include/linux/regulator/driver.h | 3 +++
> 2 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index d8e6a42..47b851c 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -25,9 +25,11 @@
> #include <linux/mutex.h>
> #include <linux/suspend.h>
> #include <linux/delay.h>
> +#include <linux/of.h>
> #include <linux/regulator/consumer.h>
> #include <linux/regulator/driver.h>
> #include <linux/regulator/machine.h>
> +#include <linux/regulator/of_regulator.h>
>
> #define CREATE_TRACE_POINTS
> #include <trace/events/regulator.h>
> @@ -1155,6 +1157,7 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
> struct regulator_map *map;
> struct regulator *regulator = ERR_PTR(-ENODEV);
> const char *devname = NULL;
> + struct device_node *node;
> int ret;
>
> if (id == NULL) {
> @@ -1167,6 +1170,15 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
>
> mutex_lock(®ulator_list_mutex);
>
> + if (dev->of_node) {
> + node = of_get_regulator(dev, id);
> + if (!node)
> + goto retry; /* fallback and chk regulator_map_list */
> + list_for_each_entry(rdev, ®ulator_list, list)
> + if (node == rdev->node)
> + goto found;
> + }
> +retry:
> list_for_each_entry(map, ®ulator_map_list, list) {
> /* If the mapping has a device set up it must match */
> if (map->dev_name &&
> @@ -2619,6 +2631,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> rdev->reg_data = driver_data;
> rdev->owner = regulator_desc->owner;
> rdev->desc = regulator_desc;
> + if (dev && dev->of_node)
> + rdev->node = dev->of_node;
> INIT_LIST_HEAD(&rdev->consumer_list);
> INIT_LIST_HEAD(&rdev->list);
> BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
> index 1a80bc7..4aebbf5 100644
> --- a/include/linux/regulator/driver.h
> +++ b/include/linux/regulator/driver.h
> @@ -196,6 +196,9 @@ struct regulator_dev {
> struct mutex mutex; /* consumer lock */
> struct module *owner;
> struct device dev;
> +#ifdef CONFIG_OF
> + struct device_node *node;
> +#endif
There is already an of_node pointer in regulator_dev->dev.of_node.
Why does another need to be added here?
g.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 0/9] Device tree support for regulators
2011-09-27 10:12 ` Rajendra Nayak
@ 2011-09-30 1:39 ` Grant Likely
-1 siblings, 0 replies; 114+ messages in thread
From: Grant Likely @ 2011-09-30 1:39 UTC (permalink / raw)
To: Rajendra Nayak
Cc: broonie, devicetree-discuss, linux-omap, linux-arm-kernel, tony,
lrg, b-cousson, patches
On Tue, Sep 27, 2011 at 03:42:43PM +0530, Rajendra Nayak wrote:
> Hi Mark, Grant,
>
> This is a respin of my RFC series I posted sometime back
> and is now based on top of the latest omap i2c-twl support
> series posted by Benoit
> git://gitorious.org/omap-pm/linux.git for_3.2/4_omap_dt_i2c_twl
>
> some changes done since the RFC:
> 1. twl driver fixed to remove hardcoded board params
> 2. regulator helpers moved from drivers/of to drivers/regulator
> 3. Better compatible definitions for specific device type
> 4. twl regulator driver doing internal table lookup based on
> compatible rather then pdev->id
> 5. Seperate fixed voltage regulator bindings defined
> 6. Changed the way devices associate with regulators
> i.e using <name>-supply = <®ulator-phandle>;
Overall looks fairly good other than the comments made by Mark and myself.
g.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 0/9] Device tree support for regulators
@ 2011-09-30 1:39 ` Grant Likely
0 siblings, 0 replies; 114+ messages in thread
From: Grant Likely @ 2011-09-30 1:39 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 27, 2011 at 03:42:43PM +0530, Rajendra Nayak wrote:
> Hi Mark, Grant,
>
> This is a respin of my RFC series I posted sometime back
> and is now based on top of the latest omap i2c-twl support
> series posted by Benoit
> git://gitorious.org/omap-pm/linux.git for_3.2/4_omap_dt_i2c_twl
>
> some changes done since the RFC:
> 1. twl driver fixed to remove hardcoded board params
> 2. regulator helpers moved from drivers/of to drivers/regulator
> 3. Better compatible definitions for specific device type
> 4. twl regulator driver doing internal table lookup based on
> compatible rather then pdev->id
> 5. Seperate fixed voltage regulator bindings defined
> 6. Changed the way devices associate with regulators
> i.e using <name>-supply = <®ulator-phandle>;
Overall looks fairly good other than the comments made by Mark and myself.
g.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-09-27 15:05 ` Mark Brown
@ 2011-09-30 4:27 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-30 4:27 UTC (permalink / raw)
To: Mark Brown
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
[]...
>
>>>> + init_data->supply_regulator = (char *)of_get_property(dev->of_node,
>>>> + "regulator-supplies", NULL);
>
>>> I'd expect that in the device tree world the supply regulator would
>>> reference the node for that regulator.
>
>> You mean using phandles? Thats what Grant proposed too but
>> I thought you instead had an inclination towards names? Or maybe
>> I misunderstood.
>
> They need both. We need to reference the device that provides the
> supply and use a name to say which of the potentially multiple supplies
> on the consumer device is which.
Mark, I still seem to be a little confused with this one as to why
we would need a phandle *and* a supply-name to reference a parent
regulator/supply.
The phandle would point to a regulator dt node and that node internally
would have just one name associated with it.
>
>>> Hrm, I think loosing the signs here is bad karma - negative voltages do
>>> exist after all.
>
>> Oops.. they do? didn't know about that.
>
> Yup, ground is just a reference point.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-09-30 4:27 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-30 4:27 UTC (permalink / raw)
To: linux-arm-kernel
[]...
>
>>>> + init_data->supply_regulator = (char *)of_get_property(dev->of_node,
>>>> + "regulator-supplies", NULL);
>
>>> I'd expect that in the device tree world the supply regulator would
>>> reference the node for that regulator.
>
>> You mean using phandles? Thats what Grant proposed too but
>> I thought you instead had an inclination towards names? Or maybe
>> I misunderstood.
>
> They need both. We need to reference the device that provides the
> supply and use a name to say which of the potentially multiple supplies
> on the consumer device is which.
Mark, I still seem to be a little confused with this one as to why
we would need a phandle *and* a supply-name to reference a parent
regulator/supply.
The phandle would point to a regulator dt node and that node internally
would have just one name associated with it.
>
>>> Hrm, I think loosing the signs here is bad karma - negative voltages do
>>> exist after all.
>
>> Oops.. they do? didn't know about that.
>
> Yup, ground is just a reference point.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-09-30 4:27 ` Rajendra Nayak
@ 2011-09-30 7:58 ` Cousson, Benoit
-1 siblings, 0 replies; 114+ messages in thread
From: Cousson, Benoit @ 2011-09-30 7:58 UTC (permalink / raw)
To: Nayak, Rajendra, Mark Brown
Cc: patches, tony, devicetree-discuss, grant.likely, linux-omap,
Girdwood, Liam, linux-arm-kernel
On 9/30/2011 6:27 AM, Nayak, Rajendra wrote:
[...]
>> They need both. We need to reference the device that provides the
>> supply and use a name to say which of the potentially multiple supplies
>> on the consumer device is which.
>
> Mark, I still seem to be a little confused with this one as to why
> we would need a phandle *and* a supply-name to reference a parent
> regulator/supply.
> The phandle would point to a regulator dt node and that node internally
> would have just one name associated with it.
I think as well that we should avoid considering a regulator with
several outputs. I saw the same pattern used for the clock binding in DT
as well.
A clock node like a regulator node should output only one signal.
These nodes should provide atomic functionality. And if extra
functionality are needed we might consider adding some intermediate nodes.
Except for a regulator that will output several lines at the same
voltage to spread the current load, assuming it does exist, I'm not sure
to understand the need.
Mark,
What usage do you have in mind for such supply node with several outputs?
Regards,
Benoit
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-09-30 7:58 ` Cousson, Benoit
0 siblings, 0 replies; 114+ messages in thread
From: Cousson, Benoit @ 2011-09-30 7:58 UTC (permalink / raw)
To: linux-arm-kernel
On 9/30/2011 6:27 AM, Nayak, Rajendra wrote:
[...]
>> They need both. We need to reference the device that provides the
>> supply and use a name to say which of the potentially multiple supplies
>> on the consumer device is which.
>
> Mark, I still seem to be a little confused with this one as to why
> we would need a phandle *and* a supply-name to reference a parent
> regulator/supply.
> The phandle would point to a regulator dt node and that node internally
> would have just one name associated with it.
I think as well that we should avoid considering a regulator with
several outputs. I saw the same pattern used for the clock binding in DT
as well.
A clock node like a regulator node should output only one signal.
These nodes should provide atomic functionality. And if extra
functionality are needed we might consider adding some intermediate nodes.
Except for a regulator that will output several lines at the same
voltage to spread the current load, assuming it does exist, I'm not sure
to understand the need.
Mark,
What usage do you have in mind for such supply node with several outputs?
Regards,
Benoit
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 9/9] regulator: map consumer regulator based on device tree
2011-09-30 1:38 ` Grant Likely
@ 2011-09-30 9:29 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-30 9:29 UTC (permalink / raw)
To: Grant Likely
Cc: broonie, devicetree-discuss, linux-omap, linux-arm-kernel, tony,
lrg, b-cousson, patches
On Friday 30 September 2011 07:08 AM, Grant Likely wrote:
> On Tue, Sep 27, 2011 at 03:42:52PM +0530, Rajendra Nayak wrote:
>> Look up the regulator for a given consumer from device tree, during
>> a regulator_get(). If not found fallback and lookup through
>> the regulator_map_list instead.
>>
>> Devices can associate with one or more regulators by providing a
>> list of phandles and supply names.
>>
>> For Example:
>> devicenode: node@0x0 {
>> ...
>> ...
>> vmmc-supply =<®ulator1>;
>> vpll-supply =<®ulator2>;
>> };
>>
>> When a device driver calls a regulator_get, specifying the
>> supply name, the phandle and eventually the regulator node
>> is extracted from the device node.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> ---
>> drivers/regulator/core.c | 14 ++++++++++++++
>> include/linux/regulator/driver.h | 3 +++
>> 2 files changed, 17 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
>> index d8e6a42..47b851c 100644
>> --- a/drivers/regulator/core.c
>> +++ b/drivers/regulator/core.c
>> @@ -25,9 +25,11 @@
>> #include<linux/mutex.h>
>> #include<linux/suspend.h>
>> #include<linux/delay.h>
>> +#include<linux/of.h>
>> #include<linux/regulator/consumer.h>
>> #include<linux/regulator/driver.h>
>> #include<linux/regulator/machine.h>
>> +#include<linux/regulator/of_regulator.h>
>>
>> #define CREATE_TRACE_POINTS
>> #include<trace/events/regulator.h>
>> @@ -1155,6 +1157,7 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
>> struct regulator_map *map;
>> struct regulator *regulator = ERR_PTR(-ENODEV);
>> const char *devname = NULL;
>> + struct device_node *node;
>> int ret;
>>
>> if (id == NULL) {
>> @@ -1167,6 +1170,15 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
>>
>> mutex_lock(®ulator_list_mutex);
>>
>> + if (dev->of_node) {
>> + node = of_get_regulator(dev, id);
>> + if (!node)
>> + goto retry; /* fallback and chk regulator_map_list */
>> + list_for_each_entry(rdev,®ulator_list, list)
>> + if (node == rdev->node)
>> + goto found;
>> + }
>> +retry:
>> list_for_each_entry(map,®ulator_map_list, list) {
>> /* If the mapping has a device set up it must match */
>> if (map->dev_name&&
>> @@ -2619,6 +2631,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
>> rdev->reg_data = driver_data;
>> rdev->owner = regulator_desc->owner;
>> rdev->desc = regulator_desc;
>> + if (dev&& dev->of_node)
>> + rdev->node = dev->of_node;
>> INIT_LIST_HEAD(&rdev->consumer_list);
>> INIT_LIST_HEAD(&rdev->list);
>> BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
>> diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
>> index 1a80bc7..4aebbf5 100644
>> --- a/include/linux/regulator/driver.h
>> +++ b/include/linux/regulator/driver.h
>> @@ -196,6 +196,9 @@ struct regulator_dev {
>> struct mutex mutex; /* consumer lock */
>> struct module *owner;
>> struct device dev;
>> +#ifdef CONFIG_OF
>> + struct device_node *node;
>> +#endif
>
> There is already an of_node pointer in regulator_dev->dev.of_node.
> Why does another need to be added here?
Yes, I guess it doesn't. Will remove it.
Thanks.
>
> g.
>
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 9/9] regulator: map consumer regulator based on device tree
@ 2011-09-30 9:29 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-30 9:29 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 30 September 2011 07:08 AM, Grant Likely wrote:
> On Tue, Sep 27, 2011 at 03:42:52PM +0530, Rajendra Nayak wrote:
>> Look up the regulator for a given consumer from device tree, during
>> a regulator_get(). If not found fallback and lookup through
>> the regulator_map_list instead.
>>
>> Devices can associate with one or more regulators by providing a
>> list of phandles and supply names.
>>
>> For Example:
>> devicenode: node at 0x0 {
>> ...
>> ...
>> vmmc-supply =<®ulator1>;
>> vpll-supply =<®ulator2>;
>> };
>>
>> When a device driver calls a regulator_get, specifying the
>> supply name, the phandle and eventually the regulator node
>> is extracted from the device node.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> ---
>> drivers/regulator/core.c | 14 ++++++++++++++
>> include/linux/regulator/driver.h | 3 +++
>> 2 files changed, 17 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
>> index d8e6a42..47b851c 100644
>> --- a/drivers/regulator/core.c
>> +++ b/drivers/regulator/core.c
>> @@ -25,9 +25,11 @@
>> #include<linux/mutex.h>
>> #include<linux/suspend.h>
>> #include<linux/delay.h>
>> +#include<linux/of.h>
>> #include<linux/regulator/consumer.h>
>> #include<linux/regulator/driver.h>
>> #include<linux/regulator/machine.h>
>> +#include<linux/regulator/of_regulator.h>
>>
>> #define CREATE_TRACE_POINTS
>> #include<trace/events/regulator.h>
>> @@ -1155,6 +1157,7 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
>> struct regulator_map *map;
>> struct regulator *regulator = ERR_PTR(-ENODEV);
>> const char *devname = NULL;
>> + struct device_node *node;
>> int ret;
>>
>> if (id == NULL) {
>> @@ -1167,6 +1170,15 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
>>
>> mutex_lock(®ulator_list_mutex);
>>
>> + if (dev->of_node) {
>> + node = of_get_regulator(dev, id);
>> + if (!node)
>> + goto retry; /* fallback and chk regulator_map_list */
>> + list_for_each_entry(rdev,®ulator_list, list)
>> + if (node == rdev->node)
>> + goto found;
>> + }
>> +retry:
>> list_for_each_entry(map,®ulator_map_list, list) {
>> /* If the mapping has a device set up it must match */
>> if (map->dev_name&&
>> @@ -2619,6 +2631,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
>> rdev->reg_data = driver_data;
>> rdev->owner = regulator_desc->owner;
>> rdev->desc = regulator_desc;
>> + if (dev&& dev->of_node)
>> + rdev->node = dev->of_node;
>> INIT_LIST_HEAD(&rdev->consumer_list);
>> INIT_LIST_HEAD(&rdev->list);
>> BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
>> diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
>> index 1a80bc7..4aebbf5 100644
>> --- a/include/linux/regulator/driver.h
>> +++ b/include/linux/regulator/driver.h
>> @@ -196,6 +196,9 @@ struct regulator_dev {
>> struct mutex mutex; /* consumer lock */
>> struct module *owner;
>> struct device dev;
>> +#ifdef CONFIG_OF
>> + struct device_node *node;
>> +#endif
>
> There is already an of_node pointer in regulator_dev->dev.of_node.
> Why does another need to be added here?
Yes, I guess it doesn't. Will remove it.
Thanks.
>
> g.
>
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 8/9] regulator: helper to extract regulator node based on supply name
2011-09-28 12:26 ` Mark Brown
@ 2011-09-30 9:34 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-30 9:34 UTC (permalink / raw)
To: Mark Brown
Cc: Cousson, Benoit, grant.likely, devicetree-discuss, linux-omap,
linux-arm-kernel, tony, Girdwood, Liam, patches
On Wednesday 28 September 2011 05:56 PM, Mark Brown wrote:
> On Wed, Sep 28, 2011 at 10:09:30AM +0200, Cousson, Benoit wrote:
>> On 9/27/2011 8:59 PM, Mark Brown wrote:
>
>>> I'm not sure how this should work in a device tree world, I'd *hope*
>>> we'd get a device tree node for the CPU and could then just make this a
>>> regular consumer thing but then the cpufreq drivers would need to be
>>> updated to make use of it. The only reason we allow null devices right
>>> now is the fact that cpufreq doesn't have a struct device it can use.
>
>> That's why we do have a MPU node in OMAP dts, in order to build an
>> omap_device that will be mainly used for the DVFS on the MPU.
>
>> And even before DT migration, we used to build statically some
>> omap_device to represent the various processors in the system (MPU,
>> DSP, CortexM3...).
>
> Yeah, but that's very OMAP specific - we don't have that in general (in
> fact it's the only Linux platform I'm aware of that has a device for the
> CPU).
But isn't this the right thing to do for everyone else too?
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 8/9] regulator: helper to extract regulator node based on supply name
@ 2011-09-30 9:34 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-30 9:34 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 28 September 2011 05:56 PM, Mark Brown wrote:
> On Wed, Sep 28, 2011 at 10:09:30AM +0200, Cousson, Benoit wrote:
>> On 9/27/2011 8:59 PM, Mark Brown wrote:
>
>>> I'm not sure how this should work in a device tree world, I'd *hope*
>>> we'd get a device tree node for the CPU and could then just make this a
>>> regular consumer thing but then the cpufreq drivers would need to be
>>> updated to make use of it. The only reason we allow null devices right
>>> now is the fact that cpufreq doesn't have a struct device it can use.
>
>> That's why we do have a MPU node in OMAP dts, in order to build an
>> omap_device that will be mainly used for the DVFS on the MPU.
>
>> And even before DT migration, we used to build statically some
>> omap_device to represent the various processors in the system (MPU,
>> DSP, CortexM3...).
>
> Yeah, but that's very OMAP specific - we don't have that in general (in
> fact it's the only Linux platform I'm aware of that has a device for the
> CPU).
But isn't this the right thing to do for everyone else too?
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-09-30 4:27 ` Rajendra Nayak
@ 2011-09-30 10:28 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-30 10:28 UTC (permalink / raw)
To: Rajendra Nayak
Cc: grant.likely, devicetree-discuss, linux-omap, linux-arm-kernel,
tony, lrg, b-cousson, patches
On Fri, Sep 30, 2011 at 09:57:30AM +0530, Rajendra Nayak wrote:
> Mark, I still seem to be a little confused with this one as to why
> we would need a phandle *and* a supply-name to reference a parent
> regulator/supply.
> The phandle would point to a regulator dt node and that node internally
> would have just one name associated with it.
To repeat: the supply name is for the consumer. It is needed so that
the consumer can tell which supply is provided by which regulator.
Almost all devices have more than one supply and if the device does
anything more complicated than just turning on all the supplies when the
device is active it's going to need to figure out which supply is which.
Also, please do remember to keep linux-kernel in the loop on all
regulator API discussion - you should always keep the relevant mailing
lists in the loop for any subsystem you're changing.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-09-30 10:28 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-30 10:28 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 30, 2011 at 09:57:30AM +0530, Rajendra Nayak wrote:
> Mark, I still seem to be a little confused with this one as to why
> we would need a phandle *and* a supply-name to reference a parent
> regulator/supply.
> The phandle would point to a regulator dt node and that node internally
> would have just one name associated with it.
To repeat: the supply name is for the consumer. It is needed so that
the consumer can tell which supply is provided by which regulator.
Almost all devices have more than one supply and if the device does
anything more complicated than just turning on all the supplies when the
device is active it's going to need to figure out which supply is which.
Also, please do remember to keep linux-kernel in the loop on all
regulator API discussion - you should always keep the relevant mailing
lists in the loop for any subsystem you're changing.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 8/9] regulator: helper to extract regulator node based on supply name
2011-09-30 9:34 ` Rajendra Nayak
@ 2011-09-30 10:35 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-30 10:35 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Cousson, Benoit, grant.likely, devicetree-discuss, linux-omap,
linux-arm-kernel, tony, Girdwood, Liam, patches
On Fri, Sep 30, 2011 at 03:04:45PM +0530, Rajendra Nayak wrote:
> On Wednesday 28 September 2011 05:56 PM, Mark Brown wrote:
> >On Wed, Sep 28, 2011 at 10:09:30AM +0200, Cousson, Benoit wrote:
> >>And even before DT migration, we used to build statically some
> >>omap_device to represent the various processors in the system (MPU,
> >>DSP, CortexM3...).
> >Yeah, but that's very OMAP specific - we don't have that in general (in
> >fact it's the only Linux platform I'm aware of that has a device for the
> >CPU).
> But isn't this the right thing to do for everyone else too?
That doesn't really matter so long as nobody else is actually doing it;
you can't make a decision like this in an OMAP-specific fashion, you
need to make sure everyone else is on board with the decision and make
sure we've got at least at a high level way of representing the CPUs and
SoCs in the device tree that people can buy into.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 8/9] regulator: helper to extract regulator node based on supply name
@ 2011-09-30 10:35 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-30 10:35 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 30, 2011 at 03:04:45PM +0530, Rajendra Nayak wrote:
> On Wednesday 28 September 2011 05:56 PM, Mark Brown wrote:
> >On Wed, Sep 28, 2011 at 10:09:30AM +0200, Cousson, Benoit wrote:
> >>And even before DT migration, we used to build statically some
> >>omap_device to represent the various processors in the system (MPU,
> >>DSP, CortexM3...).
> >Yeah, but that's very OMAP specific - we don't have that in general (in
> >fact it's the only Linux platform I'm aware of that has a device for the
> >CPU).
> But isn't this the right thing to do for everyone else too?
That doesn't really matter so long as nobody else is actually doing it;
you can't make a decision like this in an OMAP-specific fashion, you
need to make sure everyone else is on board with the decision and make
sure we've got at least at a high level way of representing the CPUs and
SoCs in the device tree that people can buy into.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-09-30 10:28 ` Mark Brown
@ 2011-09-30 10:48 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-30 10:48 UTC (permalink / raw)
To: Rajendra Nayak
Cc: b-cousson, patches, tony, devicetree-discuss, grant.likely,
linux-omap, lrg, linux-arm-kernel
On Fri, Sep 30, 2011 at 11:28:49AM +0100, Mark Brown wrote:
> On Fri, Sep 30, 2011 at 09:57:30AM +0530, Rajendra Nayak wrote:
>>>> + init_data->supply_regulator = (char *)of_get_property(dev->of_node,
>>>> + "regulator-supplies", NULL);
> > Mark, I still seem to be a little confused with this one as to why
> > we would need a phandle *and* a supply-name to reference a parent
> > regulator/supply.
> > The phandle would point to a regulator dt node and that node internally
> > would have just one name associated with it.
> To repeat: the supply name is for the consumer. It is needed so that
> the consumer can tell which supply is provided by which regulator.
> Almost all devices have more than one supply and if the device does
> anything more complicated than just turning on all the supplies when the
> device is active it's going to need to figure out which supply is which.
Hang on, I now have no idea what this is supposed to be doing. Later on
in the series you had examples in your commit logs with perfectly
sensible bindings for supplies:
vmmc-supply = <®ulator1>;
vpll-supply = <®ulator1>;
which have both a unique name and a direct reference to the supplying
regulator. What are these "regulator-supplies" properties supposed to
be?
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-09-30 10:48 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-30 10:48 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 30, 2011 at 11:28:49AM +0100, Mark Brown wrote:
> On Fri, Sep 30, 2011 at 09:57:30AM +0530, Rajendra Nayak wrote:
>>>> + init_data->supply_regulator = (char *)of_get_property(dev->of_node,
>>>> + "regulator-supplies", NULL);
> > Mark, I still seem to be a little confused with this one as to why
> > we would need a phandle *and* a supply-name to reference a parent
> > regulator/supply.
> > The phandle would point to a regulator dt node and that node internally
> > would have just one name associated with it.
> To repeat: the supply name is for the consumer. It is needed so that
> the consumer can tell which supply is provided by which regulator.
> Almost all devices have more than one supply and if the device does
> anything more complicated than just turning on all the supplies when the
> device is active it's going to need to figure out which supply is which.
Hang on, I now have no idea what this is supposed to be doing. Later on
in the series you had examples in your commit logs with perfectly
sensible bindings for supplies:
vmmc-supply = <®ulator1>;
vpll-supply = <®ulator1>;
which have both a unique name and a direct reference to the supplying
regulator. What are these "regulator-supplies" properties supposed to
be?
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-09-30 7:58 ` Cousson, Benoit
@ 2011-09-30 10:49 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-30 10:49 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Nayak, Rajendra, patches, tony, devicetree-discuss, grant.likely,
linux-omap, Girdwood, Liam, linux-arm-kernel
On Fri, Sep 30, 2011 at 09:58:04AM +0200, Cousson, Benoit wrote:
> I think as well that we should avoid considering a regulator with
> several outputs. I saw the same pattern used for the clock binding
> in DT as well.
This binding is for the consumer side, not the producer side. A binding
which restricted us to a single consumer per regulator would obviously
not work for real systems.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-09-30 10:49 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-30 10:49 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 30, 2011 at 09:58:04AM +0200, Cousson, Benoit wrote:
> I think as well that we should avoid considering a regulator with
> several outputs. I saw the same pattern used for the clock binding
> in DT as well.
This binding is for the consumer side, not the producer side. A binding
which restricted us to a single consumer per regulator would obviously
not work for real systems.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-09-30 10:48 ` Mark Brown
@ 2011-09-30 11:09 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-30 11:09 UTC (permalink / raw)
To: Mark Brown
Cc: b-cousson, patches, tony, devicetree-discuss, grant.likely,
linux-omap, lrg, linux-arm-kernel
On Friday 30 September 2011 04:18 PM, Mark Brown wrote:
> On Fri, Sep 30, 2011 at 11:28:49AM +0100, Mark Brown wrote:
>> On Fri, Sep 30, 2011 at 09:57:30AM +0530, Rajendra Nayak wrote:
>
>>>>> + init_data->supply_regulator = (char *)of_get_property(dev->of_node,
>>>>> + "regulator-supplies", NULL);
>
>>> Mark, I still seem to be a little confused with this one as to why
>>> we would need a phandle *and* a supply-name to reference a parent
>>> regulator/supply.
>>> The phandle would point to a regulator dt node and that node internally
>>> would have just one name associated with it.
>
>> To repeat: the supply name is for the consumer. It is needed so that
>> the consumer can tell which supply is provided by which regulator.
>> Almost all devices have more than one supply and if the device does
>> anything more complicated than just turning on all the supplies when the
>> device is active it's going to need to figure out which supply is which.
>
> Hang on, I now have no idea what this is supposed to be doing. Later on
> in the series you had examples in your commit logs with perfectly
> sensible bindings for supplies:
>
> vmmc-supply =<®ulator1>;
> vpll-supply =<®ulator1>;
>
> which have both a unique name and a direct reference to the supplying
> regulator. What are these "regulator-supplies" properties supposed to
> be?
:-), yes, I was confused for a while as well after reading your response.
The "regulator-supplies" is used to specific the regulator *parent*.
Same as what was earlier passed by using the
"supply_regulator" field of regulator_init_data structure.
Grant wanted the bindings to support specifying multiple parents
and hence I was thinking of either a list of names *or*
a list of phandles to specify multiple parents to a regulator.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-09-30 11:09 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-09-30 11:09 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 30 September 2011 04:18 PM, Mark Brown wrote:
> On Fri, Sep 30, 2011 at 11:28:49AM +0100, Mark Brown wrote:
>> On Fri, Sep 30, 2011 at 09:57:30AM +0530, Rajendra Nayak wrote:
>
>>>>> + init_data->supply_regulator = (char *)of_get_property(dev->of_node,
>>>>> + "regulator-supplies", NULL);
>
>>> Mark, I still seem to be a little confused with this one as to why
>>> we would need a phandle *and* a supply-name to reference a parent
>>> regulator/supply.
>>> The phandle would point to a regulator dt node and that node internally
>>> would have just one name associated with it.
>
>> To repeat: the supply name is for the consumer. It is needed so that
>> the consumer can tell which supply is provided by which regulator.
>> Almost all devices have more than one supply and if the device does
>> anything more complicated than just turning on all the supplies when the
>> device is active it's going to need to figure out which supply is which.
>
> Hang on, I now have no idea what this is supposed to be doing. Later on
> in the series you had examples in your commit logs with perfectly
> sensible bindings for supplies:
>
> vmmc-supply =<®ulator1>;
> vpll-supply =<®ulator1>;
>
> which have both a unique name and a direct reference to the supplying
> regulator. What are these "regulator-supplies" properties supposed to
> be?
:-), yes, I was confused for a while as well after reading your response.
The "regulator-supplies" is used to specific the regulator *parent*.
Same as what was earlier passed by using the
"supply_regulator" field of regulator_init_data structure.
Grant wanted the bindings to support specifying multiple parents
and hence I was thinking of either a list of names *or*
a list of phandles to specify multiple parents to a regulator.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-09-30 11:09 ` Rajendra Nayak
@ 2011-09-30 11:35 ` Cousson, Benoit
-1 siblings, 0 replies; 114+ messages in thread
From: Cousson, Benoit @ 2011-09-30 11:35 UTC (permalink / raw)
To: Nayak, Rajendra
Cc: patches, tony, devicetree-discuss, Mark Brown, grant.likely,
linux-omap, Girdwood, Liam, linux-arm-kernel
On 9/30/2011 1:09 PM, Nayak, Rajendra wrote:
> On Friday 30 September 2011 04:18 PM, Mark Brown wrote:
>> On Fri, Sep 30, 2011 at 11:28:49AM +0100, Mark Brown wrote:
>>> On Fri, Sep 30, 2011 at 09:57:30AM +0530, Rajendra Nayak wrote:
>>
>>>>>> + init_data->supply_regulator = (char *)of_get_property(dev->of_node,
>>>>>> + "regulator-supplies", NULL);
>>
>>>> Mark, I still seem to be a little confused with this one as to why
>>>> we would need a phandle *and* a supply-name to reference a parent
>>>> regulator/supply.
>>>> The phandle would point to a regulator dt node and that node internally
>>>> would have just one name associated with it.
>>
>>> To repeat: the supply name is for the consumer. It is needed so that
>>> the consumer can tell which supply is provided by which regulator.
>>> Almost all devices have more than one supply and if the device does
>>> anything more complicated than just turning on all the supplies when the
>>> device is active it's going to need to figure out which supply is which.
>>
>> Hang on, I now have no idea what this is supposed to be doing. Later on
>> in the series you had examples in your commit logs with perfectly
>> sensible bindings for supplies:
>>
>> vmmc-supply =<®ulator1>;
>> vpll-supply =<®ulator1>;
>>
>> which have both a unique name and a direct reference to the supplying
>> regulator. What are these "regulator-supplies" properties supposed to
>> be?
>
> :-), yes, I was confused for a while as well after reading your response.
>
> The "regulator-supplies" is used to specific the regulator *parent*.
> Same as what was earlier passed by using the
> "supply_regulator" field of regulator_init_data structure.
> Grant wanted the bindings to support specifying multiple parents
> and hence I was thinking of either a list of names *or*
> a list of phandles to specify multiple parents to a regulator.
I'm confused too now :-)
You can not have multiple to one kind of connection from a power supply
to a single power rail of an IP (vmmc, vpll...).
So I do not see the need for more any other binding that the one you did:
vmmc-supply = <®ulator1>;
That kind of binding does not really exist in the real world:
vmmc-supply = <®ulator1 ®ulator2>;
At least not without a power switch in between.
Regards,
Benoit
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-09-30 11:35 ` Cousson, Benoit
0 siblings, 0 replies; 114+ messages in thread
From: Cousson, Benoit @ 2011-09-30 11:35 UTC (permalink / raw)
To: linux-arm-kernel
On 9/30/2011 1:09 PM, Nayak, Rajendra wrote:
> On Friday 30 September 2011 04:18 PM, Mark Brown wrote:
>> On Fri, Sep 30, 2011 at 11:28:49AM +0100, Mark Brown wrote:
>>> On Fri, Sep 30, 2011 at 09:57:30AM +0530, Rajendra Nayak wrote:
>>
>>>>>> + init_data->supply_regulator = (char *)of_get_property(dev->of_node,
>>>>>> + "regulator-supplies", NULL);
>>
>>>> Mark, I still seem to be a little confused with this one as to why
>>>> we would need a phandle *and* a supply-name to reference a parent
>>>> regulator/supply.
>>>> The phandle would point to a regulator dt node and that node internally
>>>> would have just one name associated with it.
>>
>>> To repeat: the supply name is for the consumer. It is needed so that
>>> the consumer can tell which supply is provided by which regulator.
>>> Almost all devices have more than one supply and if the device does
>>> anything more complicated than just turning on all the supplies when the
>>> device is active it's going to need to figure out which supply is which.
>>
>> Hang on, I now have no idea what this is supposed to be doing. Later on
>> in the series you had examples in your commit logs with perfectly
>> sensible bindings for supplies:
>>
>> vmmc-supply =<®ulator1>;
>> vpll-supply =<®ulator1>;
>>
>> which have both a unique name and a direct reference to the supplying
>> regulator. What are these "regulator-supplies" properties supposed to
>> be?
>
> :-), yes, I was confused for a while as well after reading your response.
>
> The "regulator-supplies" is used to specific the regulator *parent*.
> Same as what was earlier passed by using the
> "supply_regulator" field of regulator_init_data structure.
> Grant wanted the bindings to support specifying multiple parents
> and hence I was thinking of either a list of names *or*
> a list of phandles to specify multiple parents to a regulator.
I'm confused too now :-)
You can not have multiple to one kind of connection from a power supply
to a single power rail of an IP (vmmc, vpll...).
So I do not see the need for more any other binding that the one you did:
vmmc-supply = <®ulator1>;
That kind of binding does not really exist in the real world:
vmmc-supply = <®ulator1 ®ulator2>;
At least not without a power switch in between.
Regards,
Benoit
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-09-30 11:09 ` Rajendra Nayak
@ 2011-09-30 12:18 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-30 12:18 UTC (permalink / raw)
To: Rajendra Nayak
Cc: b-cousson, patches, tony, devicetree-discuss, grant.likely,
linux-omap, lrg, linux-arm-kernel
On Fri, Sep 30, 2011 at 04:39:02PM +0530, Rajendra Nayak wrote:
> The "regulator-supplies" is used to specific the regulator *parent*.
> Same as what was earlier passed by using the
> "supply_regulator" field of regulator_init_data structure.
> Grant wanted the bindings to support specifying multiple parents
> and hence I was thinking of either a list of names *or*
> a list of phandles to specify multiple parents to a regulator.
So, as I'm fairly sure I said last time these are just standard
supplies. It just happens to be that the consumer is a regulator. The
fact that Linux chooses to have core framework handling for this is an
implementation detail of Linux (and indeed many devices ignore this for
their on board regulators).
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-09-30 12:18 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-09-30 12:18 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 30, 2011 at 04:39:02PM +0530, Rajendra Nayak wrote:
> The "regulator-supplies" is used to specific the regulator *parent*.
> Same as what was earlier passed by using the
> "supply_regulator" field of regulator_init_data structure.
> Grant wanted the bindings to support specifying multiple parents
> and hence I was thinking of either a list of names *or*
> a list of phandles to specify multiple parents to a regulator.
So, as I'm fairly sure I said last time these are just standard
supplies. It just happens to be that the consumer is a regulator. The
fact that Linux chooses to have core framework handling for this is an
implementation detail of Linux (and indeed many devices ignore this for
their on board regulators).
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-09-30 12:18 ` Mark Brown
@ 2011-10-04 5:28 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-10-04 5:28 UTC (permalink / raw)
To: Mark Brown
Cc: b-cousson, patches, tony, devicetree-discuss, grant.likely,
linux-omap, lrg, linux-arm-kernel
On Friday 30 September 2011 05:48 PM, Mark Brown wrote:
> On Fri, Sep 30, 2011 at 04:39:02PM +0530, Rajendra Nayak wrote:
>
>> The "regulator-supplies" is used to specific the regulator *parent*.
>> Same as what was earlier passed by using the
>> "supply_regulator" field of regulator_init_data structure.
>> Grant wanted the bindings to support specifying multiple parents
>> and hence I was thinking of either a list of names *or*
>> a list of phandles to specify multiple parents to a regulator.
>
> So, as I'm fairly sure I said last time these are just standard
> supplies. It just happens to be that the consumer is a regulator. The
> fact that Linux chooses to have core framework handling for this is an
> implementation detail of Linux (and indeed many devices ignore this for
> their on board regulators).
Yes, the implementation details of linux is what is making me using
these bindings difficult, and maybe you can help me how I can work
around the framework. The binding themselves, I agree should not care
if the consumer is a device/IP or a regulator itself.
So here's my problem:
I use the <name-supply> = <®_phandle> binding to define
a device/IP using one/more regulators on one/more rails.
device mmc {
...
...
vmmc-supply = <&vmmc>;
vpll-supply = <&vpll>;
};
The parsing of the "vmmc-supply" or the "vpll-supply" property
happens only when a mmc drivers makes a call to
regulator_get() passing the supply-name as "vmmc" or "vpll".
For ex:
regulator_get(dev, "vmmc"); or regulator_get(dev, "vpll");
Its easy to just append the "-supply" to a "vmmc" or "vpll"
and derive a property name like "vmm-supply" or "vpll-supply".
Now lets take the case of a regulator as a consumer:
regulator vmmc {
...
...
vin-supply = <&vin>;
};
Now I need to parse the "vin-supply" property during a
regulator_register(), so I could do a set_supply() and
create the parent/child relationship between a vin and
vmmc.
The problem is I don't know if the property in the regulator dt
node is called "vin-supply" or "vxyz-supply" and hence I
can parse the property based on a substring alone, which is
"-supply" because all I know is the property name is expected
to end with a "-supply".
I can always add a new of_find_property_substr() which finds
me property based on a substring value passed rather than the
exact property-name string.
However I don;t know if this is the best way to handle it.
Any thoughts?
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-10-04 5:28 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-10-04 5:28 UTC (permalink / raw)
To: linux-arm-kernel
On Friday 30 September 2011 05:48 PM, Mark Brown wrote:
> On Fri, Sep 30, 2011 at 04:39:02PM +0530, Rajendra Nayak wrote:
>
>> The "regulator-supplies" is used to specific the regulator *parent*.
>> Same as what was earlier passed by using the
>> "supply_regulator" field of regulator_init_data structure.
>> Grant wanted the bindings to support specifying multiple parents
>> and hence I was thinking of either a list of names *or*
>> a list of phandles to specify multiple parents to a regulator.
>
> So, as I'm fairly sure I said last time these are just standard
> supplies. It just happens to be that the consumer is a regulator. The
> fact that Linux chooses to have core framework handling for this is an
> implementation detail of Linux (and indeed many devices ignore this for
> their on board regulators).
Yes, the implementation details of linux is what is making me using
these bindings difficult, and maybe you can help me how I can work
around the framework. The binding themselves, I agree should not care
if the consumer is a device/IP or a regulator itself.
So here's my problem:
I use the <name-supply> = <®_phandle> binding to define
a device/IP using one/more regulators on one/more rails.
device mmc {
...
...
vmmc-supply = <&vmmc>;
vpll-supply = <&vpll>;
};
The parsing of the "vmmc-supply" or the "vpll-supply" property
happens only when a mmc drivers makes a call to
regulator_get() passing the supply-name as "vmmc" or "vpll".
For ex:
regulator_get(dev, "vmmc"); or regulator_get(dev, "vpll");
Its easy to just append the "-supply" to a "vmmc" or "vpll"
and derive a property name like "vmm-supply" or "vpll-supply".
Now lets take the case of a regulator as a consumer:
regulator vmmc {
...
...
vin-supply = <&vin>;
};
Now I need to parse the "vin-supply" property during a
regulator_register(), so I could do a set_supply() and
create the parent/child relationship between a vin and
vmmc.
The problem is I don't know if the property in the regulator dt
node is called "vin-supply" or "vxyz-supply" and hence I
can parse the property based on a substring alone, which is
"-supply" because all I know is the property name is expected
to end with a "-supply".
I can always add a new of_find_property_substr() which finds
me property based on a substring value passed rather than the
exact property-name string.
However I don;t know if this is the best way to handle it.
Any thoughts?
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-10-04 5:28 ` Rajendra Nayak
@ 2011-10-04 10:18 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-10-04 10:18 UTC (permalink / raw)
To: Rajendra Nayak
Cc: b-cousson, patches, tony, devicetree-discuss, grant.likely,
linux-omap, lrg, linux-arm-kernel
On Tue, Oct 04, 2011 at 10:58:40AM +0530, Rajendra Nayak wrote:
> The problem is I don't know if the property in the regulator dt
> node is called "vin-supply" or "vxyz-supply" and hence I
> can parse the property based on a substring alone, which is
> "-supply" because all I know is the property name is expected
> to end with a "-supply".
This seems fairly straightforward though it will require some changes
within Linux, all we have to do is have the regulators name their
supplies.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-10-04 10:18 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-10-04 10:18 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 04, 2011 at 10:58:40AM +0530, Rajendra Nayak wrote:
> The problem is I don't know if the property in the regulator dt
> node is called "vin-supply" or "vxyz-supply" and hence I
> can parse the property based on a substring alone, which is
> "-supply" because all I know is the property name is expected
> to end with a "-supply".
This seems fairly straightforward though it will require some changes
within Linux, all we have to do is have the regulators name their
supplies.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-10-04 10:18 ` Mark Brown
@ 2011-10-04 11:40 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-10-04 11:40 UTC (permalink / raw)
To: Mark Brown
Cc: b-cousson, patches, tony, devicetree-discuss, grant.likely,
linux-omap, lrg, linux-arm-kernel
On Tuesday 04 October 2011 03:48 PM, Mark Brown wrote:
> On Tue, Oct 04, 2011 at 10:58:40AM +0530, Rajendra Nayak wrote:
>
>> The problem is I don't know if the property in the regulator dt
>> node is called "vin-supply" or "vxyz-supply" and hence I
>> can parse the property based on a substring alone, which is
>> "-supply" because all I know is the property name is expected
>> to end with a "-supply".
>
> This seems fairly straightforward though it will require some changes
> within Linux, all we have to do is have the regulators name their
> supplies.
through dt? thats what the original bindings was doing.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-10-04 11:40 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-10-04 11:40 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 04 October 2011 03:48 PM, Mark Brown wrote:
> On Tue, Oct 04, 2011 at 10:58:40AM +0530, Rajendra Nayak wrote:
>
>> The problem is I don't know if the property in the regulator dt
>> node is called "vin-supply" or "vxyz-supply" and hence I
>> can parse the property based on a substring alone, which is
>> "-supply" because all I know is the property name is expected
>> to end with a "-supply".
>
> This seems fairly straightforward though it will require some changes
> within Linux, all we have to do is have the regulators name their
> supplies.
through dt? thats what the original bindings was doing.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-10-04 11:40 ` Rajendra Nayak
@ 2011-10-04 11:51 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-10-04 11:51 UTC (permalink / raw)
To: Rajendra Nayak
Cc: b-cousson, patches, tony, devicetree-discuss, grant.likely,
linux-omap, lrg, linux-arm-kernel
On Tue, Oct 04, 2011 at 05:10:00PM +0530, Rajendra Nayak wrote:
> On Tuesday 04 October 2011 03:48 PM, Mark Brown wrote:
> >This seems fairly straightforward though it will require some changes
> >within Linux, all we have to do is have the regulators name their
> >supplies.
> through dt? thats what the original bindings was doing.
I wouldn't expect it done through DT (except for things like the fixed
voltage regulator) - the driver should just know.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-10-04 11:51 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-10-04 11:51 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 04, 2011 at 05:10:00PM +0530, Rajendra Nayak wrote:
> On Tuesday 04 October 2011 03:48 PM, Mark Brown wrote:
> >This seems fairly straightforward though it will require some changes
> >within Linux, all we have to do is have the regulators name their
> >supplies.
> through dt? thats what the original bindings was doing.
I wouldn't expect it done through DT (except for things like the fixed
voltage regulator) - the driver should just know.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-10-04 11:51 ` Mark Brown
@ 2011-10-04 12:02 ` Rajendra Nayak
-1 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-10-04 12:02 UTC (permalink / raw)
To: Mark Brown
Cc: b-cousson, patches, tony, devicetree-discuss, grant.likely,
linux-omap, lrg, linux-arm-kernel
On Tuesday 04 October 2011 05:21 PM, Mark Brown wrote:
> On Tue, Oct 04, 2011 at 05:10:00PM +0530, Rajendra Nayak wrote:
>> On Tuesday 04 October 2011 03:48 PM, Mark Brown wrote:
>
>>> This seems fairly straightforward though it will require some changes
>>> within Linux, all we have to do is have the regulators name their
>>> supplies.
>
>> through dt? thats what the original bindings was doing.
>
> I wouldn't expect it done through DT (except for things like the fixed
> voltage regulator) - the driver should just know.
something like a
int regulator_set_supply(struct regulator_dev *rdev, char *supply_name);
to be called from drivers makes sense?
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-10-04 12:02 ` Rajendra Nayak
0 siblings, 0 replies; 114+ messages in thread
From: Rajendra Nayak @ 2011-10-04 12:02 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 04 October 2011 05:21 PM, Mark Brown wrote:
> On Tue, Oct 04, 2011 at 05:10:00PM +0530, Rajendra Nayak wrote:
>> On Tuesday 04 October 2011 03:48 PM, Mark Brown wrote:
>
>>> This seems fairly straightforward though it will require some changes
>>> within Linux, all we have to do is have the regulators name their
>>> supplies.
>
>> through dt? thats what the original bindings was doing.
>
> I wouldn't expect it done through DT (except for things like the fixed
> voltage regulator) - the driver should just know.
something like a
int regulator_set_supply(struct regulator_dev *rdev, char *supply_name);
to be called from drivers makes sense?
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-10-04 12:02 ` Rajendra Nayak
@ 2011-10-04 12:11 ` Mark Brown
-1 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-10-04 12:11 UTC (permalink / raw)
To: Rajendra Nayak
Cc: b-cousson, patches, tony, devicetree-discuss, grant.likely,
linux-omap, lrg, linux-arm-kernel
On Tue, Oct 04, 2011 at 05:32:47PM +0530, Rajendra Nayak wrote:
> On Tuesday 04 October 2011 05:21 PM, Mark Brown wrote:
> >I wouldn't expect it done through DT (except for things like the fixed
> >voltage regulator) - the driver should just know.
> something like a
> int regulator_set_supply(struct regulator_dev *rdev, char *supply_name);
> to be called from drivers makes sense?
Just put a member in the driver struct, much simpler that way, no code
in the individual drivers.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-10-04 12:11 ` Mark Brown
0 siblings, 0 replies; 114+ messages in thread
From: Mark Brown @ 2011-10-04 12:11 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 04, 2011 at 05:32:47PM +0530, Rajendra Nayak wrote:
> On Tuesday 04 October 2011 05:21 PM, Mark Brown wrote:
> >I wouldn't expect it done through DT (except for things like the fixed
> >voltage regulator) - the driver should just know.
> something like a
> int regulator_set_supply(struct regulator_dev *rdev, char *supply_name);
> to be called from drivers makes sense?
Just put a member in the driver struct, much simpler that way, no code
in the individual drivers.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-10-04 12:11 ` Mark Brown
@ 2011-10-04 12:40 ` Nayak, Rajendra
-1 siblings, 0 replies; 114+ messages in thread
From: Nayak, Rajendra @ 2011-10-04 12:40 UTC (permalink / raw)
To: Mark Brown
Cc: b-cousson, patches, tony, devicetree-discuss, grant.likely,
linux-omap, lrg, linux-arm-kernel
On Tue, Oct 4, 2011 at 5:41 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
>
> On Tue, Oct 04, 2011 at 05:32:47PM +0530, Rajendra Nayak wrote:
> > On Tuesday 04 October 2011 05:21 PM, Mark Brown wrote:
>
> > >I wouldn't expect it done through DT (except for things like the fixed
> > >voltage regulator) - the driver should just know.
>
> > something like a
> > int regulator_set_supply(struct regulator_dev *rdev, char *supply_name);
> > to be called from drivers makes sense?
>
> Just put a member in the driver struct, much simpler that way, no code
> in the individual drivers.
okay, makes sense. I will add it to struct regulator_desc.
Thanks.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-10-04 12:40 ` Nayak, Rajendra
0 siblings, 0 replies; 114+ messages in thread
From: Nayak, Rajendra @ 2011-10-04 12:40 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 4, 2011 at 5:41 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
>
> On Tue, Oct 04, 2011 at 05:32:47PM +0530, Rajendra Nayak wrote:
> > On Tuesday 04 October 2011 05:21 PM, Mark Brown wrote:
>
> > >I wouldn't expect it done through DT (except for things like the fixed
> > >voltage regulator) - the driver should just know.
>
> > something like a
> > int regulator_set_supply(struct regulator_dev *rdev, char *supply_name);
> > to be called from drivers makes sense?
>
> Just put a member in the driver struct, much simpler that way, no code
> in the individual drivers.
okay, makes sense. I will add it to struct regulator_desc.
Thanks.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 8/9] regulator: helper to extract regulator node based on supply name
2011-09-30 9:34 ` Rajendra Nayak
@ 2011-10-04 17:00 ` Grant Likely
-1 siblings, 0 replies; 114+ messages in thread
From: Grant Likely @ 2011-10-04 17:00 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Mark Brown, Cousson, Benoit, devicetree-discuss, linux-omap,
linux-arm-kernel, tony, Girdwood, Liam, patches
On Fri, Sep 30, 2011 at 03:04:45PM +0530, Rajendra Nayak wrote:
> On Wednesday 28 September 2011 05:56 PM, Mark Brown wrote:
> >On Wed, Sep 28, 2011 at 10:09:30AM +0200, Cousson, Benoit wrote:
> >>On 9/27/2011 8:59 PM, Mark Brown wrote:
> >
> >>>I'm not sure how this should work in a device tree world, I'd *hope*
> >>>we'd get a device tree node for the CPU and could then just make this a
> >>>regular consumer thing but then the cpufreq drivers would need to be
> >>>updated to make use of it. The only reason we allow null devices right
> >>>now is the fact that cpufreq doesn't have a struct device it can use.
> >
> >>That's why we do have a MPU node in OMAP dts, in order to build an
> >>omap_device that will be mainly used for the DVFS on the MPU.
> >
> >>And even before DT migration, we used to build statically some
> >>omap_device to represent the various processors in the system (MPU,
> >>DSP, CortexM3...).
> >
> >Yeah, but that's very OMAP specific - we don't have that in general (in
> >fact it's the only Linux platform I'm aware of that has a device for the
> >CPU).
>
> But isn't this the right thing to do for everyone else too?
>
It is normal to have nodes for each CPU. The /cpus/ node normally
contains cpu@* nodes for each logical cpu core, and I would expect
nodes for each additional DSP and MPU core. Whether or not they
belong in the /cpus/ node is a matter of design (we don't have any
patterns for that yet).
g.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 8/9] regulator: helper to extract regulator node based on supply name
@ 2011-10-04 17:00 ` Grant Likely
0 siblings, 0 replies; 114+ messages in thread
From: Grant Likely @ 2011-10-04 17:00 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 30, 2011 at 03:04:45PM +0530, Rajendra Nayak wrote:
> On Wednesday 28 September 2011 05:56 PM, Mark Brown wrote:
> >On Wed, Sep 28, 2011 at 10:09:30AM +0200, Cousson, Benoit wrote:
> >>On 9/27/2011 8:59 PM, Mark Brown wrote:
> >
> >>>I'm not sure how this should work in a device tree world, I'd *hope*
> >>>we'd get a device tree node for the CPU and could then just make this a
> >>>regular consumer thing but then the cpufreq drivers would need to be
> >>>updated to make use of it. The only reason we allow null devices right
> >>>now is the fact that cpufreq doesn't have a struct device it can use.
> >
> >>That's why we do have a MPU node in OMAP dts, in order to build an
> >>omap_device that will be mainly used for the DVFS on the MPU.
> >
> >>And even before DT migration, we used to build statically some
> >>omap_device to represent the various processors in the system (MPU,
> >>DSP, CortexM3...).
> >
> >Yeah, but that's very OMAP specific - we don't have that in general (in
> >fact it's the only Linux platform I'm aware of that has a device for the
> >CPU).
>
> But isn't this the right thing to do for everyone else too?
>
It is normal to have nodes for each CPU. The /cpus/ node normally
contains cpu@* nodes for each logical cpu core, and I would expect
nodes for each additional DSP and MPU core. Whether or not they
belong in the /cpus/ node is a matter of design (we don't have any
patterns for that yet).
g.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-09-27 12:10 ` Mark Brown
@ 2011-10-04 23:01 ` Russell King - ARM Linux
-1 siblings, 0 replies; 114+ messages in thread
From: Russell King - ARM Linux @ 2011-10-04 23:01 UTC (permalink / raw)
To: Mark Brown
Cc: Rajendra Nayak, b-cousson, patches, tony, devicetree-discuss,
grant.likely, linux-omap, lrg, linux-arm-kernel
On Tue, Sep 27, 2011 at 01:10:04PM +0100, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
>
> > + init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
> > + GFP_KERNEL);
> > + if (!init_data)
> > + return NULL; /* Out of memory? */
>
> This means that the init data will be kept around for the entire
> lifetime of the device rather than being discarded.
May I remind you that devm_* lifetime expires whenever the associated
driver is unbound, which can be much shorter than the lifetime of the
struct device.
It expires when any of the following occurs:
1. userspace asks the associated driver to be unbound
2. the driver is removed
3. any driver probe for this struct device fails
4. the struct device is unregistered.
So: don't use devm_* for anything other than stuff inside a driver being
associated with the struct device itself. Other uses are a bug waiting
to happen.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-10-04 23:01 ` Russell King - ARM Linux
0 siblings, 0 replies; 114+ messages in thread
From: Russell King - ARM Linux @ 2011-10-04 23:01 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 27, 2011 at 01:10:04PM +0100, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
>
> > + init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
> > + GFP_KERNEL);
> > + if (!init_data)
> > + return NULL; /* Out of memory? */
>
> This means that the init data will be kept around for the entire
> lifetime of the device rather than being discarded.
May I remind you that devm_* lifetime expires whenever the associated
driver is unbound, which can be much shorter than the lifetime of the
struct device.
It expires when any of the following occurs:
1. userspace asks the associated driver to be unbound
2. the driver is removed
3. any driver probe for this struct device fails
4. the struct device is unregistered.
So: don't use devm_* for anything other than stuff inside a driver being
associated with the struct device itself. Other uses are a bug waiting
to happen.
^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data
2011-10-04 23:01 ` Russell King - ARM Linux
@ 2011-10-04 23:48 ` Grant Likely
-1 siblings, 0 replies; 114+ messages in thread
From: Grant Likely @ 2011-10-04 23:48 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Mark Brown, Rajendra Nayak, b-cousson, patches, tony,
devicetree-discuss, linux-omap, lrg, linux-arm-kernel
On Wed, Oct 05, 2011 at 12:01:27AM +0100, Russell King - ARM Linux wrote:
> On Tue, Sep 27, 2011 at 01:10:04PM +0100, Mark Brown wrote:
> > On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
> >
> > > + init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
> > > + GFP_KERNEL);
> > > + if (!init_data)
> > > + return NULL; /* Out of memory? */
> >
> > This means that the init data will be kept around for the entire
> > lifetime of the device rather than being discarded.
>
> May I remind you that devm_* lifetime expires whenever the associated
> driver is unbound, which can be much shorter than the lifetime of the
> struct device.
>
> It expires when any of the following occurs:
> 1. userspace asks the associated driver to be unbound
> 2. the driver is removed
> 3. any driver probe for this struct device fails
> 4. the struct device is unregistered.
>
> So: don't use devm_* for anything other than stuff inside a driver being
> associated with the struct device itself. Other uses are a bug waiting
> to happen.
Yes, Russell is right. There were a number of places where I
suggested using devm_* in entirely the wrong places. Double check
anyplace where you've added devm_ calls.
g.
^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
@ 2011-10-04 23:48 ` Grant Likely
0 siblings, 0 replies; 114+ messages in thread
From: Grant Likely @ 2011-10-04 23:48 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Oct 05, 2011 at 12:01:27AM +0100, Russell King - ARM Linux wrote:
> On Tue, Sep 27, 2011 at 01:10:04PM +0100, Mark Brown wrote:
> > On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
> >
> > > + init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
> > > + GFP_KERNEL);
> > > + if (!init_data)
> > > + return NULL; /* Out of memory? */
> >
> > This means that the init data will be kept around for the entire
> > lifetime of the device rather than being discarded.
>
> May I remind you that devm_* lifetime expires whenever the associated
> driver is unbound, which can be much shorter than the lifetime of the
> struct device.
>
> It expires when any of the following occurs:
> 1. userspace asks the associated driver to be unbound
> 2. the driver is removed
> 3. any driver probe for this struct device fails
> 4. the struct device is unregistered.
>
> So: don't use devm_* for anything other than stuff inside a driver being
> associated with the struct device itself. Other uses are a bug waiting
> to happen.
Yes, Russell is right. There were a number of places where I
suggested using devm_* in entirely the wrong places. Double check
anyplace where you've added devm_ calls.
g.
^ permalink raw reply [flat|nested] 114+ messages in thread
end of thread, other threads:[~2011-10-04 23:48 UTC | newest]
Thread overview: 114+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-27 10:12 [PATCH 0/9] Device tree support for regulators Rajendra Nayak
2011-09-27 10:12 ` Rajendra Nayak
2011-09-27 10:12 ` [PATCH 1/9] regulator: twl: Remove hardcoded board constraints from driver Rajendra Nayak
2011-09-27 10:12 ` Rajendra Nayak
2011-09-27 11:37 ` Mark Brown
2011-09-27 11:37 ` Mark Brown
2011-09-27 14:47 ` Rajendra Nayak
2011-09-27 14:47 ` Rajendra Nayak
2011-09-27 10:12 ` [PATCH 2/9] regulator: helper routine to extract regulator_init_data Rajendra Nayak
2011-09-27 10:12 ` Rajendra Nayak
2011-09-27 12:10 ` Mark Brown
2011-09-27 12:10 ` Mark Brown
2011-09-27 14:48 ` Rajendra Nayak
2011-09-27 14:48 ` Rajendra Nayak
[not found] ` <4E81E224.2070408-l0cyMroinI0@public.gmane.org>
2011-09-27 15:05 ` Mark Brown
2011-09-27 15:05 ` Mark Brown
2011-09-28 8:06 ` Cousson, Benoit
2011-09-28 8:06 ` Cousson, Benoit
2011-09-30 4:27 ` Rajendra Nayak
2011-09-30 4:27 ` Rajendra Nayak
2011-09-30 7:58 ` Cousson, Benoit
2011-09-30 7:58 ` Cousson, Benoit
2011-09-30 10:49 ` Mark Brown
2011-09-30 10:49 ` Mark Brown
2011-09-30 10:28 ` Mark Brown
2011-09-30 10:28 ` Mark Brown
2011-09-30 10:48 ` Mark Brown
2011-09-30 10:48 ` Mark Brown
2011-09-30 11:09 ` Rajendra Nayak
2011-09-30 11:09 ` Rajendra Nayak
2011-09-30 11:35 ` Cousson, Benoit
2011-09-30 11:35 ` Cousson, Benoit
2011-09-30 12:18 ` Mark Brown
2011-09-30 12:18 ` Mark Brown
2011-10-04 5:28 ` Rajendra Nayak
2011-10-04 5:28 ` Rajendra Nayak
2011-10-04 10:18 ` Mark Brown
2011-10-04 10:18 ` Mark Brown
2011-10-04 11:40 ` Rajendra Nayak
2011-10-04 11:40 ` Rajendra Nayak
2011-10-04 11:51 ` Mark Brown
2011-10-04 11:51 ` Mark Brown
2011-10-04 12:02 ` Rajendra Nayak
2011-10-04 12:02 ` Rajendra Nayak
2011-10-04 12:11 ` Mark Brown
2011-10-04 12:11 ` Mark Brown
2011-10-04 12:40 ` Nayak, Rajendra
2011-10-04 12:40 ` Nayak, Rajendra
[not found] ` <20110927121003.GB4289-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-09-30 1:24 ` Grant Likely
2011-09-30 1:24 ` Grant Likely
2011-10-04 23:01 ` Russell King - ARM Linux
2011-10-04 23:01 ` Russell King - ARM Linux
2011-10-04 23:48 ` Grant Likely
2011-10-04 23:48 ` Grant Likely
2011-09-27 10:12 ` [PATCH 3/9] omap4: sdp: Pass regulator data from dt Rajendra Nayak
2011-09-27 10:12 ` Rajendra Nayak
2011-09-27 10:12 ` [PATCH 4/9] regulator: twl: Make twl-regulator driver extract data from DT Rajendra Nayak
2011-09-27 10:12 ` Rajendra Nayak
2011-09-27 12:14 ` Mark Brown
2011-09-27 12:14 ` Mark Brown
2011-09-27 14:48 ` Rajendra Nayak
2011-09-27 14:48 ` Rajendra Nayak
2011-09-27 10:12 ` [PATCH 5/9] regulator: helper routine to extract fixed_voltage_config Rajendra Nayak
2011-09-27 10:12 ` Rajendra Nayak
2011-09-27 12:16 ` Mark Brown
2011-09-27 12:16 ` Mark Brown
2011-09-27 14:49 ` Rajendra Nayak
2011-09-27 14:49 ` Rajendra Nayak
2011-09-27 16:13 ` Mark Brown
2011-09-27 16:13 ` Mark Brown
[not found] ` <1317118372-17052-6-git-send-email-rnayak-l0cyMroinI0@public.gmane.org>
2011-09-30 1:26 ` Grant Likely
2011-09-30 1:26 ` Grant Likely
2011-09-27 10:12 ` [PATCH 6/9] regulator: make fixed regulator driver extract data from dt Rajendra Nayak
2011-09-27 10:12 ` Rajendra Nayak
2011-09-30 1:34 ` Grant Likely
2011-09-30 1:34 ` Grant Likely
2011-09-27 10:12 ` [PATCH 7/9] omap4: panda: Pass regulator data from DT Rajendra Nayak
2011-09-27 10:12 ` Rajendra Nayak
2011-09-27 10:12 ` [PATCH 8/9] regulator: helper to extract regulator node based on supply name Rajendra Nayak
2011-09-27 10:12 ` Rajendra Nayak
2011-09-27 12:21 ` Mark Brown
2011-09-27 12:21 ` Mark Brown
2011-09-27 14:49 ` Rajendra Nayak
2011-09-27 14:49 ` Rajendra Nayak
2011-09-27 18:59 ` Mark Brown
2011-09-27 18:59 ` Mark Brown
2011-09-28 8:09 ` Cousson, Benoit
2011-09-28 8:09 ` Cousson, Benoit
2011-09-28 8:18 ` Rajendra Nayak
2011-09-28 8:18 ` Rajendra Nayak
2011-09-28 12:26 ` Mark Brown
2011-09-28 12:26 ` Mark Brown
2011-09-30 9:34 ` Rajendra Nayak
2011-09-30 9:34 ` Rajendra Nayak
2011-09-30 10:35 ` Mark Brown
2011-09-30 10:35 ` Mark Brown
2011-10-04 17:00 ` Grant Likely
2011-10-04 17:00 ` Grant Likely
2011-09-28 10:56 ` Rajendra Nayak
2011-09-28 10:56 ` Rajendra Nayak
2011-09-30 1:36 ` Grant Likely
2011-09-30 1:36 ` Grant Likely
2011-09-27 10:12 ` [PATCH 9/9] regulator: map consumer regulator based on device tree Rajendra Nayak
2011-09-27 10:12 ` Rajendra Nayak
2011-09-27 12:23 ` Mark Brown
2011-09-27 12:23 ` Mark Brown
2011-09-27 14:49 ` Rajendra Nayak
2011-09-27 14:49 ` Rajendra Nayak
[not found] ` <1317118372-17052-10-git-send-email-rnayak-l0cyMroinI0@public.gmane.org>
2011-09-30 1:38 ` Grant Likely
2011-09-30 1:38 ` Grant Likely
2011-09-30 9:29 ` Rajendra Nayak
2011-09-30 9:29 ` Rajendra Nayak
2011-09-30 1:39 ` [PATCH 0/9] Device tree support for regulators Grant Likely
2011-09-30 1:39 ` Grant Likely
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.