[patch 2.6.29-rc2-omap1-git 0/7] regulator and MMC updates...

[patch 2.6.29-rc2-omap1-git 0/7] regulator and MMC updates...

[David Brownell]

Several patches here:

 - New interface in regulator core ... in the regulator queue
   (presumably for 2.6.30 merge)

 - twl4030 regulator updates to use that interface

Given that second part, I think the twl4030 regulator code can
be submitted upstream.

 - Init updates for OMAP 3430 SDP ... regulators, MMC switches,
   and a bit more.

 - Minor Overo init update:  set up VMMC1

 - HSMMC init update:  pass device back so regulator setup can
   use it.  (Not as invasive as a cleaner fix would be...)

 - Beagle init update:  hook up the regulators used by MMC-1
   (relies on that init update)

 - SDP init update:  hook up regulators used by MMC-1 and MMC-2
   (also relies on that init update)

These go on top of patches I sent previously, to work around
a lockdep issue in the hsmmc driver (that might go to mainline
as a bugfix, assuming that driver goes to mainline for 2.6.29)
and correct the mach-omap2/mmc-twl4030.c power switching.

Once that's merged, it'll be ready to start using the regulator
calls to switch power for MMC on at least those platforms.

- Dave

[patch 2.6.29-rc2-omap1-git 1/7] regulator get_status()

[David Brownell]

From: David Brownell <dbrownell@users.sourceforge.net>

Based on previous LKML discussions:

 * Update docs for regulator sysfs class attributes to highlight
   the fact that all current attributes are intended to be control
   inputs, including notably "state" and "opmode" which previously
   implied otherwise.

 * Define a new regulator driver get_status() method, which is the
   first method reporting regulator outputs instead of inputs.
   It can report on/off and error status; or instead of simply
   "on", report the actual operating mode.

For the moment, this is a sysfs-only interface, not accessible to 
regulator clients.  Such clients can use the current notification
interfaces to detect errors, if the regulator reports them.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
---
This is in the -next tree and on track to merge to mainline.

 Documentation/ABI/testing/sysfs-class-regulator |   57 ++++++++++++++++++----
 drivers/regulator/core.c                        |   46 +++++++++++++++++
 include/linux/regulator/driver.h                |   17 ++++++
 3 files changed, 111 insertions(+), 9 deletions(-)

--- a/Documentation/ABI/testing/sysfs-class-regulator
+++ b/Documentation/ABI/testing/sysfs-class-regulator
@@ -4,8 +4,8 @@ KernelVersion:	2.6.26
 Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
 Description:
 		Some regulator directories will contain a field called
-		state. This reports the regulator enable status, for
-		regulators which can report that value.
+		state. This reports the regulator enable control, for
+		regulators which can report that input value.
 
 		This will be one of the following strings:
 
@@ -14,16 +14,54 @@ Description:
 		'unknown'
 
 		'enabled' means the regulator output is ON and is supplying
-		power to the system.
+		power to the system (assuming no error prevents it).
 
 		'disabled' means the regulator output is OFF and is not
-		supplying power to the system..
+		supplying power to the system (unless some non-Linux
+		control has enabled it).
 
 		'unknown' means software cannot determine the state, or
 		the reported state is invalid.
 
 		NOTE: this field can be used in conjunction with microvolts
-		and microamps to determine regulator output levels.
+		or microamps to determine configured regulator output levels.
+
+
+What:		/sys/class/regulator/.../status
+Description:
+		Some regulator directories will contain a field called
+		"status". This reports the current regulator status, for
+		regulators which can report that output value.
+
+		This will be one of the following strings:
+
+			off
+			on
+			error
+			fast
+			normal
+			idle
+			standby
+
+		"off" means the regulator is not supplying power to the
+		system.
+
+		"on" means the regulator is supplying power to the system,
+		and the regulator can't report a detailed operation mode.
+
+		"error" indicates an out-of-regulation status such as being
+		disabled due to thermal shutdown, or voltage being unstable
+		because of problems with the input power supply.
+
+		"fast", "normal", "idle", and "standby" are all detailed
+		regulator operation modes (described elsewhere).  They
+		imply "on", but provide more detail.
+
+		Note that regulator status is a function of many inputs,
+		not limited to control inputs from Linux.  For example,
+		the actual load presented may trigger "error" status; or
+		a regulator may be enabled by another user, even though
+		Linux did not enable it.
 
 
 What:		/sys/class/regulator/.../type
