Skip to contentSkip to conversation

twl-regulator: Allow CONFIG_TWL4030_ALLOW_UNSUPPORTED to be requested.

PATCH In review NeilBrown 2 participants 6 messages Apr 25, 2012 – Apr 26, 2012

Subsystems (2)
OMAP2+ support Voltage and current regulator framework
lore
Share & tools
lore

NeilBrown

author
#0 lore raw

PATCH 1/1 twl-regulator: Allow CONFIG_TWL4030_ALLOW_UNSUPPORTED to be requested.

twl-regulator.c changes behaviour slightly depending on
CONFIG_TWL4030_ALLOW_UNSUPPORTED
However that config option is not currently listed in any Kconfig file.
So add the option to allow it to be chosen.

Signed-off-by NeilBrown <[email protected]>
drivers/regulator/Kconfig +9 -0
index 36db5a4..1d24cac 100644
@@ -338,6 +338,15 @@ config REGULATOR_TWL4030
 	  This driver supports the voltage regulators provided by
 	  this family of companion chips.
 
+config TWL4030_ALLOW_UNSUPPORTED
+	bool "Allow unsupported voltages on TI TWL4030/TWL5030/TWL6030/TPS659x0 PMIC"
+	depends on REGULATOR_TWL4030
+	help
+	  TWL4030 regulator can (possibly) supply voltages that are not
+	  explicitly supported by TI.  Set this option to allow those
+	  voltages to be requested.
+	  If unsure, say 'N'
+
 config REGULATOR_WM831X
 	tristate "Wolfson Microelectronics WM831x PMIC regulators"
 	depends on MFD_WM831X
#1 lore raw
Quoted 6 lines · NeilBrown

twl-regulator.c changes behaviour slightly depending on
CONFIG_TWL4030_ALLOW_UNSUPPORTED
However that config option is not currently listed in any Kconfig file.
So add the option to allow it to be chosen.

Shouldn't this be hidden behind _EXPERIMENTAL and/or enabled by the board in platform data/device tree? Kconfig feels like the wrong place to do this sort of configuration.

author
#2 lore raw
Quoted 11 lines · On Wed, 25 Apr 2012 09:24:18 +0100 Mark Brown…
Quoted 6 lines · NeilBrown

twl-regulator.c changes behaviour slightly depending on
CONFIG_TWL4030_ALLOW_UNSUPPORTED
However that config option is not currently listed in any Kconfig file.
So add the option to allow it to be chosen.

Shouldn't this be hidden behind _EXPERIMENTAL and/or enabled by the board in platform data/device tree? Kconfig feels like the wrong place to do this sort of configuration.

That make sense - but I cannot find a good place to put the flag. TWL doesn't have any twl-specific platform data, it just uses struct regulator_init_data. I don't suppose it would be acceptable to tuck an 'allow_unsupported' flag inside 'struct regulation_constraints'?

I'm not sure how else to do it without fairly major surgery.

Thanks,
NeilBrown

#3 lore raw
Quoted 6 lines · NeilBrown

That make sense - but I cannot find a good place to put the flag. TWL doesn't have any twl-specific platform data, it just uses struct regulator_init_data. I don't suppose it would be acceptable to tuck an 'allow_unsupported' flag inside 'struct regulation_constraints'?

I'm not sure how else to do it without fairly major surgery.

This is what the driver_data in regulator_init_data is there for - to allow device specific extensions to be added if needed. I guess it should be possible to use that?

author
#4 lore raw
Quoted 7 lines · On Wed, 25 Apr 2012 11:12:59 +0100 Mark Brown…
Quoted 4 lines · NeilBrown

That make sense - but I cannot find a good place to put the flag. TWL doesn't have any twl-specific platform data, it just uses struct regulator_init_data. I don't suppose it would be acceptable to tuck an 'allow_unsupported' flag inside 'struct regulation_constraints'?

Quoted 5 lines
Quoted 1 line

I'm not sure how else to do it without fairly major surgery.

This is what the driver_data in regulator_init_data is there for - to allow device specific extensions to be added if needed. I guess it should be possible to use that?

Ahh... (digs around) and twl treats that as a 'long' and copies it into
info->features
(which is otherwize set from static data).

So maybe something like that (completely untested as yet) ?? (and this seems to have changed between 3.3 and 3.4 which confused me a bit. But if you think this approach is OK I'll come up with something that is right for 3.4).

Thanks,
NeilBrown

drivers/regulator/twl-regulator.c +5 -7
index 181a2cf..00fd3d2 100644
@@ -375,14 +375,12 @@ static int twl6030reg_set_mode(struct regulator_dev *rdev, unsigned mode)
  * VAUX3 at 3V is incorrectly listed in some TI manuals as unsupported.
  * TI are revising the twl5030/tps659x0 specs to support that 3.0V setting.
  */
-#ifdef CONFIG_TWL4030_ALLOW_UNSUPPORTED
-#define UNSUP_MASK	0x0000
-#else
 #define UNSUP_MASK	0x8000
-#endif
 
 #define UNSUP(x)	(UNSUP_MASK | (x))
-#define IS_UNSUP(x)	(UNSUP_MASK & (x))
+#define IS_UNSUP(info, x)			\
+	((UNSUP_MASK & (x)) &&			\
+	 !((info)->features & TWL4030_ALLOW_UNSUPPORTED))
 #define LDO_MV(x)	(~UNSUP_MASK & (x))
 
 

@@ -456,7 +454,7 @@ static int twl4030ldo_list_voltage(struct regulator_dev *rdev, unsigned index)
 	struct twlreg_info	*info = rdev_get_drvdata(rdev);
 	int			mV = info->table[index];
 
-	return IS_UNSUP(mV) ? 0 : (LDO_MV(mV) * 1000);
+	return IS_UNSUP(info, mV) ? 0 : (LDO_MV(mV) * 1000);
 }
 
 static int

@@ -470,7 +468,7 @@ twl4030ldo_set_voltage(struct regulator_dev *rdev, int min_uV, int max_uV,
 		int mV = info->table[vsel];
 		int uV;
 
-		if (IS_UNSUP(mV))
+		if (IS_UNSUP(info, mV))
 			continue;
 		uV = LDO_MV(mV) * 1000;
include/linux/i2c/twl.h +3 -0
index 5b87dc9..5f56743 100644
@@ -172,6 +172,9 @@ TWL_CLASS_IS(4030, TWL4030_CLASS_ID)
 TWL_CLASS_IS(6030, TWL6030_CLASS_ID)
 
 #define TWL6025_SUBCLASS	BIT(4)  /* TWL6025 has changed registers */
+#define TWL4030_ALLOW_UNSUPPORTED BIT(0) /* Some voltages are possible
+					  * but not officially supported
+					  */
 
 /*
  * Read and write single 8-bit registers
#5 lore raw
Quoted 4 lines · NeilBrown

So maybe something like that (completely untested as yet) ?? (and this seems to have changed between 3.3 and 3.4 which confused me a bit. But if you think this approach is OK I'll come up with something that is right for 3.4).

Yes, that looks reasonable.