From: Linus Walleij <[email protected]>
This switches the ab3100 core to use the enable_time()
infrastructure from the regulator core.
Cc: Mattias Wallin <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
---
drivers/regulator/ab3100.c | 51 ++++++++++++++++++++++++-------------------
1 files changed, 28 insertions(+), 23 deletions(-)
diff --git a/drivers/regulator/ab3100.c b/drivers/regulator/ab3100.c
index ed6feaf..585e494 100644
--- a/drivers/regulator/ab3100.c
+++ b/drivers/regulator/ab3100.c
@@ -205,29 +205,6 @@ static int ab3100_enable_regulator(struct regulator_dev *reg)
return err;
}
- /* Per-regulator power on delay from spec */
- switch (abreg->regreg) {
- case AB3100_LDO_A: /* Fallthrough */
- case AB3100_LDO_C: /* Fallthrough */
- case AB3100_LDO_D: /* Fallthrough */
- case AB3100_LDO_E: /* Fallthrough */
- case AB3100_LDO_H: /* Fallthrough */
- case AB3100_LDO_K:
- udelay(200);
- break;
- case AB3100_LDO_F:
- udelay(600);
- break;
- case AB3100_LDO_G:
- udelay(400);
- break;
- case AB3100_BUCK:
- mdelay(1);
- break;
- default:
- break;
- }
-
return 0;
}
@@ -449,11 +426,37 @@ static int ab3100_get_voltage_regulator_external(struct regulator_dev *reg)
return abreg->plfdata->external_voltage;
}
+static int ab3100_enable_time_regulator(struct regulator_dev *reg)
+{
+ struct ab3100_regulator *abreg = reg->reg_data;
+
+ /* Per-regulator power on delay from spec */
+ switch (abreg->regreg) {
+ case AB3100_LDO_A: /* Fallthrough */
+ case AB3100_LDO_C: /* Fallthrough */
+ case AB3100_LDO_D: /* Fallthrough */
+ case AB3100_LDO_E: /* Fallthrough */
+ case AB3100_LDO_H: /* Fallthrough */
+ case AB3100_LDO_K:
+ return 200;
+ case AB3100_LDO_F:
+ return 600;
+ case AB3100_LDO_G:
+ return 400;
+ case AB3100_BUCK:
+ return 1000;
+ default:
+ break;
+ }
+ return 0;
+}
+
static struct regulator_ops regulator_ops_fixed = {
.enable = ab3100_enable_regulator,
.disable = ab3100_disable_regulator,
.is_enabled = ab3100_is_enabled_regulator,
.get_voltage = ab3100_get_voltage_regulator,
+ .enable_time = ab3100_enable_time_regulator,
};
static struct regulator_ops regulator_ops_variable = {
@@ -463,6 +466,7 @@ static struct regulator_ops regulator_ops_variable = {
.get_voltage = ab3100_get_voltage_regulator,
.set_voltage = ab3100_set_voltage_regulator,
.list_voltage = ab3100_list_voltage_regulator,
+ .enable_time = ab3100_enable_time_regulator,
};
static struct regulator_ops regulator_ops_variable_sleepable = {
@@ -473,6 +477,7 @@ static struct regulator_ops regulator_ops_variable_sleepable = {
.set_voltage = ab3100_set_voltage_regulator,
.set_suspend_voltage = ab3100_set_suspend_voltage_regulator,
.list_voltage = ab3100_list_voltage_regulator,
+ .enable_time = ab3100_enable_time_regulator,
};
/*
--
1.7.3.2
On Fri, Mar 11, 2011 at 04:26:18PM +0100, Linus Walleij wrote:
> From: Linus Walleij <[email protected]>
>
> This switches the ab3100 core to use the enable_time()
> infrastructure from the regulator core.
Acked-by: Mark Brown <[email protected]>
On Fri, Mar 11, 2011 at 4:31 PM, Mark Brown
<[email protected]> wrote:
> On Fri, Mar 11, 2011 at 04:26:18PM +0100, Linus Walleij wrote:
>> From: Linus Walleij <[email protected]>
>>
>> This switches the ab3100 core to use the enable_time()
>> infrastructure from the regulator core.
>
> Acked-by: Mark Brown <[email protected]>
Mark can you pick this into the regulator tree? I have sent my ux500
tree upstream.
Yours,
Linus Walleij
On Mon, Mar 14, 2011 at 05:42:28PM +0100, Linus Walleij wrote:
> Mark can you pick this into the regulator tree? I have sent my ux500
> tree upstream.
No, I can't do that - mostly because Liam manages the regulator tree and
not me :)
On Mon, Mar 14, 2011 at 7:15 PM, Mark Brown
<[email protected]> wrote:
> On Mon, Mar 14, 2011 at 05:42:28PM +0100, Linus Walleij wrote:
>
>> Mark can you pick this into the regulator tree? I have sent my ux500
>> tree upstream.
>
> No, I can't do that - mostly because Liam manages the regulator tree and
> not me :)
Ah yeah now I remember. Liam, please?
Yours,
Linus Walleij
On Fri, 2011-03-11 at 15:31 +0000, Mark Brown wrote:
> On Fri, Mar 11, 2011 at 04:26:18PM +0100, Linus Walleij wrote:
> > From: Linus Walleij <[email protected]>
> >
> > This switches the ab3100 core to use the enable_time()
> > infrastructure from the regulator core.
>
> Acked-by: Mark Brown <[email protected]>
Applied.
Thanks
Liam
On Tue, 2011-03-15 at 10:07 +0100, Linus Walleij wrote:
> On Mon, Mar 14, 2011 at 7:15 PM, Mark Brown
> <[email protected]> wrote:
> > On Mon, Mar 14, 2011 at 05:42:28PM +0100, Linus Walleij wrote:
> >
> >> Mark can you pick this into the regulator tree? I have sent my ux500
> >> tree upstream.
> >
> > No, I can't do that - mostly because Liam manages the regulator tree and
> > not me :)
>
> Ah yeah now I remember. Liam, please?
>
Now done. Sorry very busy atm.
Btw, you have a few other regulator patches recently in amongst MFD and
ARM updates. I assume these will go via MFD ?
Thanks
Liam
2011/3/16 Liam Girdwood <[email protected]>:
> Btw, you have a few other regulator patches recently in amongst MFD and
> ARM updates. I assume these will go via MFD ?
The TPS6105x stuff will go through MFD, hopefully.
There are two other AB8500 regulator patches which are ripe
for merge through the regulator tree right now, and that's the
ones with Subjects:
"[PATCH 1/4] regulator: add support for USB voltage regulator"
"[PATCH 3/4] regulator: initialization for ab8500 regulators"
Both have Mark's ACK, and I think they apply cleanly in
that order. If there are any problems, tell me and I'll respin.
The platform data [4/4] can be applied out-of-order so I will
bring that in later.
The last patch [2/4] needs some refactoring and a consumer
interface that I'm working on in accordance with Mark's
directions, but that's a separate issue.
Yours,
Linus Walleij
On Wed, Mar 16, 2011 at 01:43:25PM +0100, Linus Walleij wrote:
> 2011/3/16 Liam Girdwood <[email protected]>:
> > Btw, you have a few other regulator patches recently in amongst MFD and
> > ARM updates. I assume these will go via MFD ?
> The TPS6105x stuff will go through MFD, hopefully.
Note that this isn't 100% required for new drivers - since you have a
dependency on the MFD you can merge subdevices through their own trees
and they won't cause problems as they can't be built until the MFD is
merged and makes the core symbol available.
On Wed, 2011-03-16 at 13:43 +0100, Linus Walleij wrote:
> 2011/3/16 Liam Girdwood <[email protected]>:
>
> > Btw, you have a few other regulator patches recently in amongst MFD and
> > ARM updates. I assume these will go via MFD ?
>
> The TPS6105x stuff will go through MFD, hopefully.
>
> There are two other AB8500 regulator patches which are ripe
> for merge through the regulator tree right now, and that's the
> ones with Subjects:
>
> "[PATCH 1/4] regulator: add support for USB voltage regulator"
> "[PATCH 3/4] regulator: initialization for ab8500 regulators"
>
> Both have Mark's ACK, and I think they apply cleanly in
> that order. If there are any problems, tell me and I'll respin.
Both look fine and have been applied.
Thanks
Liam
2011/3/16 Mark Brown <[email protected]>:
> On Wed, Mar 16, 2011 at 01:43:25PM +0100, Linus Walleij wrote:
>> 2011/3/16 Liam Girdwood <[email protected]>:
>
>> > Btw, you have a few other regulator patches recently in amongst MFD and
>> > ARM updates. I assume these will go via MFD ?
>
>> The TPS6105x stuff will go through MFD, hopefully.
>
> Note that this isn't 100% required for new drivers - since you have a
> dependency on the MFD you can merge subdevices through their own trees
> and they won't cause problems as they can't be built until the MFD is
> merged and makes the core symbol available.
Yep that's true in general, in this case the regulator driver is
extending a header file provided by the MFD core, so they need
to be kept in succession...
Linus Walleij