@@ -58,7 +96,7 @@ Description:
 		Some regulator directories will contain a field called
 		microvolts. This holds the regulator output voltage setting
 		measured in microvolts (i.e. E-6 Volts), for regulators
-		which can report that voltage.
+		which can report the control input for voltage.
 
 		NOTE: This value should not be used to determine the regulator
 		output voltage level as this value is the same regardless of
@@ -73,7 +111,7 @@ Description:
 		Some regulator directories will contain a field called
 		microamps. This holds the regulator output current limit
 		setting measured in microamps (i.e. E-6 Amps), for regulators
-		which can report that current.
+		which can report the control input for a current limit.
 
 		NOTE: This value should not be used to determine the regulator
 		output current level as this value is the same regardless of
@@ -87,7 +125,7 @@ Contact:	Liam Girdwood <lrg@slimlogic.co
 Description:
 		Some regulator directories will contain a field called
 		opmode. This holds the current regulator operating mode,
-		for regulators which can report it.
+		for regulators which can report that control input value.
 
 		The opmode value can be one of the following strings:
 
@@ -101,7 +139,8 @@ Description:
 
 		NOTE: This value should not be used to determine the regulator
 		output operating mode as this value is the same regardless of
-		whether the regulator is enabled or disabled.
+		whether the regulator is enabled or disabled.  A "status"
+		attribute may be available to determine the actual mode.
 
 
 What:		/sys/class/regulator/.../min_microvolts
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -312,6 +312,47 @@ static ssize_t regulator_state_show(stru
 }
 static DEVICE_ATTR(state, 0444, regulator_state_show, NULL);
 
+static ssize_t regulator_status_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	struct regulator_dev *rdev = dev_get_drvdata(dev);
+	int status;
+	char *label;
+
+	status = rdev->desc->ops->get_status(rdev);
+	if (status < 0)
+		return status;
+
+	switch (status) {
+	case REGULATOR_STATUS_OFF:
+		label = "off";
+		break;
+	case REGULATOR_STATUS_ON:
+		label = "on";
+		break;
+	case REGULATOR_STATUS_ERROR:
+		label = "error";
+		break;
+	case REGULATOR_STATUS_FAST:
+		label = "fast";
+		break;
+	case REGULATOR_STATUS_NORMAL:
+		label = "normal";
+		break;
+	case REGULATOR_STATUS_IDLE:
+		label = "idle";
+		break;
+	case REGULATOR_STATUS_STANDBY:
+		label = "standby";
+		break;
+	default:
+		return -ERANGE;
+	}
+
+	return sprintf(buf, "%s\n", label);
+}
+static DEVICE_ATTR(status, 0444, regulator_status_show, NULL);
+
 static ssize_t regulator_min_uA_show(struct device *dev,
 				    struct device_attribute *attr, char *buf)
 {
@@ -1744,6 +1785,11 @@ static int add_regulator_attributes(stru
 		if (status < 0)
 			return status;
 	}
+	if (ops->get_status) {
+		status = device_create_file(dev, &dev_attr_status);
+		if (status < 0)
+			return status;
+	}
 
 	/* some attributes are type-specific */
 	if (rdev->desc->type == REGULATOR_CURRENT) {
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -21,6 +21,17 @@
 struct regulator_dev;
 struct regulator_init_data;
 
+enum regulator_status {
+	REGULATOR_STATUS_OFF,
+	REGULATOR_STATUS_ON,
+	REGULATOR_STATUS_ERROR,
+	/* fast/normal/idle/standby are flavors of "on" */
+	REGULATOR_STATUS_FAST,
+	REGULATOR_STATUS_NORMAL,
+	REGULATOR_STATUS_IDLE,
+	REGULATOR_STATUS_STANDBY,
+};
+
 /**
  * struct regulator_ops - regulator operations.
  *
@@ -72,6 +83,12 @@ struct regulator_ops {
 	int (*set_mode) (struct regulator_dev *, unsigned int mode);
 	unsigned int (*get_mode) (struct regulator_dev *);
 
+	/* report regulator status ... most other accessors report
+	 * control inputs, this reports results of combining inputs
+	 * from Linux (and other sources) with the actual load.
+	 */
+	int (*get_status)(struct regulator_dev *);
+
 	/* get most efficient regulator operating mode for load */
 	unsigned int (*get_optimum_mode) (struct regulator_dev *, int input_uV,
 					  int output_uV, int load_uA);

[patch 2.6.29-rc2-omap1-git 2/7] twl4030 regulator uses new get_status() op

[David Brownell]

From: David Brownell <dbrownell@users.sourceforge.net>

Update twl4030 regulator driver to support the new get_status()
method and otherwise implement the newly "clarified" semantics.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
Given this, I think this driver is ready to merge to mainline.

 drivers/regulator/twl4030-regulator.c |   39 +++++++++++++++-----------------
 1 file changed, 19 insertions(+), 20 deletions(-)

--- a/drivers/regulator/twl4030-regulator.c
+++ b/drivers/regulator/twl4030-regulator.c
@@ -90,17 +90,6 @@ static int twl4030reg_grp(struct regulat
 	return twl4030reg_read(rdev_get_drvdata(rdev), VREG_GRP);
 }
 
-static int twl4030reg_is_enabled(struct regulator_dev *rdev)
-{
-	int	state = twl4030reg_grp(rdev);
-
-	if (state < 0)
-		return state;
-
-	/* resource state == OFF (vs SLEEP or ACTIVE) */
-	return (state & 0x0f) != 0;
-}
-
 /*
  * Enable/disable regulators by joining/leaving the P1 (processor) group.
  * We assume nobody else is updating the DEV_GRP registers.
@@ -110,6 +99,16 @@ static int twl4030reg_is_enabled(struct 
 #define P2_GRP		BIT(6)		/* secondary processor, modem, etc */
 #define P1_GRP		BIT(5)		/* CPU/Linux */
 
+static int twl4030reg_is_enabled(struct regulator_dev *rdev)
+{
+	int	state = twl4030reg_grp(rdev);
+
+	if (state < 0)
+		return state;
+
+	return (state & P1_GRP) != 0;
+}
+
 static int twl4030reg_enable(struct regulator_dev *rdev)
 {
 	struct twlreg_info	*info = rdev_get_drvdata(rdev);
@@ -136,7 +135,7 @@ static int twl4030reg_disable(struct reg
 	return twl4030reg_write(info, VREG_GRP, grp);
 }
 
-static unsigned twl4030reg_get_mode(struct regulator_dev *rdev)
+static int twl4030reg_get_status(struct regulator_dev *rdev)
 {
 	int	state = twl4030reg_grp(rdev);
 
@@ -146,10 +145,10 @@ static unsigned twl4030reg_get_mode(stru
 
 	/* assume state != WARM_RESET; we'd not be running...  */
 	if (!state)
-		return REGULATOR_MODE_OFF;
+		return REGULATOR_STATUS_OFF;
 	return (state & BIT(3))
-		? REGULATOR_MODE_NORMAL
-		: REGULATOR_MODE_STANDBY;
+		? REGULATOR_STATUS_NORMAL
+		: REGULATOR_STATUS_STANDBY;
 }
 
 static int twl4030reg_set_mode(struct regulator_dev *rdev, unsigned mode)
@@ -306,7 +305,8 @@ static struct regulator_ops twl4030ldo_o
 	.is_enabled	= twl4030reg_is_enabled,
 
 	.set_mode	= twl4030reg_set_mode,
-	.get_mode	= twl4030reg_get_mode,
+
+	.get_status	= twl4030reg_get_status,
 };
 
 /*----------------------------------------------------------------------*/
@@ -329,7 +329,8 @@ static struct regulator_ops twl4030fixed
 	.is_enabled	= twl4030reg_is_enabled,
 
 	.set_mode	= twl4030reg_set_mode,
-	.get_mode	= twl4030reg_get_mode,
+
+	.get_status	= twl4030reg_get_status,
 };
 
 /*----------------------------------------------------------------------*/
@@ -426,9 +427,7 @@ static int twl4030reg_probe(struct platf
 		c->min_uV = min_uV;
 	if (!c->max_uV || c->max_uV > max_uV)
 		c->max_uV = max_uV;
-	c->valid_modes_mask &= REGULATOR_MODE_NORMAL
-				| REGULATOR_MODE_STANDBY
-				| REGULATOR_MODE_OFF;
+	c->valid_modes_mask &= REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY;
 	c->valid_ops_mask &= REGULATOR_CHANGE_VOLTAGE
 				| REGULATOR_CHANGE_MODE
 				| REGULATOR_CHANGE_STATUS;

[patch 2.6.29-rc2-omap1-git 3/7] 3430SDP init updates

[David Brownell]

From: David Brownell <dbrownell@users.sourceforge.net>

OMAP 3430 SDP init updates:

 - Provide a more correct address for the Ethernet chip, getting
   rid of a warning during system boot
 - Hook up the various MMC card cage switches (init MMC later)
 - Configure pullups on the unused twl4030 GPIOs
 - Set up the GPIOs coupled to the (optional) SPI display
 - Initialize various regulators

Note that some SDP boards (all rev2 versions?) use a twl5030 not
the older twl4030 chip.  This isn't changed here.  It'd be a bit of
work to detect (fetch configuration data from the FPGA), and doesn't
much matter since the main change would be that VAUX2 could support
more voltages, but it's supposed to be fixed at 2.8V.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
 arch/arm/mach-omap2/board-3430sdp.c |  182 ++++++++++++++++++++++++++++++----
 1 file changed, 161 insertions(+), 21 deletions(-)

--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -23,6 +23,7 @@
 #include <linux/spi/spi.h>
 #include <linux/spi/ads7846.h>
 #include <linux/i2c/twl4030.h>
+#include <linux/regulator/machine.h>
 
 #include <mach/hardware.h>
 #include <asm/mach-types.h>
@@ -58,8 +59,6 @@
 
 static struct resource sdp3430_smc91x_resources[] = {
 	[0] = {
-		.start	= OMAP34XX_ETHR_START,
-		.end	= OMAP34XX_ETHR_START + SZ_4K,
 		.flags	= IORESOURCE_MEM,
 	},
 	[1] = {
@@ -260,8 +259,8 @@ static inline void __init sdp3430_init_s
 		return;
 	}
 
-	sdp3430_smc91x_resources[0].start = cs_mem_base + 0x0;
-	sdp3430_smc91x_resources[0].end   = cs_mem_base + 0xf;
+	sdp3430_smc91x_resources[0].start = cs_mem_base + 0x300;
+	sdp3430_smc91x_resources[0].end   = cs_mem_base + 0x30f;
 	udelay(100);
 
 	if (omap_rev() > OMAP3430_REV_ES1_0)
@@ -316,10 +315,51 @@ static struct twl4030_bci_platform_data 
       .tblsize		= ARRAY_SIZE(sdp3430_batt_table),
 };
 
+static struct twl4030_hsmmc_info mmc[] = {
+	{
+		.mmc		= 1,
+		/* 8 bits (default) requires S6.3 == ON,
+		 * so the SIM card isn't used; else 4 bits.
+		 */
+		.wires		= 8,
+		.gpio_wp	= 4,
+	},
+	{
+		.mmc		= 2,
+		.wires		= 8,
+		.gpio_wp	= 7,
+	},
+	{}	/* Terminator */
+};
+
+static int sdp3430_twl_gpio_setup(struct device *dev,
+		unsigned gpio, unsigned ngpio)
+{
+	/* gpio + 0 is "mmc0_cd" (input/IRQ),
+	 * gpio + 1 is "mmc1_cd" (input/IRQ)
+	 */
+	mmc[0].gpio_cd = gpio + 0;
+	mmc[1].gpio_cd = gpio + 1;
+	twl4030_mmc_init(mmc);
+
+	/* gpio + 7 is "sub_lcd_en_bkl" (output/PWM1) */
+	gpio_request(gpio + 7, "sub_lcd_en_bkl");
+	gpio_direction_output(gpio + 7, 0);
+
+	/* gpio + 15 is "sub_lcd_nRST" (output) */
+	gpio_request(gpio + 15, "sub_lcd_nRST");
+	gpio_direction_output(gpio + 15, 0);
+
+	return 0;
+}
+
 static struct twl4030_gpio_platform_data sdp3430_gpio_data = {
 	.gpio_base	= OMAP_MAX_GPIO_LINES,
 	.irq_base	= TWL4030_GPIO_IRQ_BASE,
 	.irq_end	= TWL4030_GPIO_IRQ_END,
+	.pulldowns	= BIT(2) | BIT(6) | BIT(8) | BIT(13)
+				| BIT(16) | BIT(17),
+	.setup		= sdp3430_twl_gpio_setup,
 };
 
 static struct twl4030_usb_data sdp3430_usb_data = {
@@ -411,6 +451,111 @@ static struct twl4030_power_data sdp3430
 	.size		= ARRAY_SIZE(twl4030_scripts),
 };
 
+/*
+ * Apply all the fixed voltages since most versions of U-Boot
+ * don't bother with that initialization.
+ */
+
+/* VAUX1 for mainboard (irda and sub-lcd) */
+static struct regulator_init_data sdp3430_vaux1 = {
+	.constraints = {
+		.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,
+	},
+};
+
+/* VAUX2 for camera module */
+static struct regulator_init_data sdp3430_vaux2 = {
+	.constraints = {
+		.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,
+	},
+};
+
+/* VAUX3 for LCD board */
+static struct regulator_init_data sdp3430_vaux3 = {
+	.constraints = {
+		.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,
+	},
+};
+
+/* VAUX4 for OMAP VDD_CSI2 (camera) */
+static struct regulator_init_data sdp3430_vaux4 = {
+	.constraints = {
+		.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,
+	},
+};
+
+/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
+static struct regulator_init_data sdp3430_vmmc1 = {
+	.constraints = {
+		.valid_modes_mask = REGULATOR_MODE_NORMAL
+				| REGULATOR_MODE_STANDBY,
+		.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+				| REGULATOR_CHANGE_MODE
+				| REGULATOR_CHANGE_STATUS,
+	},
+};
+
+/* VMMC2 for MMC2 card */
+static struct regulator_init_data sdp3430_vmmc2 = {
+	.constraints = {
+		.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,
+	},
+};
+
+/* VSIM for OMAP VDD_MMC1A (i/o for DAT4..DAT7) */
+static struct regulator_init_data sdp3430_vsim = {
+	.constraints = {
+		.valid_modes_mask = REGULATOR_MODE_NORMAL
+				| REGULATOR_MODE_STANDBY,
+		.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+				| REGULATOR_CHANGE_MODE
+				| REGULATOR_CHANGE_STATUS,
+	},
+};
+
+/* VDAC for DSS driving S-Video */
+static struct regulator_init_data sdp3430_vdac = {
+	.constraints = {
+		.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,
+	},
+};
+
 static struct twl4030_platform_data sdp3430_twldata = {
 	.irq_base	= TWL4030_IRQ_BASE,
 	.irq_end	= TWL4030_IRQ_END,
@@ -422,6 +567,15 @@ static struct twl4030_platform_data sdp3
 	.keypad		= &sdp3430_kp_data,
 	.power		= &sdp3430_t2scripts_data,
 	.usb		= &sdp3430_usb_data,
+
+	.vaux1		= &sdp3430_vaux1,
+	.vaux2		= &sdp3430_vaux2,
+	.vaux3		= &sdp3430_vaux3,
+	.vaux4		= &sdp3430_vaux4,
+	.vmmc1		= &sdp3430_vmmc1,
+	.vmmc2		= &sdp3430_vmmc2,
+	.vsim		= &sdp3430_vsim,
+	.vdac		= &sdp3430_vdac,
 };
 
 static struct i2c_board_info __initdata sdp3430_i2c_boardinfo[] = {
@@ -435,29 +589,16 @@ static struct i2c_board_info __initdata 
 
 static int __init omap3430_i2c_init(void)
 {
+	/* i2c1 for PMIC only */
 	omap_register_i2c_bus(1, 2600, sdp3430_i2c_boardinfo,
 			ARRAY_SIZE(sdp3430_i2c_boardinfo));
+	/* i2c2 on camera connector (for sensor control) and optional isp1301 */
 	omap_register_i2c_bus(2, 400, NULL, 0);
+	/* i2c3 on display connector (for DVI, tfp410) */
 	omap_register_i2c_bus(3, 400, NULL, 0);
 	return 0;
 }
 
-static struct twl4030_hsmmc_info mmc[] __initdata = {
-	{
-		.mmc		= 1,
-		.wires		= 8,
-		.gpio_cd	= -EINVAL,
-		.gpio_wp	= -EINVAL,
-	},
-	{
-		.mmc		= 2,
-		.wires		= 8,
-		.gpio_cd	= -EINVAL,
-		.gpio_wp	= -EINVAL,
-	},
-	{}	/* Terminator */
-};
-
 extern void __init sdp3430_flash_init(void);
 
 static void __init omap_3430sdp_init(void)
@@ -479,7 +620,6 @@ static void __init omap_3430sdp_init(voi
 	omap_serial_init();
 	usb_musb_init();
 	usb_ehci_init();
-	twl4030_mmc_init(mmc);
 }
 
 static void __init omap_3430sdp_map_io(void)

[patch 2.6.29-rc2-omap1-git 4/7] minor overo init update

[David Brownell]

From: David Brownell <dbrownell@users.sourceforge.net>

Overo init update:  configure the VMMC regulator, which seems
to be the only one (other than VDD1 and VIO) used.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
 arch/arm/mach-omap2/board-overo.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -27,6 +27,7 @@
 #include <linux/kernel.h>
 #include <linux/platform_device.h>
 #include <linux/i2c/twl4030.h>
+#include <linux/regulator/machine.h>
 
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/nand.h>
@@ -156,12 +157,25 @@ static struct twl4030_usb_data overo_usb
 	.usb_mode	= T2_USB_MODE_ULPI,
 };
 
+static struct regulator_init_data overo_vmmc1 = {
+	.constraints = {
+		.valid_modes_mask = REGULATOR_MODE_NORMAL
+				| REGULATOR_MODE_STANDBY,
+		.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+				| REGULATOR_CHANGE_MODE
+				| REGULATOR_CHANGE_STATUS,
+	},
+};
+
+/* mmc2 (WLAN) and Bluetooth don't use twl4030 regulators */
+
 static struct twl4030_platform_data overo_twldata = {
 	.irq_base	= TWL4030_IRQ_BASE,
 	.irq_end	= TWL4030_IRQ_END,
 	.gpio		= &overo_gpio_data,
 	.usb		= &overo_usb_data,
 	.power		= GENERIC3430_T2SCRIPTS_DATA,
+	.vmmc1		= &overo_vmmc1,
 };
 
 static struct i2c_board_info __initdata overo_i2c_boardinfo[] = {

[patch 2.6.29-rc2-omap1-git 5/7] hsmmc init passes device nodes back

[David Brownell]

From: David Brownell <dbrownell@users.sourceforge.net>

When setting up HSMMC devices, pass pass the device nodes back so
board code can linking them to their power supply regulators.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
Kind of ugly, but minimally invasive.  A cleaner approach might
have board code initialize one controller at a time, with that
call returning the relevant device node.

 arch/arm/mach-omap2/mmc-twl4030.c     |   10 ++++++++++
 arch/arm/mach-omap2/mmc-twl4030.h     |    1 +
 arch/arm/plat-omap/devices.c          |    3 +++
 arch/arm/plat-omap/include/mach/mmc.h |    2 ++
 4 files changed, 16 insertions(+)

--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -17,6 +17,7 @@
 #include <linux/delay.h>
 #include <linux/gpio.h>
 #include <linux/i2c/twl4030.h>
+#include <linux/regulator/machine.h>
 
 #include <mach/hardware.h>
 #include <mach/control.h>
@@ -436,6 +437,15 @@ void __init twl4030_mmc_init(struct twl4
 	}
 
 	omap2_init_mmc(hsmmc_data, OMAP34XX_NR_MMC);
+
+	/* pass the device nodes back to board setup code */
+	for (c = controllers; c->mmc; c++) {
+		struct omap_mmc_platform_data *mmc = hsmmc_data[c->mmc - 1];
+
+		if (!c->mmc || c->mmc > nr_hsmmc)
+			continue;
+		c->dev = mmc->dev;
+	}
 }
 
 #endif
--- a/arch/arm/mach-omap2/mmc-twl4030.h
+++ b/arch/arm/mach-omap2/mmc-twl4030.h
@@ -13,6 +13,7 @@ struct twl4030_hsmmc_info {
 	bool	ext_clock;	/* use external pin for input clock */
 	int	gpio_cd;	/* or -EINVAL */
 	int	gpio_wp;	/* or -EINVAL */
+	struct device *dev;	/* returned: pointer to mmc adapter */
 };
 
 #if	defined(CONFIG_TWL4030_CORE) && \
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -232,6 +232,9 @@ int __init omap_mmc_add(int id, unsigned
 	ret = platform_device_add(pdev);
 	if (ret)
 		goto fail;
+
+	/* return device handle to board setup code */
+	data->dev = &pdev->dev;
 	return 0;
 
 fail:
--- a/arch/arm/plat-omap/include/mach/mmc.h
+++ b/arch/arm/plat-omap/include/mach/mmc.h
@@ -37,6 +37,8 @@
 #define OMAP_MMC_MAX_SLOTS	2
 
 struct omap_mmc_platform_data {
+	/* back-link to device */
+	struct device *dev;
 
 	/* number of slots per controller */
 	unsigned nr_slots:2;

[patch 2.6.29-rc2-omap1-git 6/7] beagle regulator updates

[David Brownell]

From: David Brownell <dbrownell@users.sourceforge.net>

For Beagle, link two regulators to the MMC-1 host adapter.

Note:  when MMC1 is used in 8 bit mode (e.g. for an MMCplus card)
DAT4..DAT7 I/O uses a separate supply (VSIM).  But MMC_BUS_WIDTH_8
support isn't yet merged into the MMC framework.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
 arch/arm/mach-omap2/board-omap3beagle.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -126,6 +126,14 @@ static struct twl4030_hsmmc_info mmc[] =
 	{}	/* Terminator */
 };
 
+static struct regulator_consumer_supply beagle_vmmc1_supply = {
+	.supply			= "vmmc",
+};
+
+static struct regulator_consumer_supply beagle_vsim_supply = {
+	.supply			= "vmmc_dat4..7",
+};
+
 static struct gpio_led gpio_leds[];
 
 static int beagle_twl_gpio_setup(struct device *dev,
@@ -136,6 +144,10 @@ static int beagle_twl_gpio_setup(struct 
 	mmc[0].gpio_cd = gpio + 0;
 	twl4030_mmc_init(mmc);
 
+	/* link regulators to MMC adapters */
+	beagle_vmmc1_supply.dev = mmc[0].dev;
+	beagle_vsim_supply.dev = mmc[0].dev;
+
 	/* REVISIT: need ehci-omap hooks for external VBUS
 	 * power switch and overcurrent detect
 	 */
@@ -173,6 +185,8 @@ static struct regulator_init_data beagle
 				| REGULATOR_CHANGE_MODE
 				| REGULATOR_CHANGE_STATUS,
 	},
+	.num_consumer_supplies	= 1,
+	.consumer_supplies	= &beagle_vmmc1_supply,
 };
 
 /* VSIM for MMC1 pins DAT4..DAT7 (2 mA, plus card == max 50 mA) */
@@ -184,6 +198,8 @@ static struct regulator_init_data beagle
 				| REGULATOR_CHANGE_MODE
 				| REGULATOR_CHANGE_STATUS,
 	},
+	.num_consumer_supplies	= 1,
+	.consumer_supplies	= &beagle_vsim_supply,
 };
 
 /* VDAC for DSS driving S-Video (8 mA unloaded, max 65 mA) */

[patch 2.6.29-rc2-omap1-git 7/7] 3430SDP regulator updates

[David Brownell]

From: David Brownell <dbrownell@users.sourceforge.net>

For OMAP3430 SDP, link regulators to the appropriate MMC host adapters.

Note that when MMC1 is used in 8 bit mode (e.g. for an MMCplus card
or CE-ATA device), DAT4..DAT7 I/O uses a separate supply (VSIM).
But MMC_BUS_WIDTH_8 support isn't merged into the MMC framework.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
 arch/arm/mach-omap2/board-3430sdp.c |   25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -332,6 +332,18 @@ static struct twl4030_hsmmc_info mmc[] =
 	{}	/* Terminator */
 };
 
+static struct regulator_consumer_supply sdp3430_vmmc1_supply = {
+	.supply			= "vmmc",
+};
+
+static struct regulator_consumer_supply sdp3430_vsim_supply = {
+	.supply			= "vmmc_dat4..7",
+};
+
+static struct regulator_consumer_supply sdp3430_vmmc2_supply = {
+	.supply			= "vmmc",
+};
+
 static int sdp3430_twl_gpio_setup(struct device *dev,
 		unsigned gpio, unsigned ngpio)
 {
@@ -342,6 +354,13 @@ static int sdp3430_twl_gpio_setup(struct
 	mmc[1].gpio_cd = gpio + 1;
 	twl4030_mmc_init(mmc);
 
+	/* link regulators to MMC adapters ... we "know" the
+	 * regulators will be set up only *after* we return.
+	 */
+	sdp3430_vmmc1_supply.dev = mmc[0].dev;
+	sdp3430_vsim_supply.dev = mmc[0].dev;
+	sdp3430_vmmc2_supply.dev = mmc[1].dev;
+
 	/* gpio + 7 is "sub_lcd_en_bkl" (output/PWM1) */
 	gpio_request(gpio + 7, "sub_lcd_en_bkl");
 	gpio_direction_output(gpio + 7, 0);
@@ -517,6 +536,8 @@ static struct regulator_init_data sdp343
 				| REGULATOR_CHANGE_MODE
 				| REGULATOR_CHANGE_STATUS,
 	},
+	.num_consumer_supplies	= 1,
+	.consumer_supplies	= &sdp3430_vmmc1_supply,
 };
 
 /* VMMC2 for MMC2 card */
@@ -530,6 +551,8 @@ static struct regulator_init_data sdp343
 		.valid_ops_mask		= REGULATOR_CHANGE_MODE
 					| REGULATOR_CHANGE_STATUS,
 	},
+	.num_consumer_supplies	= 1,
+	.consumer_supplies	= &sdp3430_vmmc2_supply,
 };
 
 /* VSIM for OMAP VDD_MMC1A (i/o for DAT4..DAT7) */
@@ -541,6 +564,8 @@ static struct regulator_init_data sdp343
 				| REGULATOR_CHANGE_MODE
 				| REGULATOR_CHANGE_STATUS,
 	},
+	.num_consumer_supplies	= 1,
+	.consumer_supplies	= &sdp3430_vsim_supply,
 };
 
 /* VDAC for DSS driving S-Video */

Re: [patch 2.6.29-rc2-omap1-git 0/7] regulator and MMC updates...

[Tony Lindgren]

* David Brownell <david-b@pacbell.net> [090120 03:01]:
> Several patches here:
> 
>  - New interface in regulator core ... in the regulator queue
>    (presumably for 2.6.30 merge)
> 
>  - twl4030 regulator updates to use that interface
> 
> Given that second part, I think the twl4030 regulator code can
> be submitted upstream.
> 
>  - Init updates for OMAP 3430 SDP ... regulators, MMC switches,
>    and a bit more.
> 
>  - Minor Overo init update:  set up VMMC1
> 
>  - HSMMC init update:  pass device back so regulator setup can
>    use it.  (Not as invasive as a cleaner fix would be...)
> 
>  - Beagle init update:  hook up the regulators used by MMC-1
>    (relies on that init update)
> 
>  - SDP init update:  hook up regulators used by MMC-1 and MMC-2
>    (also relies on that init update)
> 
> These go on top of patches I sent previously, to work around
> a lockdep issue in the hsmmc driver (that might go to mainline
> as a bugfix, assuming that driver goes to mainline for 2.6.29)
> and correct the mach-omap2/mmc-twl4030.c power switching.
> 
> Once that's merged, it'll be ready to start using the regulator
> calls to switch power for MMC on at least those platforms.

