* [RFC PATCH 06/11] DT: regulator: Helper routine to extract fixed_voltage_config
From: Rajendra Nayak @ 2011-09-15 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-6-git-send-email-rnayak@ti.com>
The helper routine defined here (of_get_fixed_voltage_config) can
be used to extract information about fixed regulators (which are not
software controlable) from device tree.
Add documenation about additional bindings for fixed
regulators that can be passed through DT.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
.../devicetree/bindings/regulator/regulator.txt | 19 ++++++++++++
drivers/of/of_regulator.c | 31 ++++++++++++++++++++
include/linux/of_regulator.h | 7 ++++
3 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
index 001e5ce..f8c51d8 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -2,6 +2,8 @@ Voltage/Current Regulators
Required properties:
- compatible: Must be "regulator";
+or
+- compatible: Must be "regulator-fixed"; /* For Fixed volatge regulator */
Optional properties:
- supply-regulator: Name of the parent regulator
@@ -24,6 +26,13 @@ Optional properties:
- always-on: boolean, regulator should never be disabled
- boot-on: bootloader/firmware enabled regulator
- apply-uV: apply uV constraint if min == max
+# For fixed voltage regulators
+- supply-name: Name of the regulator supply
+- microvolts: Output voltage of regulator
+- gpio: gpio to use for enable control
+- startup-delay: startup time in microseconds
+- enable-high: Polarity of enable GPIO, 1 = Active High, 0 = Active low
+- enabled-at-boot: 1 = yes, 0 = no
Example:
@@ -35,3 +44,13 @@ Example:
change-voltage;
always-on;
};
+
+ abc-fixedregulator {
+ compatible = "regulator-fixed";
+ supply-name = "fixed-supply";
+ microvolts = <1800000>;
+ gpio = <43>;
+ startup-delay = <70000>;
+ enable-high;
+ enabled-at-boot;
+ };
diff --git a/drivers/of/of_regulator.c b/drivers/of/of_regulator.c
index f01d275..4d7a49d 100644
--- a/drivers/of/of_regulator.c
+++ b/drivers/of/of_regulator.c
@@ -13,6 +13,7 @@
#include <linux/slab.h>
#include <linux/of.h>
#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
static void of_get_regulation_constraints(struct device_node *np,
struct regulator_init_data **init_data)
@@ -83,3 +84,33 @@ struct regulator_init_data *of_get_regulator_init_data(struct device_node *np)
return init_data;
}
EXPORT_SYMBOL(of_get_regulator_init_data);
+
+/**
+ * of_get_fixed_voltage_config - extract fixed_voltage_config structure info
+ * @np: Pointer to fixed-regulator device tree node
+ *
+ * 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_node *np)
+{
+ struct fixed_voltage_config *config;
+
+ config = kzalloc(sizeof(struct fixed_voltage_config), GFP_KERNEL);
+ if (!config)
+ return NULL;
+
+ config->supply_name = (char *)of_get_property(np, "supply-name", NULL);
+ of_property_read_u32(np, "microvolts", &config->microvolts);
+ of_property_read_u32(np, "gpio", &config->gpio);
+ of_property_read_u32(np, "startup-delay", &config->startup_delay);
+ if (of_find_property(np, "enable-high", NULL))
+ config->enable_high = true;
+ if (of_find_property(np, "enabled-at-boot", NULL))
+ config->enabled_at_boot = true;
+ config->init_data = of_get_regulator_init_data(np);
+
+ return config;
+}
+EXPORT_SYMBOL(of_get_fixed_voltage_config);
diff --git a/include/linux/of_regulator.h b/include/linux/of_regulator.h
index 5eb048c..39860c5 100644
--- a/include/linux/of_regulator.h
+++ b/include/linux/of_regulator.h
@@ -11,12 +11,19 @@
#if defined(CONFIG_OF_REGULATOR)
extern struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np);
+extern struct fixed_voltage_config
+ *of_get_fixed_voltage_config(struct device_node *np);
#else
static inline struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np)
{
return NULL;
}
+static inline struct fixed_voltage_config
+ *of_get_fixed_voltage_config(struct device_node *np)
+{
+ return NULL;
+}
#endif /* CONFIG_OF_REGULATOR */
#endif /* __LINUX_OF_REG_H */
--
1.7.1
^ permalink raw reply related
* [RFC PATCH 05/11] TWL: regulator: Make twl-regulator driver extract data from DT
From: Rajendra Nayak @ 2011-09-15 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-5-git-send-email-rnayak@ti.com>
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 | 28 +++++++++++++++++++++++++---
1 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c b/drivers/regulator/twl-regulator.c
index ee8747f..df1b95a 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -17,6 +17,8 @@
#include <linux/regulator/driver.h>
#include <linux/regulator/machine.h>
#include <linux/i2c/twl.h>
+#include <linux/of.h>
+#include <linux/of_regulator.h>
/*
@@ -1011,6 +1013,9 @@ static int __devinit twlreg_probe(struct platform_device *pdev)
struct regulation_constraints *c;
struct regulator_dev *rdev;
+ if (pdev->dev.of_node)
+ of_property_read_u32(pdev->dev.of_node, "ti,reg-id", &pdev->id);
+
for (i = 0, info = NULL; i < ARRAY_SIZE(twl_regs); i++) {
if (twl_regs[i].desc.id != pdev->id)
continue;
@@ -1020,7 +1025,11 @@ static int __devinit twlreg_probe(struct platform_device *pdev)
if (!info)
return -ENODEV;
- initdata = pdev->dev.platform_data;
+ if (pdev->dev.of_node)
+ initdata = of_get_regulator_init_data(pdev->dev.of_node);
+ else
+ initdata = pdev->dev.platform_data;
+
if (!initdata)
return -EINVAL;
@@ -1101,14 +1110,27 @@ 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,twl-reg", },
+ {},
+};
+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
* [RFC PATCH 04/11] omap4: SDP: Pass regulator_init_data from DT
From: Rajendra Nayak @ 2011-09-15 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-4-git-send-email-rnayak@ti.com>
Pass regulator_init_data 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().
Add documentation for TWL regulator specific bindings.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
.../bindings/regulator/twl-regulator.txt | 18 ++++++++++++++++++
arch/arm/boot/dts/omap4-sdp.dts | 16 ++++++++++++++++
2 files changed, 34 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..59df44b
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -0,0 +1,18 @@
+TWL family of regulators
+
+Required properties:
+- compatible: Must be "regulator","ti,twl-reg";
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+- ti,reg-id: Identifier for a TWL regulator, defined in linux/i2c/twl.h file.
+
+Example:
+
+ xyz-regulator: regulator at 0 {
+ compatible = "regulator","ti,twl-reg";
+ ti,reg-id = <37>; /* TWL6030_REG_VAUX1_6030 */
+ min-uV = <1000000>;
+ max-uV = <3000000>;
+ apply-uV;
+ };
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 14faf92..2a613e2 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -52,6 +52,22 @@
interrupts = <11>;
reg = <0>;
};
+
+ vaux1-regulator: regulator at 0 {
+ compatible = "regulator","ti,twl-reg";
+ ti,reg-id = <37>; /* TWL6030_REG_VAUX1_6030 */
+ min-uV = <1000000>;
+ max-uV = <3000000>;
+ apply-uV;
+ };
+
+ vusim-regulator: regulator at 1 {
+ compatible = "regulator","ti,twl-reg";
+ ti,reg-id = <42>; /* TWL6030_REG_VUSIM */
+ min-uV = <1200000>;
+ max-uV = <2900000>;
+ apply_uV;
+ };
};
};
--
1.7.1
^ permalink raw reply related
* [RFC PATCH 03/11] DT: regulator: Helper routine to extract regulator_init_data
From: Rajendra Nayak @ 2011-09-15 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-3-git-send-email-rnayak@ti.com>
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure passed from device tree.
'consumer_supplies' which is part of regulator_init_data is not extracted
as the regulator consumer mappings are passed through DT differently,
implemented in subsequent patches.
Also add documentation for regulator bindings to be used to pass
regulator_init_data struct information from device tree.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
.../devicetree/bindings/regulator/regulator.txt | 37 +++++++++
drivers/of/Kconfig | 6 ++
drivers/of/Makefile | 1 +
drivers/of/of_regulator.c | 85 ++++++++++++++++++++
include/linux/of_regulator.h | 23 +++++
5 files changed, 152 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
create mode 100644 drivers/of/of_regulator.c
create mode 100644 include/linux/of_regulator.h
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
new file mode 100644
index 0000000..001e5ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -0,0 +1,37 @@
+Voltage/Current Regulators
+
+Required properties:
+- compatible: Must be "regulator";
+
+Optional properties:
+- supply-regulator: Name of the parent regulator
+- min-uV: smallest voltage consumers may set
+- max-uV: largest voltage consumers may set
+- uV-offset: Offset applied to voltages from consumer to compensate for voltage drops
+- min-uA: smallest current consumers may set
+- max-uA: largest current consumers may set
+- mode-fast: boolean, Can handle fast changes in its load
+- mode-normal: boolean, Normal regulator power supply mode
+- mode-idle: boolean, Can be more efficient during light loads
+- mode-standby: boolean, Can be most efficient during light loads
+- change-voltage: boolean, Output voltage can be changed by software
+- change-current: boolean, Output current can be chnaged by software
+- change-mode: boolean, Operating mode can be changed by software
+- change-status: boolean, Enable/Disable control for regulator exists
+- change-drms: boolean, Dynamic regulator mode switching is enabled
+- input-uV: Input voltage for regulator when supplied by another regulator
+- initial-mode: Mode to set at startup
+- always-on: boolean, regulator should never be disabled
+- boot-on: bootloader/firmware enabled regulator
+- apply-uV: apply uV constraint if min == max
+
+Example:
+
+ xyz-regulator: regulator at 0 {
+ compatible = "regulator";
+ min-uV = <1000000>;
+ max-uV = <2500000>;
+ mode-fast;
+ change-voltage;
+ always-on;
+ };
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index b3bfea5..296b96d 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -87,4 +87,10 @@ config OF_PCI_IRQ
help
OpenFirmware PCI IRQ routing helpers
+config OF_REGULATOR
+ def_bool y
+ depends on REGULATOR
+ help
+ OpenFirmware regulator framework helpers
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 74b959c..bea2852 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SPI) += of_spi.o
obj-$(CONFIG_OF_MDIO) += of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
+obj-$(CONFIG_OF_REGULATOR) += of_regulator.o
diff --git a/drivers/of/of_regulator.c b/drivers/of/of_regulator.c
new file mode 100644
index 0000000..f01d275
--- /dev/null
+++ b/drivers/of/of_regulator.c
@@ -0,0 +1,85 @@
+/*
+ * OF helpers for regulator framework
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Rajendra Nayak <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, "min-uV", &(*init_data)->constraints.min_uV);
+ of_property_read_u32(np, "max-uV", &(*init_data)->constraints.max_uV);
+ of_property_read_u32(np, "uV-offset", &(*init_data)->constraints.uV_offset);
+ of_property_read_u32(np, "min-uA", &(*init_data)->constraints.min_uA);
+ of_property_read_u32(np, "max-uA", &(*init_data)->constraints.max_uA);
+
+ /* valid modes mask */
+ if (of_find_property(np, "mode-fast", NULL))
+ valid_modes_mask |= REGULATOR_MODE_FAST;
+ if (of_find_property(np, "mode-normal", NULL))
+ valid_modes_mask |= REGULATOR_MODE_NORMAL;
+ if (of_find_property(np, "mode-idle", NULL))
+ valid_modes_mask |= REGULATOR_MODE_IDLE;
+ if (of_find_property(np, "mode-standby", NULL))
+ valid_modes_mask |= REGULATOR_MODE_STANDBY;
+
+ /* valid ops mask */
+ if (of_find_property(np, "change-voltage", NULL))
+ valid_ops_mask |= REGULATOR_CHANGE_VOLTAGE;
+ if (of_find_property(np, "change-current", NULL))
+ valid_ops_mask |= REGULATOR_CHANGE_CURRENT;
+ if (of_find_property(np, "change-mode", NULL))
+ valid_ops_mask |= REGULATOR_CHANGE_MODE;
+ if (of_find_property(np, "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;
+
+ of_property_read_u32(np, "input-uV",
+ &(*init_data)->constraints.input_uV);
+ of_property_read_u32(np, "initial-mode",
+ &(*init_data)->constraints.initial_mode);
+
+ if (of_find_property(np, "always-on", NULL))
+ (*init_data)->constraints.always_on = true;
+ if (of_find_property(np, "boot-on", NULL))
+ (*init_data)->constraints.boot_on = true;
+ if (of_find_property(np, "apply-uV", NULL))
+ (*init_data)->constraints.apply_uV = true;
+}
+
+/**
+ * of_get_regulator_init_data - extarct regulator_init_data structure info
+ * @np: Pointer to regulator device tree node
+ *
+ * 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_node *np)
+{
+ struct regulator_init_data *init_data;
+
+ init_data = kzalloc(sizeof(struct regulator_init_data), GFP_KERNEL);
+ if (!init_data)
+ return NULL; /* Out of memory? */
+
+ init_data->supply_regulator = (char *)of_get_property(np,
+ "supply-regulator", NULL);
+ of_get_regulation_constraints(np, &init_data);
+ return init_data;
+}
+EXPORT_SYMBOL(of_get_regulator_init_data);
diff --git a/include/linux/of_regulator.h b/include/linux/of_regulator.h
new file mode 100644
index 0000000..5eb048c
--- /dev/null
+++ b/include/linux/of_regulator.h
@@ -0,0 +1,23 @@
+/*
+ * OpenFirmware regulator support routines
+ *
+ */
+
+#ifndef __LINUX_OF_REG_H
+#define __LINUX_OF_REG_H
+
+#include <linux/regulator/machine.h>
+
+#if defined(CONFIG_OF_REGULATOR)
+extern struct regulator_init_data
+ *of_get_regulator_init_data(struct device_node *np);
+#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
* [RFC PATCH 02/11] regulator: Fix error check in set_consumer_device_supply
From: Rajendra Nayak @ 2011-09-15 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-2-git-send-email-rnayak@ti.com>
The parameters to set_consumer_device_supply() can be considered
invalid (and hence it could return -EINVAL) if nether consumer_dev nor
consumer_dev_name are passed, not when *both* are passed.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
drivers/regulator/core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index d8e6a42..9365359 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -981,7 +981,7 @@ static int set_consumer_device_supply(struct regulator_dev *rdev,
struct regulator_map *node;
int has_dev;
- if (consumer_dev && consumer_dev_name)
+ if (!consumer_dev && !consumer_dev_name)
return -EINVAL;
if (!consumer_dev_name && consumer_dev)
--
1.7.1
^ permalink raw reply related
* [RFC PATCH 01/11] OMAP: TWL: Clean up mode and ops mask passed from board files
From: Rajendra Nayak @ 2011-09-15 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316085727-15023-1-git-send-email-rnayak@ti.com>
The TWL driver seems to set the default .valid_modes_mask to
(REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY) and .valid_ops_mask
to (REGULATOR_CHANGE_VOLTAGE | REGULATOR_CHANGE_MODE | REGULATOR_CHANGE_STATUS)
for all the registered regulators.
There is no need for all the board files to pass this information
additionally, when the driver already sets them by default.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/board-2430sdp.c | 5 --
arch/arm/mach-omap2/board-3430sdp.c | 30 --------------
arch/arm/mach-omap2/board-4430sdp.c | 10 -----
arch/arm/mach-omap2/board-cm-t35.c | 10 -----
arch/arm/mach-omap2/board-devkit8000.c | 13 ------
arch/arm/mach-omap2/board-igep0020.c | 11 -----
arch/arm/mach-omap2/board-ldp.c | 9 ----
arch/arm/mach-omap2/board-omap3beagle.c | 10 -----
arch/arm/mach-omap2/board-omap3evm.c | 14 -------
arch/arm/mach-omap2/board-omap3logic.c | 5 --
arch/arm/mach-omap2/board-omap3pandora.c | 26 ------------
arch/arm/mach-omap2/board-omap3stalker.c | 8 ----
arch/arm/mach-omap2/board-omap3touchbook.c | 10 -----
arch/arm/mach-omap2/board-overo.c | 5 --
arch/arm/mach-omap2/board-rm680.c | 4 --
arch/arm/mach-omap2/board-rx51-peripherals.c | 55 --------------------------
arch/arm/mach-omap2/board-zoom-peripherals.c | 14 -------
arch/arm/mach-omap2/twl-common.c | 44 --------------------
18 files changed, 0 insertions(+), 283 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
index 2028464..32154f4 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -156,11 +156,6 @@ static struct regulator_init_data sdp2430_vmmc1 = {
.constraints = {
.min_uV = 1850000,
.max_uV = 3150000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(sdp2430_vmmc1_supplies),
.consumer_supplies = &sdp2430_vmmc1_supplies[0],
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index bd600cf..01ce6df 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -306,10 +306,6 @@ static struct regulator_init_data sdp3430_vaux1 = {
.min_uV = 2800000,
.max_uV = 2800000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
};
@@ -319,10 +315,6 @@ static struct regulator_init_data sdp3430_vaux2 = {
.min_uV = 2800000,
.max_uV = 2800000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
};
@@ -332,10 +324,6 @@ static struct regulator_init_data sdp3430_vaux3 = {
.min_uV = 2800000,
.max_uV = 2800000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(sdp3430_vaux3_supplies),
.consumer_supplies = sdp3430_vaux3_supplies,
@@ -347,10 +335,6 @@ static struct regulator_init_data sdp3430_vaux4 = {
.min_uV = 1800000,
.max_uV = 1800000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
};
@@ -359,11 +343,6 @@ static struct regulator_init_data sdp3430_vmmc1 = {
.constraints = {
.min_uV = 1850000,
.max_uV = 3150000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(sdp3430_vmmc1_supplies),
.consumer_supplies = sdp3430_vmmc1_supplies,
@@ -375,10 +354,6 @@ static struct regulator_init_data sdp3430_vmmc2 = {
.min_uV = 1850000,
.max_uV = 1850000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(sdp3430_vmmc2_supplies),
.consumer_supplies = sdp3430_vmmc2_supplies,
@@ -389,11 +364,6 @@ static struct regulator_init_data sdp3430_vsim = {
.constraints = {
.min_uV = 1800000,
.max_uV = 3000000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(sdp3430_vsim_supplies),
.consumer_supplies = sdp3430_vsim_supplies,
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index c7cef44..acfbed0 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -511,11 +511,6 @@ static struct regulator_init_data sdp4430_vaux1 = {
.min_uV = 1000000,
.max_uV = 3000000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(sdp4430_vaux_supply),
.consumer_supplies = sdp4430_vaux_supply,
@@ -526,11 +521,6 @@ static struct regulator_init_data sdp4430_vusim = {
.min_uV = 1200000,
.max_uV = 2900000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
};
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index 3af8aab..e6e909d 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -348,11 +348,6 @@ static struct regulator_init_data cm_t35_vmmc1 = {
.constraints = {
.min_uV = 1850000,
.max_uV = 3150000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(cm_t35_vmmc1_supply),
.consumer_supplies = cm_t35_vmmc1_supply,
@@ -363,11 +358,6 @@ static struct regulator_init_data cm_t35_vsim = {
.constraints = {
.min_uV = 1800000,
.max_uV = 3000000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(cm_t35_vsim_supply),
.consumer_supplies = cm_t35_vsim_supply,
diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index b6002ec..7bfbe5f 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -275,11 +275,6 @@ static struct regulator_init_data devkit8000_vmmc1 = {
.constraints = {
.min_uV = 1850000,
.max_uV = 3150000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(devkit8000_vmmc1_supply),
.consumer_supplies = devkit8000_vmmc1_supply,
@@ -290,10 +285,6 @@ static struct regulator_init_data devkit8000_vpll1 = {
.constraints = {
.min_uV = 1800000,
.max_uV = 1800000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(devkit8000_vpll1_supplies),
.consumer_supplies = devkit8000_vpll1_supplies,
@@ -305,10 +296,6 @@ static struct regulator_init_data devkit8000_vio = {
.min_uV = 1800000,
.max_uV = 1800000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(devkit8000_vio_supply),
.consumer_supplies = devkit8000_vio_supply,
diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index 2521823..3e0c54c 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -231,11 +231,6 @@ static struct regulator_init_data igep_vmmc1 = {
.constraints = {
.min_uV = 1850000,
.max_uV = 3150000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(igep_vmmc1_supply),
.consumer_supplies = igep_vmmc1_supply,
@@ -250,11 +245,6 @@ static struct regulator_init_data igep_vio = {
.min_uV = 1800000,
.max_uV = 1800000,
.apply_uV = 1,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(igep_vio_supply),
.consumer_supplies = igep_vio_supply,
@@ -266,7 +256,6 @@ static struct regulator_consumer_supply igep_vmmc2_supply[] = {
static struct regulator_init_data igep_vmmc2 = {
.constraints = {
- .valid_modes_mask = REGULATOR_MODE_NORMAL,
.always_on = 1,
},
.num_consumer_supplies = ARRAY_SIZE(igep_vmmc2_supply),
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 218764c..8a81b92 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -214,11 +214,6 @@ static struct regulator_init_data ldp_vmmc1 = {
.constraints = {
.min_uV = 1850000,
.max_uV = 3150000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(ldp_vmmc1_supply),
.consumer_supplies = ldp_vmmc1_supply,
@@ -235,10 +230,6 @@ static struct regulator_init_data ldp_vaux1 = {
.min_uV = 3000000,
.max_uV = 3000000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(ldp_vaux1_supplies),
.consumer_supplies = ldp_vaux1_supplies,
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index a7923ca..0da3c9c 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -338,11 +338,6 @@ static struct regulator_init_data beagle_vmmc1 = {
.constraints = {
.min_uV = 1850000,
.max_uV = 3150000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(beagle_vmmc1_supply),
.consumer_supplies = beagle_vmmc1_supply,
@@ -353,11 +348,6 @@ static struct regulator_init_data beagle_vsim = {
.constraints = {
.min_uV = 1800000,
.max_uV = 3000000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(beagle_vsim_supply),
.consumer_supplies = beagle_vsim_supply,
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index c452b3f..f2508dc 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -286,11 +286,6 @@ static struct regulator_init_data omap3evm_vmmc1 = {
.constraints = {
.min_uV = 1850000,
.max_uV = 3150000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(omap3evm_vmmc1_supply),
.consumer_supplies = omap3evm_vmmc1_supply,
@@ -301,11 +296,6 @@ static struct regulator_init_data omap3evm_vsim = {
.constraints = {
.min_uV = 1800000,
.max_uV = 3000000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(omap3evm_vsim_supply),
.consumer_supplies = omap3evm_vsim_supply,
@@ -441,10 +431,6 @@ static struct regulator_init_data omap3evm_vio = {
.min_uV = 1800000,
.max_uV = 1800000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(omap3evm_vio_supply),
.consumer_supplies = omap3evm_vio_supply,
diff --git a/arch/arm/mach-omap2/board-omap3logic.c b/arch/arm/mach-omap2/board-omap3logic.c
index 703aeb5..90584e2 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -64,11 +64,6 @@ static struct regulator_init_data omap3logic_vmmc1 = {
.name = "VMMC1",
.min_uV = 1850000,
.max_uV = 3150000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(omap3logic_vmmc1_supply),
.consumer_supplies = omap3logic_vmmc1_supply,
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c
index 080d7bd..37638d3 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -362,11 +362,6 @@ static struct regulator_init_data pandora_vmmc1 = {
.constraints = {
.min_uV = 1850000,
.max_uV = 3150000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(pandora_vmmc1_supply),
.consumer_supplies = pandora_vmmc1_supply,
@@ -377,11 +372,6 @@ static struct regulator_init_data pandora_vmmc2 = {
.constraints = {
.min_uV = 1850000,
.max_uV = 3150000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(pandora_vmmc2_supply),
.consumer_supplies = pandora_vmmc2_supply,
@@ -393,10 +383,6 @@ static struct regulator_init_data pandora_vaux1 = {
.min_uV = 3000000,
.max_uV = 3000000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(pandora_vcc_lcd_supply),
.consumer_supplies = pandora_vcc_lcd_supply,
@@ -408,10 +394,6 @@ static struct regulator_init_data pandora_vaux2 = {
.min_uV = 1800000,
.max_uV = 1800000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(pandora_usb_phy_supply),
.consumer_supplies = pandora_usb_phy_supply,
@@ -423,10 +405,6 @@ static struct regulator_init_data pandora_vaux4 = {
.min_uV = 2800000,
.max_uV = 2800000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(pandora_vaux4_supplies),
.consumer_supplies = pandora_vaux4_supplies,
@@ -438,10 +416,6 @@ static struct regulator_init_data pandora_vsim = {
.min_uV = 2800000,
.max_uV = 2800000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(pandora_adac_supply),
.consumer_supplies = pandora_adac_supply,
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c
index 8e10498..92116f2 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -218,10 +218,6 @@ static struct regulator_init_data omap3stalker_vmmc1 = {
.constraints = {
.min_uV = 1850000,
.max_uV = 3150000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(omap3stalker_vmmc1_supply),
.consumer_supplies = omap3stalker_vmmc1_supply,
@@ -232,10 +228,6 @@ static struct regulator_init_data omap3stalker_vsim = {
.constraints = {
.min_uV = 1800000,
.max_uV = 3000000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(omap3stalker_vsim_supply),
.consumer_supplies = omap3stalker_vsim_supply,
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c b/arch/arm/mach-omap2/board-omap3touchbook.c
index 852ea04..d97dc67 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -181,11 +181,6 @@ static struct regulator_init_data touchbook_vmmc1 = {
.constraints = {
.min_uV = 1850000,
.max_uV = 3150000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(touchbook_vmmc1_supply),
.consumer_supplies = touchbook_vmmc1_supply,
@@ -196,11 +191,6 @@ static struct regulator_init_data touchbook_vsim = {
.constraints = {
.min_uV = 1800000,
.max_uV = 3000000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(touchbook_vsim_supply),
.consumer_supplies = touchbook_vsim_supply,
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index f0b8489..baee16b 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -428,11 +428,6 @@ static struct regulator_init_data overo_vmmc1 = {
.constraints = {
.min_uV = 1850000,
.max_uV = 3150000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(overo_vmmc1_supply),
.consumer_supplies = overo_vmmc1_supply,
diff --git a/arch/arm/mach-omap2/board-rm680.c b/arch/arm/mach-omap2/board-rm680.c
index 7dfed24..5015db7 100644
--- a/arch/arm/mach-omap2/board-rm680.c
+++ b/arch/arm/mach-omap2/board-rm680.c
@@ -41,10 +41,6 @@ static struct regulator_consumer_supply rm680_vemmc_consumers[] = {
static struct regulator_init_data rm680_vemmc = {
.constraints = {
.name = "rm680_vemmc",
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_STATUS
- | REGULATOR_CHANGE_MODE,
},
.num_consumer_supplies = ARRAY_SIZE(rm680_vemmc_consumers),
.consumer_supplies = rm680_vemmc_consumers,
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 5a886cd..498c8dd 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -464,10 +464,6 @@ static struct regulator_init_data rx51_vaux1 = {
.min_uV = 2800000,
.max_uV = 2800000,
.always_on = true, /* due battery cover sensor */
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(rx51_vaux1_consumers),
.consumer_supplies = rx51_vaux1_consumers,
@@ -478,10 +474,6 @@ static struct regulator_init_data rx51_vaux2 = {
.name = "VCSI",
.min_uV = 1800000,
.max_uV = 1800000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(rx51_vaux2_supply),
.consumer_supplies = rx51_vaux2_supply,
@@ -494,10 +486,6 @@ static struct regulator_init_data rx51_vaux3_cam = {
.min_uV = 1800000,
.max_uV = 1800000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
};
@@ -507,11 +495,6 @@ static struct regulator_init_data rx51_vaux3_mmc = {
.min_uV = 2800000,
.max_uV = 3000000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(rx51_vaux3_supply),
.consumer_supplies = rx51_vaux3_supply,
@@ -523,10 +506,6 @@ static struct regulator_init_data rx51_vaux4 = {
.min_uV = 2800000,
.max_uV = 2800000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
};
@@ -534,11 +513,6 @@ static struct regulator_init_data rx51_vmmc1 = {
.constraints = {
.min_uV = 1850000,
.max_uV = 3150000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(rx51_vmmc1_supply),
.consumer_supplies = rx51_vmmc1_supply,
@@ -551,11 +525,6 @@ static struct regulator_init_data rx51_vmmc2 = {
.max_uV = 3000000,
.always_on = true, /* due VIO leak to AIC34 VDDs */
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(rx51_vmmc2_supplies),
.consumer_supplies = rx51_vmmc2_supplies,
@@ -568,9 +537,6 @@ static struct regulator_init_data rx51_vpll1 = {
.max_uV = 1800000,
.apply_uV = true,
.always_on = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE,
},
};
@@ -581,9 +547,6 @@ static struct regulator_init_data rx51_vpll2 = {
.max_uV = 1800000,
.apply_uV = true,
.always_on = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE,
},
};
@@ -593,10 +556,6 @@ static struct regulator_init_data rx51_vsim = {
.min_uV = 1800000,
.max_uV = 1800000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(rx51_vsim_supply),
.consumer_supplies = rx51_vsim_supply,
@@ -606,11 +565,6 @@ static struct regulator_init_data rx51_vio = {
.constraints = {
.min_uV = 1800000,
.max_uV = 1800000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(rx51_vio_supplies),
.consumer_supplies = rx51_vio_supplies,
@@ -622,9 +576,6 @@ static struct regulator_init_data rx51_vintana1 = {
.min_uV = 1500000,
.max_uV = 1500000,
.always_on = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE,
},
};
@@ -635,9 +586,6 @@ static struct regulator_init_data rx51_vintana2 = {
.max_uV = 2750000,
.apply_uV = true,
.always_on = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE,
},
};
@@ -647,9 +595,6 @@ static struct regulator_init_data rx51_vintdig = {
.min_uV = 1500000,
.max_uV = 1500000,
.always_on = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE,
},
};
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6d0aa4f..58b5ad0 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -126,11 +126,6 @@ static struct regulator_init_data zoom_vmmc1 = {
.constraints = {
.min_uV = 1850000,
.max_uV = 3150000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(zoom_vmmc1_supply),
.consumer_supplies = zoom_vmmc1_supply,
@@ -142,10 +137,6 @@ static struct regulator_init_data zoom_vmmc2 = {
.min_uV = 1850000,
.max_uV = 1850000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(zoom_vmmc2_supply),
.consumer_supplies = zoom_vmmc2_supply,
@@ -156,11 +147,6 @@ static struct regulator_init_data zoom_vsim = {
.constraints = {
.min_uV = 1800000,
.max_uV = 3000000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(zoom_vsim_supply),
.consumer_supplies = zoom_vsim_supply,
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index daa056e..a1d4046 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -88,10 +88,6 @@ static struct regulator_init_data omap3_vdac_idata = {
.constraints = {
.min_uV = 1800000,
.max_uV = 1800000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(omap3_vdda_dac_supplies),
.consumer_supplies = omap3_vdda_dac_supplies,
@@ -106,10 +102,6 @@ static struct regulator_init_data omap3_vpll2_idata = {
.constraints = {
.min_uV = 1800000,
.max_uV = 1800000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(omap3_vpll2_supplies),
.consumer_supplies = omap3_vpll2_supplies,
@@ -158,10 +150,6 @@ static struct regulator_init_data omap4_vdac_idata = {
.constraints = {
.min_uV = 1800000,
.max_uV = 1800000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
};
@@ -170,11 +158,6 @@ static struct regulator_init_data omap4_vaux2_idata = {
.min_uV = 1200000,
.max_uV = 2800000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
};
@@ -183,11 +166,6 @@ static struct regulator_init_data omap4_vaux3_idata = {
.min_uV = 1000000,
.max_uV = 3000000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
};
@@ -201,11 +179,6 @@ static struct regulator_init_data omap4_vmmc_idata = {
.min_uV = 1200000,
.max_uV = 3000000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = ARRAY_SIZE(omap4_vmmc_supply),
.consumer_supplies = omap4_vmmc_supply,
@@ -216,11 +189,6 @@ static struct regulator_init_data omap4_vpp_idata = {
.min_uV = 1800000,
.max_uV = 2500000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
- | REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
};
@@ -228,10 +196,6 @@ static struct regulator_init_data omap4_vana_idata = {
.constraints = {
.min_uV = 2100000,
.max_uV = 2100000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
};
@@ -239,10 +203,6 @@ static struct regulator_init_data omap4_vcxio_idata = {
.constraints = {
.min_uV = 1800000,
.max_uV = 1800000,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
};
@@ -251,10 +211,6 @@ static struct regulator_init_data omap4_vusb_idata = {
.min_uV = 3300000,
.max_uV = 3300000,
.apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
},
};
--
1.7.1
^ permalink raw reply related
* [RFC PATCH 00/11] Device tree support for regulators
From: Rajendra Nayak @ 2011-09-15 11:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Grant, Mark,
This RFC is an attempt to move the regulator mappings from
board files into device tree for OMAP. In the process I have
defined some helper routines for regulators and defined
the bindings for these.
The patches are based on top of Benoit's series which adds
DT support for i2c and twl for OMAP from here
git://gitorious.org/omap-pm/linux.git for_3.2/5_omap_dt_i2c_twl
I know Benoit is planning a respin of the series soon, in which
he intends to register all twl child nodes as platform devices,
which would mean I just drop the last patch in this series.
The first couple of patches in the series are just fixes and
cleanups leading to the regulator DT migration.
The series is tested on OMAP4SDP and OMAP4PANDA boards.
regards,
Rajendra
Rajendra Nayak (11):
OMAP: TWL: Clean up mode and ops mask passed from board files
regulator: Fix error check in set_consumer_device_supply
DT: regulator: Helper routine to extract regulator_init_data
omap4: SDP: Pass regulator_init_data from DT
TWL: regulator: Make twl-regulator driver extract data from DT
DT: regulator: Helper routine to extract fixed_voltage_config
regulator: Make fixed regulator driver extract data from DT
omap4: panda: Pass fixed regulator data from DT
DT: regulator: Helper to extract regulator node based on supply name
regulator: Implement consumer regulator mapping from device tree
DT: regulator: register regulators as platform devices
.../devicetree/bindings/regulator/regulator.txt | 56 ++++++
.../bindings/regulator/twl-regulator.txt | 18 ++
arch/arm/boot/dts/omap4-panda.dts | 10 +
arch/arm/boot/dts/omap4-sdp.dts | 16 ++
arch/arm/mach-omap2/board-2430sdp.c | 5 -
arch/arm/mach-omap2/board-3430sdp.c | 30 ----
arch/arm/mach-omap2/board-4430sdp.c | 10 -
arch/arm/mach-omap2/board-cm-t35.c | 10 -
arch/arm/mach-omap2/board-devkit8000.c | 13 --
arch/arm/mach-omap2/board-igep0020.c | 11 --
arch/arm/mach-omap2/board-ldp.c | 9 -
arch/arm/mach-omap2/board-omap3beagle.c | 10 -
arch/arm/mach-omap2/board-omap3evm.c | 14 --
arch/arm/mach-omap2/board-omap3logic.c | 5 -
arch/arm/mach-omap2/board-omap3pandora.c | 26 ---
arch/arm/mach-omap2/board-omap3stalker.c | 8 -
arch/arm/mach-omap2/board-omap3touchbook.c | 10 -
arch/arm/mach-omap2/board-overo.c | 5 -
arch/arm/mach-omap2/board-rm680.c | 4 -
arch/arm/mach-omap2/board-rx51-peripherals.c | 55 ------
arch/arm/mach-omap2/board-zoom-peripherals.c | 14 --
arch/arm/mach-omap2/twl-common.c | 44 -----
drivers/mfd/twl-core.c | 3 +
drivers/of/Kconfig | 6 +
drivers/of/Makefile | 1 +
drivers/of/of_regulator.c | 183 ++++++++++++++++++++
drivers/regulator/core.c | 25 +++-
drivers/regulator/fixed.c | 20 ++-
drivers/regulator/twl-regulator.c | 28 +++-
include/linux/of_regulator.h | 42 +++++
include/linux/regulator/driver.h | 3 +
31 files changed, 406 insertions(+), 288 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
create mode 100644 Documentation/devicetree/bindings/regulator/twl-regulator.txt
create mode 100644 drivers/of/of_regulator.c
create mode 100644 include/linux/of_regulator.h
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Arnd Bergmann @ 2011-09-15 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316017900-19918-6-git-send-email-robherring2@gmail.com>
On Wednesday 14 September 2011, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> This adds gic initialization using device tree data. The initialization
> functions are intended to be called by a generic OF interrupt
> controller parsing function once the right pieces are in place.
>
> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> mask the PPI is assigned to.
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH 3/5] of/irq: introduce of_irq_init
From: Arnd Bergmann @ 2011-09-15 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316017900-19918-4-git-send-email-robherring2@gmail.com>
On Wednesday 14 September 2011, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> of_irq_init will scan the devicetree for matching interrupt controller
> nodes. Then it calls an initialization function for each found controller
> in the proper order with parent nodes initialized before child nodes.
>
> Based on initial pseudo code from Grant Likely.
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
Looks good to me,
Acked-by: Arnd Bergmann <arnd@arndb.de>
> +
> +struct intc_desc {
> + struct list_head list;
> + struct device_node *dev;
> + struct device_node *parent;
> +};
One tiny comment: how about naming the parent 'interrupt_parent'? While
reading through the code, I was confused for a short time until I figured
out what this is about.
Arnd
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Russell King - ARM Linux @ 2011-09-15 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E71CE5D.9030900@ti.com>
On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
> 32. Only the internal PPI are between 0 and 31.
SGIs are 0 to 15, PPIs are 16 to 31, and SPIs are 32+ - that's the
numbering given to us by the GIC.
> The real HW physical number start at 0, and thus this is that value that
> should be in the irq binding of the device.
That depends whether you're counting SPI number or whether you're counting
IRQ number in the GIC interfaces. SPI0 will be reported to us from the
GIC as 32, not 0, so to start numbering from 0 (which is already frowned
upon for many reasons) we'd have to subtract 32 after checking that the
IRQ is not a SGI nor PPI in the assembly code instead.
^ permalink raw reply
* READ THIS: the next mach-types update
From: Russell King - ARM Linux @ 2011-09-15 10:25 UTC (permalink / raw)
To: linux-arm-kernel
I'm going to be merging a mach-types update (the cut-down and the
policy-conforming version) for the next merge window. This will mean
that things WILL BREAK, and I will not notice that things have broken.
In order to fix this, entries need to be fixed to conform to the
requirements - where the machine_is_xxx() name is the same as the
MACH_TYPE_xxx name and the CONFIG_MACH_xxx name too.
Moreover, entries older than 12 months which have not been merged will
be removed. It is not possible to automatically check for machine_is_xxx()
usages as these could conflict with other architectures, and I'm
certainly NOT checking for them by hand (I estimate that'd take a
significant amount of manual effort to do.) What that means is that it
is _important_ to get the core platform support in _first_ before any
drivers which may make use of this.
The following will be deleted from the file this time around are:
-ts_x09 MACH_TS209 TS209 1565
-at572d940hfek MACH_AT572D940HFEB AT572D940HFEB 1783
-sheeva_esata MACH_ESATA_SHEEVAPLUG ESATA_SHEEVAPLUG 2678
-omap3_braillo MACH_OMAP3_BRAILLO OMAP3_BRAILLO 2839
-spyplug MACH_SPYPLUG SPYPLUG 2840
-ginger MACH_GINGER GINGER 2841
-tny_t3530 MACH_TNY_T3530 TNY_T3530 2842
-pca102 MACH_PCA102 PCA102 2843
-spade MACH_SPADE SPADE 2844
-mxc25_topaz MACH_MXC25_TOPAZ MXC25_TOPAZ 2845
-gw2361 MACH_GW2361 GW2361 2847
-elog MACH_ELOG ELOG 2848
-bcm589x MACH_BCM589X BCM589X 2850
-etna MACH_ETNA ETNA 2851
-hawks MACH_HAWKS HAWKS 2852
-meson MACH_MESON MESON 2853
-xsbase255 MACH_XSBASE255 XSBASE255 2854
-pvm2030 MACH_PVM2030 PVM2030 2855
-mioa502 MACH_MIOA502 MIOA502 2856
-htc_spv_m700 MACH_HTC_SPV_M700 HTC_SPV_M700 2860
-msm8x55_svlte_ffa MACH_MSM8X55_SVLTE_FFA MSM8X55_SVLTE_FFA 2863
-msm8x55_svlte_surf MACH_MSM8X55_SVLTE_SURF MSM8X55_SVLTE_SURF 2864
-quickstep MACH_QUICKSTEP QUICKSTEP 2865
-dmw96 MACH_DMW96 DMW96 2866
-hammerhead MACH_HAMMERHEAD HAMMERHEAD 2867
-trident MACH_TRIDENT TRIDENT 2868
-lightning MACH_LIGHTNING LIGHTNING 2869
-iconnect MACH_ICONNECT ICONNECT 2870
-autobot MACH_AUTOBOT AUTOBOT 2871
-coconut MACH_COCONUT COCONUT 2872
-durian MACH_DURIAN DURIAN 2873
-cayenne MACH_CAYENNE CAYENNE 2874
-fuji MACH_FUJI FUJI 2875
-synology_6282 MACH_SYNOLOGY_6282 SYNOLOGY_6282 2876
-em1sy MACH_EM1SY EM1SY 2877
-m502 MACH_M502 M502 2878
-matrix518 MACH_MATRIX518 MATRIX518 2879
-tiny_gurnard MACH_TINY_GURNARD TINY_GURNARD 2880
-spear1310 MACH_SPEAR1310 SPEAR1310 2881
-mxt_td61 MACH_MXT_TD61 MXT_TD61 2883
-devixp MACH_DEVIXP DEVIXP 2885
-miccpt MACH_MICCPT MICCPT 2886
-mic256 MACH_MIC256 MIC256 2887
-as1167 MACH_AS1167 AS1167 2888
-omap3_ibiza MACH_OMAP3_IBIZA OMAP3_IBIZA 2889
-davinci_picto MACH_DAVINCI_PICTO DAVINCI_PICTO 2891
-mecha MACH_MECHA MECHA 2892
-bubba3 MACH_BUBBA3 BUBBA3 2893
-pupitre MACH_PUPITRE PUPITRE 2894
-tegra_vogue MACH_TEGRA_VOGUE TEGRA_VOGUE 2896
-tegra_e1165 MACH_TEGRA_E1165 TEGRA_E1165 2897
-simplenet MACH_SIMPLENET SIMPLENET 2898
-ec4350tbm MACH_EC4350TBM EC4350TBM 2899
-pec_tc MACH_PEC_TC PEC_TC 2900
-pec_hc2 MACH_PEC_HC2 PEC_HC2 2901
-esl_mobilis_a MACH_ESL_MOBILIS_A ESL_MOBILIS_A 2902
-esl_mobilis_b MACH_ESL_MOBILIS_B ESL_MOBILIS_B 2903
-esl_wave_a MACH_ESL_WAVE_A ESL_WAVE_A 2904
-esl_wave_b MACH_ESL_WAVE_B ESL_WAVE_B 2905
-unisense_mmm MACH_UNISENSE_MMM UNISENSE_MMM 2906
-blueshark MACH_BLUESHARK BLUESHARK 2907
-e10 MACH_E10 E10 2908
-app3k_robin MACH_APP3K_ROBIN APP3K_ROBIN 2909
-pov15hd MACH_POV15HD POV15HD 2910
-stella MACH_STELLA STELLA 2911
-netwalker MACH_NETWALKER NETWALKER 2914
-acsx106 MACH_ACSX106 ACSX106 2915
-atlas5_c1 MACH_ATLAS5_C1 ATLAS5_C1 2916
-nsb3ast MACH_NSB3AST NSB3AST 2917
-gnet_slc MACH_GNET_SLC GNET_SLC 2918
-af4000 MACH_AF4000 AF4000 2919
-ark9431 MACH_ARK9431 ARK9431 2920
-fs_s5pc100 MACH_FS_S5PC100 FS_S5PC100 2921
-omap3505nova8 MACH_OMAP3505NOVA8 OMAP3505NOVA8 2922
-omap3621_edp1 MACH_OMAP3621_EDP1 OMAP3621_EDP1 2923
-oratisaes MACH_ORATISAES ORATISAES 2924
-siemens_l0 MACH_SIEMENS_L0 SIEMENS_L0 2926
-ventana MACH_VENTANA VENTANA 2927
-ec4350sdb MACH_EC4350SDB EC4350SDB 2929
-mimas MACH_MIMAS MIMAS 2930
-titan MACH_TITAN TITAN 2931
-es2440 MACH_ES2440 ES2440 2933
-najay_a9263 MACH_NAJAY_A9263 NAJAY_A9263 2934
-htctornado MACH_HTCTORNADO HTCTORNADO 2935
-dimm_mx257 MACH_DIMM_MX257 DIMM_MX257 2936
-jigen301 MACH_JIGEN JIGEN 2937
-meno_qng MACH_MENO_QNG MENO_QNG 2939
-ns2416 MACH_NS2416 NS2416 2940
-rpc353 MACH_RPC353 RPC353 2941
-tq6410 MACH_TQ6410 TQ6410 2942
-sky6410 MACH_SKY6410 SKY6410 2943
-dynasty MACH_DYNASTY DYNASTY 2944
-vivo MACH_VIVO VIVO 2945
-bury_bl7582 MACH_BURY_BL7582 BURY_BL7582 2946
-bury_bps5270 MACH_BURY_BPS5270 BURY_BPS5270 2947
-basi MACH_BASI BASI 2948
-tn200 MACH_TN200 TN200 2949
-c2mmi MACH_C2MMI C2MMI 2950
-meson_6236m MACH_MESON_6236M MESON_6236M 2951
-meson_8626m MACH_MESON_8626M MESON_8626M 2952
-tube MACH_TUBE TUBE 2953
-messina MACH_MESSINA MESSINA 2954
-mx50_arm2 MACH_MX50_ARM2 MX50_ARM2 2955
-cetus9263 MACH_CETUS9263 CETUS9263 2956
-vmx25 MACH_VMX25 VMX25 2958
-vmx51 MACH_VMX51 VMX51 2959
-abacus MACH_ABACUS ABACUS 2960
-cm4745 MACH_CM4745 CM4745 2961
-oratislink MACH_ORATISLINK ORATISLINK 2962
-davinci_dm365_dvr MACH_DAVINCI_DM365_DVR DAVINCI_DM365_DVR 2963
-netviz MACH_NETVIZ NETVIZ 2964
-wlan_computer MACH_WLAN_COMPUTER WLAN_COMPUTER 2966
-lpc24xx MACH_LPC24XX LPC24XX 2967
-spica MACH_SPICA SPICA 2968
-gpsdisplay MACH_GPSDISPLAY GPSDISPLAY 2969
-bipnet MACH_BIPNET BIPNET 2970
-overo_ctu_inertial MACH_OVERO_CTU_INERTIAL OVERO_CTU_INERTIAL 2971
-davinci_dm355_mmm MACH_DAVINCI_DM355_MMM DAVINCI_DM355_MMM 2972
-pc9260_v2 MACH_PC9260_V2 PC9260_V2 2973
-ptx7545 MACH_PTX7545 PTX7545 2974
-tm_efdc MACH_TM_EFDC TM_EFDC 2975
-omap3_waldo1 MACH_OMAP3_WALDO1 OMAP3_WALDO1 2977
-flyer MACH_FLYER FLYER 2978
-tornado3240 MACH_TORNADO3240 TORNADO3240 2979
-soli_01 MACH_SOLI_01 SOLI_01 2980
-omapl138_europalc MACH_OMAPL138_EUROPALC OMAPL138_EUROPALC 2981
-helios_v1 MACH_HELIOS_V1 HELIOS_V1 2982
-netspace_lite_v2 MACH_NETSPACE_LITE_V2 NETSPACE_LITE_V2 2983
-ssc MACH_SSC SSC 2984
-premierwave_en MACH_PREMIERWAVE_EN PREMIERWAVE_EN 2985
-wasabi MACH_WASABI WASABI 2986
-spx_sakura MACH_SPX_SAKURA SPX_SAKURA 2991
-ij3k_2440 MACH_IJ3K_2440 IJ3K_2440 2992
-omap3_bc10 MACH_OMAP3_BC10 OMAP3_BC10 2993
-thebe MACH_THEBE THEBE 2994
-rv082 MACH_RV082 RV082 2995
-armlguest MACH_ARMLGUEST ARMLGUEST 2996
-tjinc1000 MACH_TJINC1000 TJINC1000 2997
-ax8008 MACH_AX8008 AX8008 2999
-gnet_sgce MACH_GNET_SGCE GNET_SGCE 3000
-pxwnas_500_1000 MACH_PXWNAS_500_1000 PXWNAS_500_1000 3001
-ea20 MACH_EA20 EA20 3002
-awm2 MACH_AWM2 AWM2 3003
-ti8148evm MACH_TI8148EVM TI8148EVM 3004
-linkstation_chlv2 MACH_LINKSTATION_CHLV2 LINKSTATION_CHLV2 3006
-tera_pro2_rack MACH_TERA_PRO2_RACK TERA_PRO2_RACK 3007
-rubys MACH_RUBYS RUBYS 3008
-aquarius MACH_AQUARIUS AQUARIUS 3009
-lswxl MACH_LSWXL LSWXL 3012
-dove_avng_v3 MACH_DOVE_AVNG_V3 DOVE_AVNG_V3 3013
-sdi_ess_9263 MACH_SDI_ESS_9263 SDI_ESS_9263 3014
-jocpu550 MACH_JOCPU550 JOCPU550 3015
-yanomami MACH_YANOMAMI YANOMAMI 3018
-gta04 MACH_GTA04 GTA04 3019
-omap3_rfs200 MACH_OMAP3_RFS200 OMAP3_RFS200 3021
-kx33xx MACH_KX33XX KX33XX 3022
-ptx7510 MACH_PTX7510 PTX7510 3023
-top9000 MACH_TOP9000 TOP9000 3024
-teenote MACH_TEENOTE TEENOTE 3025
-ts3 MACH_TS3 TS3 3026
-a0 MACH_A0 A0 3027
-fsm9xxx_surf MACH_FSM9XXX_SURF FSM9XXX_SURF 3028
-fsm9xxx_ffa MACH_FSM9XXX_FFA FSM9XXX_FFA 3029
-frrhwcdma60w MACH_FRRHWCDMA60W FRRHWCDMA60W 3030
-remus MACH_REMUS REMUS 3031
-at91cap7xdk MACH_AT91CAP7XDK AT91CAP7XDK 3032
-at91cap7stk MACH_AT91CAP7STK AT91CAP7STK 3033
-kt_sbc_sam9_1 MACH_KT_SBC_SAM9_1 KT_SBC_SAM9_1 3034
-armada_xp_db MACH_ARMADA_XP_DB ARMADA_XP_DB 3036
-spdm MACH_SPDM SPDM 3037
-gtib MACH_GTIB GTIB 3038
-dgm3240 MACH_DGM3240 DGM3240 3039
-htcmega MACH_HTCMEGA HTCMEGA 3041
-tricorder MACH_TRICORDER TRICORDER 3042
-bstbrd MACH_BSTBRD BSTBRD 3044
-pwb3090 MACH_PWB3090 PWB3090 3045
-idea6410 MACH_IDEA6410 IDEA6410 3046
-qbc9263 MACH_QBC9263 QBC9263 3047
-borabora MACH_BORABORA BORABORA 3048
-valdez MACH_VALDEZ VALDEZ 3049
-ls9g20 MACH_LS9G20 LS9G20 3050
-mios_v1 MACH_MIOS_V1 MIOS_V1 3051
-s5pc110_crespo MACH_S5PC110_CRESPO S5PC110_CRESPO 3052
-controltek9g20 MACH_CONTROLTEK9G20 CONTROLTEK9G20 3053
-tin307 MACH_TIN307 TIN307 3054
-tin510 MACH_TIN510 TIN510 3055
-bluecheese MACH_BLUECHEESE BLUECHEESE 3057
-tem3x30 MACH_TEM3X30 TEM3X30 3058
-harvest_desoto MACH_HARVEST_DESOTO HARVEST_DESOTO 3059
-msm8x60_qrdc MACH_MSM8X60_QRDC MSM8X60_QRDC 3060
-spear900 MACH_SPEAR900 SPEAR900 3061
-rdstor MACH_RDSTOR RDSTOR 3063
-usdloader MACH_USDLOADER USDLOADER 3064
-tsoploader MACH_TSOPLOADER TSOPLOADER 3065
-kronos MACH_KRONOS KRONOS 3066
-ffcore MACH_FFCORE FFCORE 3067
-mone MACH_MONE MONE 3068
-unit2s MACH_UNIT2S UNIT2S 3069
-acer_a5 MACH_ACER_A5 ACER_A5 3070
-etherpro_isp MACH_ETHERPRO_ISP ETHERPRO_ISP 3071
-stretchs7000 MACH_STRETCHS7000 STRETCHS7000 3072
-p87_smartsim MACH_P87_SMARTSIM P87_SMARTSIM 3073
-tulip MACH_TULIP TULIP 3074
-sunflower MACH_SUNFLOWER SUNFLOWER 3075
-rib MACH_RIB RIB 3076
-clod MACH_CLOD CLOD 3077
-rump MACH_RUMP RUMP 3078
-tenderloin MACH_TENDERLOIN TENDERLOIN 3079
-shortloin MACH_SHORTLOIN SHORTLOIN 3080
-sc575hmi MACH_SC575IPC SC575IPC 3191
-dma_6410 MACH_DMA6410 DMA6410 3316
-pgs_v1 MACH_PGS_SITARA PGS_SITARA 3322
-sdh001 MACH_MACH_SDH001 MACH_SDH001 3390
-msm8960_mdp MACH_MSM8960_MDP MSM8960_MDP 3397
That's 214 entries being removed (and no, I'm NOT going to look up who
to contact about each one.)
The following will be deleted from the machine database:
tegra MACH_TEGRA TEGRA 3738
as it doesn't conform to the policy of this being a _platform_ database
not a _soc_ database.
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Cousson, Benoit @ 2011-09-15 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuYYwSFu2HC+u2NY41+yw9tEyy85RKa4Dpm3SL+jbwS_OOA0A@mail.gmail.com>
Hi Rob,
On 9/15/2011 9:55 AM, Thomas Abraham wrote:
> Hi Rob,
>
> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com> wrote:
>> From: Rob Herring<rob.herring@calxeda.com>
>>
>> This adds gic initialization using device tree data. The initialization
>> functions are intended to be called by a generic OF interrupt
>> controller parsing function once the right pieces are in place.
>>
>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>> mask the PPI is assigned to.
>>
>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>> ---
>> Documentation/devicetree/bindings/arm/gic.txt | 53 ++++++++++++++++++++++++
>> arch/arm/common/gic.c | 55 +++++++++++++++++++++++--
>> arch/arm/include/asm/hardware/gic.h | 10 +++++
>> 3 files changed, 114 insertions(+), 4 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>
> [...]
>
>
>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>> index d1ccc72..14de380 100644
>> --- a/arch/arm/common/gic.c
>> +++ b/arch/arm/common/gic.c
>
> [...]
>
>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>> +{
>> + void __iomem *cpu_base;
>> + void __iomem *dist_base;
>> + int irq;
>> + struct irq_domain *domain =&gic_data[gic_cnt].domain;
>> +
>> + if (WARN_ON(!node))
>> + return;
>> +
>> + dist_base = of_iomap(node, 0);
>> + WARN(!dist_base, "unable to map gic dist registers\n");
>> +
>> + cpu_base = of_iomap(node, 1);
>> + WARN(!cpu_base, "unable to map gic cpu registers\n");
>> +
>> + domain->nr_irq = gic_irq_count(dist_base);
>> + domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
>
> For exynos4, all the interrupts originating from GIC are statically
> mapped to start from 32 in the linux virq space (GIC SPI interrupts
> start from 64). In the above code, since irq_base would be 0 for
> exynos4, the interrupt mapping is not working correctly. In your
> previous version of the patch, you have given a option to the platform
> code to choose the offset. Could that option be added to this series
> also. Or a provision to use platform specific translate function
> instead of the irq_domain_simple translator.
I have another concern on a similar topic.
On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
32. Only the internal PPI are between 0 and 31.
For the moment we add 32 to every SoC interrupts in the irq.h define,
but I'm assuming that this offset calculation should be done thanks to a
dedicated irq domain for the SPI.
The real HW physical number start at 0, and thus this is that value that
should be in the irq binding of the device.
So ideally we should have a irq domain for the PPI starting at 0 and
another one for the SPI starting at 32. Or 32 and 64 for the exynos4
case, but it looks like the PPI/SPI offset is always 32.
Regards,
Benoit
^ permalink raw reply
* [PATCH v12 0/3] add the GPMI controller driver for IMX23/IMX28
From: Huang Shijie @ 2011-09-15 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20081.44941.12535.496764@ipc1.ka-ro>
Hi,
> Hi,
>
> Huang Shijie writes:
>> The patch set is based on Artem's tree:
>> http://git.infradead.org/users/dedekind/l2-mtd-2.6.git
>>
>> The general-purpose media interface(GPMI) controller is a flexible interface
>> to up to several NAND flashs.
>>
>> The Bose Ray-Choudhury Hocquenghem(BCH) module is a hardware ECC accelerator.
>>
>> With the help of BCH, the GPMI controller can choose to do the hardware ECC or
>> not.
>>
>> This driver is a _pure_ MTD NAND controller driver now.
>>
>>
>> The driver depends on another GPMI-NAND device patch set, you can find them at :
>> [1] http://marc.info/?l=linux-arm-kernel&m=131416901319573&w=2
>> [2] http://marc.info/?l=linux-arm-kernel&m=131416912319668&w=2
>> [3] http://marc.info/?l=linux-arm-kernel&m=131416891119504&w=2
>> [4] http://marc.info/?l=linux-arm-kernel&m=131416896219539&w=2
>>
>> Test environment:
>> Using imx23 and imx28 boards for test.
>>
>> imx23 :
>> console=ttyAMA0,115200 mtdparts=gpmi-nfc:20m(boot),-(user)
>> Tested by USB boot and NAND boot.
>>
>> imx28 :
>> #console=ttyAMA0,115200 root=/dev/mmcblk0p3 rw rootwait
>> Tested by SD card boot mode.
>>
> How did you perform your tests?
>
> I tried this driver on our TX28 board with the result that with
> concurrent access of the SD card and the NAND flash, I still get the
> dreaded DMA timeouts within seconds:
> DMA timeout, last DMA :1
> GPMI regs:
> HW_GPMI_CTRL0[000]=21800001
> HW_GPMI_COMPARE[010]=00000000
> HW_GPMI_ECCCTRL[020]=00000000
> HW_GPMI_ECCCOUNT[030]=00000840
> HW_GPMI_PAYLOAD[040]=46578000
> HW_GPMI_AUXILIARY[050]=46578800
> HW_GPMI_CTRL1[060]=0004000c
> HW_GPMI_TIMING0[070]=00010203
> HW_GPMI_TIMING1[080]=05000000
> HW_GPMI_TIMING2[090]=09020101
> HW_GPMI_STAT[0b0]=0d000003
> HW_GPMI_DEBUG[0c0]=01000000
> BCH regs:
> HW_BCH_CTRL[000]=00000100
> HW_BCH_STATUS0[010]=00000010
> HW_BCH_MODE[020]=00000000
> HW_BCH_ENCODEPTR[030]=00000000
> HW_BCH_DATAPTR[040]=00000000
> HW_BCH_METAPTR[050]=00000000
> HW_BCH_LAYOUTSELECT[070]=00000000
> HW_BCH_FLASH0LAYOUT0[080]=030a4200
> HW_BCH_FLASH0LAYOUT1[090]=08404200
> HW_BCH_DEBUG0[100]=00000000
> DMA regs:
> HW_APBHX_CTRL0[000]=30000000
> HW_APBHX_CTRL1[010]=ffff0000
> HW_APBHX_CTRL2[020]=00000000
> HW_APBHX_CHANNEL_CTRL[030]=00000000
> HW_APBHX_CHn_CURCMDAR(0)[100]=46e1c000
> HW_APBHX_CHn_NXTCMDAR(0)[110]=46e1c04c
> HW_APBHX_CHn_CMD(0)[120]=000001c8
> HW_APBHX_CHn_BAR(0)[130]=00000000
> HW_APBHX_CHn_SEMA(0)[140]=00000000
> HW_APBHX_CHn_DEBUG1(0)[150]=00a0001e
> HW_APBHX_CHn_DEBUG2(0)[160]=00000000
> HW_APBHX_CHn_CURCMDAR(4)[2c0]=4652c098
> HW_APBHX_CHn_NXTCMDAR(4)[2d0]=4652c0e4
> HW_APBHX_CHn_CMD(4)[2e0]=000001c9
> HW_APBHX_CHn_BAR(4)[2f0]=46553241
> HW_APBHX_CHn_SEMA(4)[300]=00010000
> HW_APBHX_CHn_DEBUG1(4)[310]=27a00015
> HW_APBHX_CHn_DEBUG2(4)[320]=00000000
> BCH Geometry :
> GF length : 13
> ECC Strength : 8
> Page Size in Bytes : 2112
> Metadata Size in Bytes : 10
> ECC Chunk Size in Bytes: 512
> ECC Chunk Count : 4
> Payload Size in Bytes : 2048
> Auxiliary Size in Bytes: 16
> Auxiliary Status Offset: 12
> Block Mark Byte Offset : 1999
> Block Mark Bit Offset : 0
>
> I'm doing a:
> dd if=/dev/mtd0> /dev/null& dd if=/dev/mmcblk0> /dev/null
> Sometimes the 'dd' accessing the SD card will stall indefinitely.
> Also copying data from SD card to flash will produce the error, though
> less likely.
>
it reproduces in my side too.
> This looks like the problem arises in the DMA driver when multiple
anyway, I will debug it.
but i will on vacation next week.
I am not sure I can fix it tomorrow.
Best Regards
Huang Shijie
> channels are being used concurrently. The GPMI driver will bail out
> with the timeout error while the MMC driver obviously has no timeout
> check for this situation.
>
> I can mostly rule out HW problems, because the same board works
> perfectly well with WindowsCE (tested with a copy operation between
> flash and SD card).
>
>
> Lothar Wa?mann
^ permalink raw reply
* [GIT PULL] Samsung Fixes for v3.1-rc7
From: Kukjin Kim @ 2011-09-15 9:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd :)
This is Samsung fixes for v3.1
Please pull from:
git://github.com/kgene/linux-samsung.git samsung-fixes-2
As you know, git.kernel.org/master.kernel.org has been down so I use
temporary git repo. at github now.
These things are needed for v3.1 and if any problems, please let me know.
As a note, others for v3.2 will be sent in the next week...
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb:
Linux 3.1-rc6 (2011-09-12 14:02:02 -0700)
are available in the git repository at:
git://github.com/kgene/linux-samsung.git samsung-fixes-2
Banajit Goswami (1):
ARM: S3C64XX: Remove un-used code backlight code on SMDK6410
Changhwan Youn (1):
ARM: EXYNOS4: restart clocksource while system resumes
Jonghwan Choi (1):
ARM: EXYNOS4: Fix wrong pll type for vpll
Kukjin Kim (3):
ARM: EXYNOS4: Fix return type of local_timer_setup()
ARM: EXYNOS4: Fix routing timer interrupt to offline CPU
ARM: SAMSUNG: fix to prevent declaring duplicated
Marek Szyprowski (1):
ARM: SAMSUNG: fix watchdog reset issue with clk_get()
Thomas Abraham (1):
ARM: EXYNOS4: fix incorrect pad configuration for keypad row lines
arch/arm/mach-exynos4/clock.c | 2 +-
arch/arm/mach-exynos4/mct.c | 10 +++++-
arch/arm/mach-exynos4/platsmp.c | 2 +
arch/arm/mach-exynos4/setup-keypad.c | 11 +++---
arch/arm/mach-s3c64xx/mach-smdk6410.c | 39
--------------------
arch/arm/plat-samsung/clock.c | 11 ++++++
arch/arm/plat-samsung/include/plat/clock.h | 8 ++++
.../arm/plat-samsung/include/plat/watchdog-reset.h | 10 ++----
8 files changed, 40 insertions(+), 53 deletions(-)
^ permalink raw reply
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
From: Cousson, Benoit @ 2011-09-15 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E70E2DE.2030006@ti.com>
Hi Santosh,
On 9/14/2011 7:22 PM, Shilimkar, Santosh wrote:
> On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote:
>> * Santosh<santosh.shilimkar@ti.com> [110914 09:40]:
>>> On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
>>>> * Santosh<santosh.shilimkar@ti.com> [110914 09:16]:
>>>>
>>>> Thanks for the clarification. It seems to me the spec is most likely
>>>> wrong as we've had the GIC working for over two years now without
>>>> doing anything with the wakeup gen registers :)
>>>>
>>> It's working because CPU clockdomain are never put under HW
>>> supervised mode and they are kept in force wakeup. Clock-domain
>>> never idles on mainline code. PM series will put the clock-domains
>>> under HW supervison as needed to achieve any low power states and
>>> then all sorts of corner cases will come out.
>>
>> But again the wakeup gen triggers only do something when hitting
>> idle. There should be no use for them during runtime, right?
>>
> You missed my point in the description. Clockdomain inactive
> doesn't depend on idle or WFI execution. Under HW supervison
> CPU clock domain can get into inactive when CPU is stalled and
> waiting for a read response from slow interconnect.
I'm a little bit confused by that statement...
I'm wondering how the PRCM can gate the CPU/MPU clock and re-enable it
if the MPU is gated? What kind of event can wakeup the CPU in case of
CPU stalled?
The spec seems to indicate that wakeupgen is needed only if CPU are in
WFI. It is even written: "CPUx will change power state only when
StandbyWFI is asserted.". Even a WFE is not supposed to trigger a standby.
How can the CPU be inactive at clock domain level without a WFI?
Regards,
Benoit
^ permalink raw reply
* [PATCH v12 0/3] add the GPMI controller driver for IMX23/IMX28
From: Huang Shijie @ 2011-09-15 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20081.49563.934890.760378@ipc1.ka-ro>
Hi,
> Hi,
>
> Huang Shijie writes:
>> Hi,
>> add more CC.
>>> Hi,
>>>
>>> Huang Shijie writes:
>>>> The patch set is based on Artem's tree:
>>>> http://git.infradead.org/users/dedekind/l2-mtd-2.6.git
>>>>
>>>> The general-purpose media interface(GPMI) controller is a flexible interface
>>>> to up to several NAND flashs.
>>>>
>>>> The Bose Ray-Choudhury Hocquenghem(BCH) module is a hardware ECC accelerator.
>>>>
>>>> With the help of BCH, the GPMI controller can choose to do the hardware ECC or
>>>> not.
>>>>
>>>> This driver is a _pure_ MTD NAND controller driver now.
>>>>
>>>>
>>>> The driver depends on another GPMI-NAND device patch set, you can find them at :
>>>> [1] http://marc.info/?l=linux-arm-kernel&m=131416901319573&w=2
>>>> [2] http://marc.info/?l=linux-arm-kernel&m=131416912319668&w=2
>>>> [3] http://marc.info/?l=linux-arm-kernel&m=131416891119504&w=2
>>>> [4] http://marc.info/?l=linux-arm-kernel&m=131416896219539&w=2
>>>>
>>>> Test environment:
>>>> Using imx23 and imx28 boards for test.
>>>>
>>>> imx23 :
>>>> console=ttyAMA0,115200 mtdparts=gpmi-nfc:20m(boot),-(user)
>>>> Tested by USB boot and NAND boot.
>>>>
>>>> imx28 :
>>>> #console=ttyAMA0,115200 root=/dev/mmcblk0p3 rw rootwait
>>>> Tested by SD card boot mode.
>>>>
>>> How did you perform your tests?
>>>
>>> I tried this driver on our TX28 board with the result that with
>> The nand conflicats with SD card1. You will get the DMA timeout if you
>> use it.
>> Do you use sd card0 or sd card1?
>>
> I'm using the SSP0 port.
>
ok.
>> BTW:I tested the gpmi driver with SD card0. It works fine.
>>
> What exactly did you do in your test?
I tested it with bonnie++.
> Can you try the concurrent 'dd' commands that I used?
not yet.
I will test it right now.
Huang Shijie
>
> Lothar Wa?mann
^ permalink raw reply
* [PATCH v12 0/3] add the GPMI controller driver for IMX23/IMX28
From: Lothar Waßmann @ 2011-09-15 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E71B741.7010907@freescale.com>
Hi,
Huang Shijie writes:
> Hi,
> add more CC.
> > Hi,
> >
> > Huang Shijie writes:
> >> The patch set is based on Artem's tree:
> >> http://git.infradead.org/users/dedekind/l2-mtd-2.6.git
> >>
> >> The general-purpose media interface(GPMI) controller is a flexible interface
> >> to up to several NAND flashs.
> >>
> >> The Bose Ray-Choudhury Hocquenghem(BCH) module is a hardware ECC accelerator.
> >>
> >> With the help of BCH, the GPMI controller can choose to do the hardware ECC or
> >> not.
> >>
> >> This driver is a _pure_ MTD NAND controller driver now.
> >>
> >>
> >> The driver depends on another GPMI-NAND device patch set, you can find them at :
> >> [1] http://marc.info/?l=linux-arm-kernel&m=131416901319573&w=2
> >> [2] http://marc.info/?l=linux-arm-kernel&m=131416912319668&w=2
> >> [3] http://marc.info/?l=linux-arm-kernel&m=131416891119504&w=2
> >> [4] http://marc.info/?l=linux-arm-kernel&m=131416896219539&w=2
> >>
> >> Test environment:
> >> Using imx23 and imx28 boards for test.
> >>
> >> imx23 :
> >> console=ttyAMA0,115200 mtdparts=gpmi-nfc:20m(boot),-(user)
> >> Tested by USB boot and NAND boot.
> >>
> >> imx28 :
> >> #console=ttyAMA0,115200 root=/dev/mmcblk0p3 rw rootwait
> >> Tested by SD card boot mode.
> >>
> > How did you perform your tests?
> >
> > I tried this driver on our TX28 board with the result that with
> The nand conflicats with SD card1. You will get the DMA timeout if you
> use it.
> Do you use sd card0 or sd card1?
>
I'm using the SSP0 port.
> BTW:I tested the gpmi driver with SD card0. It works fine.
>
What exactly did you do in your test?
Can you try the concurrent 'dd' commands that I used?
Lothar Wa?mann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [PATCH 0/5] GIC OF bindings
From: Jamie Iles @ 2011-09-15 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316017900-19918-1-git-send-email-robherring2@gmail.com>
On Wed, Sep 14, 2011 at 11:31:35AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> This series introduces of_irq_init to scan the device tree for interrupt
> controller nodes and call their init functions in proper order. The GIC
> init function is then called from this function. The platform code then
> looks something like this:
>
> const static struct of_device_id irq_match[] = {
> { .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
> {}
> };
>
> static void __init highbank_init_irq(void)
> {
> of_irq_init(irq_match);
> }
>
> The binding for GIC PPIs is now done with a 3rd interrupt cell to specify
> a cpu mask for which cpu the PPI is connected to. This was discussed at LPC
> and suggested by Grant.
>
> I dropped the public intc_desc struct. The the interrupt controller's node
> and the interrupt parent's node are passed in directly to the controller's
> init function. The linux irq assignment is now done dynamically using
> irq_alloc_descs.
Hi Rob,
This looks really nicely implemented to me.
Reviewed-by: Jamie Iles <jamie@jamieiles.com>
Jamie
^ permalink raw reply
* [PATCH v2 0/4] S3C2416: Enable IIS and HSSPI clocks
From: Kukjin Kim @ 2011-09-15 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109150921.34406.heiko@sntech.de>
Heiko St?bner wrote:
>
> Am Sonntag, 28. August 2011, 20:06:31 schrieb Heiko St?bner:
> > S3C2416/2450 (probably S3C2443 too) can use the newer style
> > kernel-drivers made for S3C64xx and above for their I2S and
> > HS-SPI controllers.
> >
> > So as a first step in this direction, these patches add their
> > respective clocks.
> ping? Any comments?
>
Hi Heiko,
Sorry for late response...came back from Korean traditional holiday :)
I will be back on this in this weekend.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver
From: Mohammed, Afzal @ 2011-09-15 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAC83ZvJgPYb3JbWT4SKXpQvq-vdKK4b6hd6E-ik5uyRCqgwWsg@mail.gmail.com>
Hi Tony,
On Thu, Sep 15, 2011 at 11:12:53, DebBarma, Tarun Kanti wrote:
> On Thu, Sep 15, 2011 at 3:15 AM, Tony Lindgren <tony@atomide.com> wrote:
> > * Tarun Kanti DebBarma <tarun.kanti@ti.com> [110908 13:36]:
> >> removed from timer code. New set of timers present on
> >> OMAP4 are now supported.
> > Also, as we don't need the support for different register offsets for
> > the first two omap4 timers, please rather implement support for the
> > new timers and the timeouts directly in plat-omap/dmtimer.c.
> >
> > That way we can still keep the minimal timer support simple for
> > clocksource and clockevent. Of course this means that we'll be only
> > supporting the first two timers as system timers on omap4, but that's
> > fine.
> Ok, I can make the change!
> But, do we have to keep OMAP5 in mind right now where even timers[1,2] require addition of offsets?
We need clocksource & clockevent to be able to work with
timers requiring addition of offsets. Without this AM335X,
TI816X and TI814X SoC's will not boot.
Regards
Afzal
^ permalink raw reply
* [PATCHv2 0/3] Initial support for Picochip picoxcell
From: Jamie Iles @ 2011-09-15 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1314196906-20709-1-git-send-email-jamie@jamieiles.com>
On Wed, Aug 24, 2011 at 03:41:43PM +0100, Jamie Iles wrote:
> This series adds support for Picochip picoXcell (PC3X2 and PC3X3)
> ARM1176JZ-S based devices. This is a device tree only platform and
> currently supports interrupt controllers and UARTs.
>
> This series is based off of Grant's devicetree/test branch and also uses
> Russell's io and gpio cleanup patches to remove the definition of
> IO_SPACE_LIMIT and trivial gpio definitions.
>
> Changes since v1:
>
> - Cleanup empty headers
> - Use of_platform_populate() and the default match table
> - Split the VIC's into separate device nodes
ping?
Jamie
^ permalink raw reply
* [PATCH v2 0/2] make reinitialization of ARM core components possible
From: Russell King - ARM Linux @ 2011-09-15 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915015338.GF1488@S2100-06.ap.freescale.net>
On Thu, Sep 15, 2011 at 09:53:39AM +0800, Shawn Guo wrote:
> The re-init approach calls the exactly same function used for the
> initial init during resume. So if this is a problem, it's the problem
> of initial init. The initial init code should initialize the L2 into
> a known state with "values" rather than "mask + values" method.
That may not be possible - the kernel may have no knowledge of the correct
settings for the number of ways and cacheline size etc for the platform.
It may be that these settings have been configured by the secure monitor
rather than the boot loader.
I couldn't tell you what the correct settings would be for Versatile
Express for instance, and I bet that the correct settings are a function
of the FPGA images loaded onto the board.
^ permalink raw reply
* [PATCH] arm: sched_clock: Enable HAVE_SCHED_CLOCK support without init_sched_clock
From: Kyungmin Park @ 2011-09-15 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915082024.GF6267@n2100.arm.linux.org.uk>
On Thu, Sep 15, 2011 at 5:20 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Sep 15, 2011 at 04:35:12PM +0900, Kyungmin Park wrote:
>> From: Kyungmin Park <kyungmin.park@samsung.com>
>>
>> On Samsung Exynos4 series, EVT0 chip uses the s5p_timer with HAVE_SCHED_CLOCK and remains use the MCT timer without init_sched_clock.
>
> So in other words, sched_clock on exynos4 is broken because the update
> function won't be called, and it'll wrap well below the 64-bit ns range
> required of it.
Right, even though MCT doesn't use the HAVE_SCHED_CLOCK, sched_clock
is override with others.
It mean it should be implement the sched_clock for all boards if there
are some boards use the HAVE_SCHED_CLOCK.
As I remember, there's attempt to solve the sched_clock registration
issue. I'll check it.
Thank you,
Kyungmin Park
>
> NAK.
>
^ permalink raw reply
* [PATCH v2 1/2] ARM: cache-l2x0: remove __init annotation from initialization functions
From: Russell King - ARM Linux @ 2011-09-15 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915013937.GE1488@S2100-06.ap.freescale.net>
On Thu, Sep 15, 2011 at 09:39:39AM +0800, Shawn Guo wrote:
> On Wed, Sep 14, 2011 at 09:42:38AM +0100, Russell King - ARM Linux wrote:
> > I'm unconvinced about the wise-ness of this. We read-modify-write the
> > auxillary control register, which means some bits are preserved from
> > the initial boot. If the boot loader sets the L2 cache up for normal
> > boot and not for resume, we'll end up with different L2 cache settings.
> >
> > We've historically seen this kind of thing with boot loaders over the
> > years, to the point where systems boot at one CPU clock rate but resume
> > at some other CPU clock rate.
> >
> I would think this is a problem in the kernel. Kernel initialization
> code should put all these stuff into a known state to ensure boot and
> resume of the kernel do not result in a different state, shouldn't it?
grep the kernel for l2x0_init() and look at the mask and value registers.
Note that any bit set in the mask is preserved from boot time.
^ permalink raw reply
* [PATCH v12 0/3] add the GPMI controller driver for IMX23/IMX28
From: Huang Shijie @ 2011-09-15 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20081.44941.12535.496764@ipc1.ka-ro>
Hi,
add more CC.
> Hi,
>
> Huang Shijie writes:
>> The patch set is based on Artem's tree:
>> http://git.infradead.org/users/dedekind/l2-mtd-2.6.git
>>
>> The general-purpose media interface(GPMI) controller is a flexible interface
>> to up to several NAND flashs.
>>
>> The Bose Ray-Choudhury Hocquenghem(BCH) module is a hardware ECC accelerator.
>>
>> With the help of BCH, the GPMI controller can choose to do the hardware ECC or
>> not.
>>
>> This driver is a _pure_ MTD NAND controller driver now.
>>
>>
>> The driver depends on another GPMI-NAND device patch set, you can find them at :
>> [1] http://marc.info/?l=linux-arm-kernel&m=131416901319573&w=2
>> [2] http://marc.info/?l=linux-arm-kernel&m=131416912319668&w=2
>> [3] http://marc.info/?l=linux-arm-kernel&m=131416891119504&w=2
>> [4] http://marc.info/?l=linux-arm-kernel&m=131416896219539&w=2
>>
>> Test environment:
>> Using imx23 and imx28 boards for test.
>>
>> imx23 :
>> console=ttyAMA0,115200 mtdparts=gpmi-nfc:20m(boot),-(user)
>> Tested by USB boot and NAND boot.
>>
>> imx28 :
>> #console=ttyAMA0,115200 root=/dev/mmcblk0p3 rw rootwait
>> Tested by SD card boot mode.
>>
> How did you perform your tests?
>
> I tried this driver on our TX28 board with the result that with
The nand conflicats with SD card1. You will get the DMA timeout if you
use it.
Do you use sd card0 or sd card1?
BTW:I tested the gpmi driver with SD card0. It works fine.
Best Regards
Huang Shijie
> concurrent access of the SD card and the NAND flash, I still get the
> dreaded DMA timeouts within seconds:
> DMA timeout, last DMA :1
> GPMI regs:
> HW_GPMI_CTRL0[000]=21800001
> HW_GPMI_COMPARE[010]=00000000
> HW_GPMI_ECCCTRL[020]=00000000
> HW_GPMI_ECCCOUNT[030]=00000840
> HW_GPMI_PAYLOAD[040]=46578000
> HW_GPMI_AUXILIARY[050]=46578800
> HW_GPMI_CTRL1[060]=0004000c
> HW_GPMI_TIMING0[070]=00010203
> HW_GPMI_TIMING1[080]=05000000
> HW_GPMI_TIMING2[090]=09020101
> HW_GPMI_STAT[0b0]=0d000003
> HW_GPMI_DEBUG[0c0]=01000000
> BCH regs:
> HW_BCH_CTRL[000]=00000100
> HW_BCH_STATUS0[010]=00000010
> HW_BCH_MODE[020]=00000000
> HW_BCH_ENCODEPTR[030]=00000000
> HW_BCH_DATAPTR[040]=00000000
> HW_BCH_METAPTR[050]=00000000
> HW_BCH_LAYOUTSELECT[070]=00000000
> HW_BCH_FLASH0LAYOUT0[080]=030a4200
> HW_BCH_FLASH0LAYOUT1[090]=08404200
> HW_BCH_DEBUG0[100]=00000000
> DMA regs:
> HW_APBHX_CTRL0[000]=30000000
> HW_APBHX_CTRL1[010]=ffff0000
> HW_APBHX_CTRL2[020]=00000000
> HW_APBHX_CHANNEL_CTRL[030]=00000000
> HW_APBHX_CHn_CURCMDAR(0)[100]=46e1c000
> HW_APBHX_CHn_NXTCMDAR(0)[110]=46e1c04c
> HW_APBHX_CHn_CMD(0)[120]=000001c8
> HW_APBHX_CHn_BAR(0)[130]=00000000
> HW_APBHX_CHn_SEMA(0)[140]=00000000
> HW_APBHX_CHn_DEBUG1(0)[150]=00a0001e
> HW_APBHX_CHn_DEBUG2(0)[160]=00000000
> HW_APBHX_CHn_CURCMDAR(4)[2c0]=4652c098
> HW_APBHX_CHn_NXTCMDAR(4)[2d0]=4652c0e4
> HW_APBHX_CHn_CMD(4)[2e0]=000001c9
> HW_APBHX_CHn_BAR(4)[2f0]=46553241
> HW_APBHX_CHn_SEMA(4)[300]=00010000
> HW_APBHX_CHn_DEBUG1(4)[310]=27a00015
> HW_APBHX_CHn_DEBUG2(4)[320]=00000000
> BCH Geometry :
> GF length : 13
> ECC Strength : 8
> Page Size in Bytes : 2112
> Metadata Size in Bytes : 10
> ECC Chunk Size in Bytes: 512
> ECC Chunk Count : 4
> Payload Size in Bytes : 2048
> Auxiliary Size in Bytes: 16
> Auxiliary Status Offset: 12
> Block Mark Byte Offset : 1999
> Block Mark Bit Offset : 0
>
> I'm doing a:
> dd if=/dev/mtd0> /dev/null& dd if=/dev/mmcblk0> /dev/null
> Sometimes the 'dd' accessing the SD card will stall indefinitely.
> Also copying data from SD card to flash will produce the error, though
> less likely.
>
> This looks like the problem arises in the DMA driver when multiple
> channels are being used concurrently. The GPMI driver will bail out
> with the timeout error while the MMC driver obviously has no timeout
> check for this situation.
>
> I can mostly rule out HW problems, because the same board works
> perfectly well with WindowsCE (tested with a copy operation between
> flash and SD card).
>
>
> Lothar Wa?mann
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox