Extend the twlreg_info structure to hold the turnon delay and remap config
value for regulators, and implement turnon delay in reg_enable
Signed-off-by: Juha Keski-Saari <[email protected]>
---
drivers/regulator/twl4030-regulator.c | 63 ++++++++++++++++++---------------
1 files changed, 34 insertions(+), 29 deletions(-)
diff --git a/drivers/regulator/twl4030-regulator.c b/drivers/regulator/twl4030-regulator.c
index 477c965..a0e43f3 100644
--- a/drivers/regulator/twl4030-regulator.c
+++ b/drivers/regulator/twl4030-regulator.c
@@ -12,6 +12,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/err.h>
+#include <linux/delay.h>
#include <linux/platform_device.h>
#include <linux/regulator/driver.h>
#include <linux/regulator/machine.h>
@@ -43,6 +44,12 @@ struct twlreg_info {
/* chip constraints on regulator behavior */
u16 min_mV;
+ /* regulator specific turn-on delay */
+ u16 delay;
+
+ /* stte REMAP default configuration */
+ u8 remap;
+
/* used by regulator core */
struct regulator_desc desc;
};
@@ -108,13 +115,18 @@ static int twl4030reg_enable(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
int grp;
+ int ret;
grp = twl4030reg_read(info, VREG_GRP);
if (grp < 0)
return grp;
grp |= P1_GRP;
- return twl4030reg_write(info, VREG_GRP, grp);
+ ret = twl4030reg_write(info, VREG_GRP, grp);
+
+ udelay(info->delay);
+
+ return ret;
}
static int twl4030reg_disable(struct regulator_dev *rdev)
@@ -401,36 +413,29 @@ static struct regulator_ops twl4030fixed_ops = {
* software control over them after boot.
*/
static struct twlreg_info twl4030_regs[] = {
- TWL_ADJUSTABLE_LDO(VAUX1, 0x17, 1),
- TWL_ADJUSTABLE_LDO(VAUX2_4030, 0x1b, 2),
- TWL_ADJUSTABLE_LDO(VAUX2, 0x1b, 2),
- TWL_ADJUSTABLE_LDO(VAUX3, 0x1f, 3),
- TWL_ADJUSTABLE_LDO(VAUX4, 0x23, 4),
- TWL_ADJUSTABLE_LDO(VMMC1, 0x27, 5),
- TWL_ADJUSTABLE_LDO(VMMC2, 0x2b, 6),
- TWL_ADJUSTABLE_LDO(VPLL1, 0x2f, 7),
- TWL_ADJUSTABLE_LDO(VPLL2, 0x33, 8),
- TWL_ADJUSTABLE_LDO(VSIM, 0x37, 9),
- TWL_ADJUSTABLE_LDO(VDAC, 0x3b, 10),
- TWL_FIXED_LDO(VINTANA1, 0x3f, 1500, 11),
- TWL_ADJUSTABLE_LDO(VINTANA2, 0x43, 12),
- TWL_FIXED_LDO(VINTDIG, 0x47, 1500, 13),
- TWL_ADJUSTABLE_LDO(VIO, 0x4b, 14),
- TWL_ADJUSTABLE_LDO(VDD1, 0x55, 15),
- TWL_ADJUSTABLE_LDO(VDD2, 0x63, 16),
- TWL_FIXED_LDO(VUSB1V5, 0x71, 1500, 17),
- TWL_FIXED_LDO(VUSB1V8, 0x74, 1800, 18),
- TWL_FIXED_LDO(VUSB3V1, 0x77, 3100, 19),
+ TWL_ADJUSTABLE_LDO(VAUX1, 0x17, 1, 100, 0x08),
+ TWL_ADJUSTABLE_LDO(VAUX2_4030, 0x1b, 2, 100, 0x08),
+ TWL_ADJUSTABLE_LDO(VAUX2, 0x1b, 2, 100, 0x08),
+ TWL_ADJUSTABLE_LDO(VAUX3, 0x1f, 3, 100, 0x08),
+ TWL_ADJUSTABLE_LDO(VAUX4, 0x23, 4, 100, 0x08),
+ TWL_ADJUSTABLE_LDO(VMMC1, 0x27, 5, 100, 0x08),
+ TWL_ADJUSTABLE_LDO(VMMC2, 0x2b, 6, 100, 0x08),
+ TWL_ADJUSTABLE_LDO(VPLL1, 0x2f, 7, 100, 0x00),
+ TWL_ADJUSTABLE_LDO(VPLL2, 0x33, 8, 100, 0x08),
+ TWL_ADJUSTABLE_LDO(VSIM, 0x37, 9, 100, 0x00),
+ TWL_ADJUSTABLE_LDO(VDAC, 0x3b, 10, 100, 0x08),
+ TWL_FIXED_LDO(VINTANA1, 0x3f, 1500, 11, 100, 0x08),
+ TWL_ADJUSTABLE_LDO(VINTANA2, 0x43, 12, 100, 0x08),
+ TWL_FIXED_LDO(VINTDIG, 0x47, 1500, 13, 100, 0x08),
+ TWL_ADJUSTABLE_LDO(VIO, 0x4b, 14, 1000, 0x08),
+ TWL_ADJUSTABLE_LDO(VDD1, 0x55, 15, 1000, 0x08),
+ TWL_ADJUSTABLE_LDO(VDD2, 0x63, 16, 1000, 0x08),
+ TWL_FIXED_LDO(VUSB1V5, 0x71, 1500, 17, 100, 0x08),
+ TWL_FIXED_LDO(VUSB1V8, 0x74, 1800, 18, 100, 0x08),
+ TWL_FIXED_LDO(VUSB3V1, 0x77, 3100, 19, 150, 0x08),
/* VUSBCP is managed *only* by the USB subchip */
};
-static const u8 REG_REMAP_table[] = {
- 0x08, 0x08, 0x08, 0x08, 0x00, 0x08, 0x08,
- 0x08, 0x00, 0x08, 0x08, 0x08, 0x08, 0x08,
- 0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x08,
- 0x08,
-};
-
static int twl4030reg_probe(struct platform_device *pdev)
{
int i;
@@ -482,7 +487,7 @@ static int twl4030reg_probe(struct platform_device *pdev)
}
platform_set_drvdata(pdev, rdev);
- twl4030reg_write(info, VREG_REMAP, REG_REMAP_table[pdev->id]);
+ twl4030reg_write(info, VREG_REMAP, info->remap);
/* NOTE: many regulators support short-circuit IRQs (presentable
* as REGULATOR_OVER_CURRENT notifications?) configured via:
--
1.6.3.3
On Fri, Dec 11, 2009 at 09:53:51AM +0200, Juha Keski-Saari wrote:
> Extend the twlreg_info structure to hold the turnon delay and remap config
> value for regulators, and implement turnon delay in reg_enable
Hrm, what exactly are these parameters? Are they for inital power
sequencing or runtime things?
but for the default setting this does
Acked-by: Mark Brown <[email protected]>
On Fri, 2009-12-11 at 11:35 +0100, ext Mark Brown wrote:
> On Fri, Dec 11, 2009 at 09:53:51AM +0200, Juha Keski-Saari wrote:
> > Extend the twlreg_info structure to hold the turnon delay and remap config
> > value for regulators, and implement turnon delay in reg_enable
>
> Hrm, what exactly are these parameters? Are they for inital power
> sequencing or runtime things?
>
> but for the default setting this does
>
> Acked-by: Mark Brown <[email protected]>
The remap configuration is as before, just put in a nicer form to group
the values better with the regulator definitions, restoring the REMAP
configuration was intended as an initial step after bootloader to make
sure we know the configuration.
The turnon delay values are quoted by the TWL4030 Data manual as the
maximum time it may take for the regulator to reach full output after it
has been turned on. The DM also quotes a maximum wakeup time for
returning from sleep to full output, but that delay is much shorter. For
some regulators the turnon delay is theoretically long enough for the
reg_enable to return to the driver noticeably earlier than the regulator
output is actually at target level.
On Mon, Dec 14, 2009 at 09:05:17AM +0200, Juha Keski-Saari wrote:
> has been turned on. The DM also quotes a maximum wakeup time for
> returning from sleep to full output, but that delay is much shorter. For
> some regulators the turnon delay is theoretically long enough for the
> reg_enable to return to the driver noticeably earlier than the regulator
> output is actually at target level.
OK. This ramp rate thing is a general issue for regulators, especially
those that are controlled via GPIOs rather than I2C since for them the
control interface takes approximately zero time to respond. Ideally we
want to do something slightly more involved than what you've got here
since if you're turning on more than one regulator at once it'd be nice
to be able to allow all the supplies to ramp in parallel rather than
serialising everything.
I've got a patch half done for this which I should try to finish off and
post soon but for now this should be OK.