Pushing this series to l-o tree. Again, let me know what to add to the
upstream queues (and when).

Regards,

Tony

Re: [patch 2.6.29-rc2-omap1-git 0/7] regulator and MMC updates...

[David Brownell]

On Wednesday 04 February 2009, Tony Lindgren wrote:
> * David Brownell <david-b@pacbell.net> [090120 03:01]:
> > Several patches here:
> > 
> >  - New interface in regulator core ... in the regulator queue
> >    (presumably for 2.6.30 merge)
> > 
> >  - twl4030 regulator updates to use that interface

And now that you've merged that ... I'll send the twl4030 regulator
code up for 2.6.30 merge-to-mainline.


> > Given that second part, I think the twl4030 regulator code can
> > be submitted upstream.
> > 
> >  - Init updates for OMAP 3430 SDP ... regulators, MMC switches,
> >    and a bit more.
> > 
> >  - Minor Overo init update:  set up VMMC1
> > 
> >  - HSMMC init update:  pass device back so regulator setup can
> >    use it.  (Not as invasive as a cleaner fix would be...)
> > 
> >  - Beagle init update:  hook up the regulators used by MMC-1
> >    (relies on that init update)
> > 
> >  - SDP init update:  hook up regulators used by MMC-1 and MMC-2
> >    (also relies on that init update)
> > 
> > These go on top of patches I sent previously, to work around
> > a lockdep issue in the hsmmc driver (that might go to mainline
> > as a bugfix, assuming that driver goes to mainline for 2.6.29)
> > and correct the mach-omap2/mmc-twl4030.c power switching.
> > 
> > Once that's merged, it'll be ready to start using the regulator
> > calls to switch power for MMC on at least those platforms.
> 
> Pushing this series to l-o tree. Again, let me know what to add to the
> upstream queues (and when).

Those last five can go whenever you're ready ... assuming
nobody finds any trouble they cause.

- Dave


> 
> Regards,
> 
> Tony
> 
>