TWL4030 and TWL5030 support 3.0V on VAUX3.
Signed-off-by: Adrian Hunter <[email protected]>
---
According to TI:
http://community.ti.com/forums/t/3777.aspx
drivers/regulator/twl4030-regulator.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator/twl4030-regulator.c b/drivers/regulator/twl4030-regulator.c
index 8655443..1755026 100644
--- a/drivers/regulator/twl4030-regulator.c
+++ b/drivers/regulator/twl4030-regulator.c
@@ -224,7 +224,7 @@ static const u16 VAUX2_VSEL_table[] = {
};
static const u16 VAUX3_VSEL_table[] = {
1500, 1800, 2500, 2800,
- UNSUP(3000), UNSUP(3000), UNSUP(3000), UNSUP(3000),
+ 3000, 3000, 3000, 3000,
};
static const u16 VAUX4_VSEL_table[] = {
700, 1000, 1200, UNSUP(1300),
--
1.5.6.3
On Fri, 2009-03-06 at 15:01 +0200, Adrian Hunter wrote:
> TWL4030 and TWL5030 support 3.0V on VAUX3.
>
> Signed-off-by: Adrian Hunter <[email protected]>
Applied.
Thanks
Liam
On Friday 06 March 2009, Adrian Hunter wrote:
> TWL4030 and TWL5030 support 3.0V on VAUX3.
I double checked several technical reference manuals, and they
say otherwise. The 3.0V settings in VAUX3_DEDICATED are very
consistently labeled as "TI cannot support these values", for
all current versions of chips with a VAUX3 supply:
TWL4030 ES3.1
TWL5030 ES1.1
TPS65930 ES1.0 (more or less a cost-reduced TWL5030)
TPS65950 ES1.0 (more or less TWL5030)
So, NAK on this.
Do you really need 3.0V out of that regulator? If so,
then I'd rather see a patch exposing that CONFIG_*
setting to enable all the unsupported/out-of-range
values, rather than just selectively hacking those
tables to permit some (but not all) of them to be used
out-of-range.
> Signed-off-by: Adrian Hunter <[email protected]>
> ---
>
> According to TI:
> http://community.ti.com/forums/t/3777.aspx
That looks to me like some random TI developer reading the
manual and ignoring the label on those settings: Yes if you
set that value it'll probably work. But no, if you rely on
that it's working out-of-spec, and is clearly marked as such.
>
>
> drivers/regulator/twl4030-regulator.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/regulator/twl4030-regulator.c b/drivers/regulator/twl4030-regulator.c
> index 8655443..1755026 100644
> --- a/drivers/regulator/twl4030-regulator.c
> +++ b/drivers/regulator/twl4030-regulator.c
> @@ -224,7 +224,7 @@ static const u16 VAUX2_VSEL_table[] = {
> };
> static const u16 VAUX3_VSEL_table[] = {
> 1500, 1800, 2500, 2800,
> - UNSUP(3000), UNSUP(3000), UNSUP(3000), UNSUP(3000),
> + 3000, 3000, 3000, 3000,
> };
> static const u16 VAUX4_VSEL_table[] = {
> 700, 1000, 1200, UNSUP(1300),
> --
> 1.5.6.3
>
>
On Fri, Mar 06, 2009 at 11:16:20AM -0800, David Brownell wrote:
> Do you really need 3.0V out of that regulator? If so,
> then I'd rather see a patch exposing that CONFIG_*
> setting to enable all the unsupported/out-of-range
> values, rather than just selectively hacking those
> tables to permit some (but not all) of them to be used
> out-of-range.
Would it make sense to make this platform data so that if a given board
requires running the chip like this it can be enabled for those boards
but it's not something people might turn on because it seems useful?
On Friday 06 March 2009, Mark Brown wrote:
> Would it make sense to make this platform data so that if a given board
> requires running the chip like this it can be enabled for those boards
> but it's not something people might turn on because it seems useful?
Let's hear if it's actually needed, first. :)
I coded those tables so that it would be easy to kick in the
support for out-of-spec operation if it's really needed. But
so far we don't know that it's needed, and I'd rather it not
be too easy to run like that.
- Dave
On Fri, 2009-03-06 at 14:48 -0800, David Brownell wrote:
> On Friday 06 March 2009, Mark Brown wrote:
> > Would it make sense to make this platform data so that if a given board
> > requires running the chip like this it can be enabled for those boards
> > but it's not something people might turn on because it seems useful?
>
> Let's hear if it's actually needed, first. :)
>
> I coded those tables so that it would be easy to kick in the
> support for out-of-spec operation if it's really needed. But
> so far we don't know that it's needed, and I'd rather it not
> be too easy to run like that.
>
I've now reverted this patch.
Liam
Liam Girdwood wrote:
> On Fri, 2009-03-06 at 14:48 -0800, David Brownell wrote:
>> On Friday 06 March 2009, Mark Brown wrote:
>>> Would it make sense to make this platform data so that if a given board
>>> requires running the chip like this it can be enabled for those boards
>>> but it's not something people might turn on because it seems useful?
>> Let's hear if it's actually needed, first. :)
>>
>> I coded those tables so that it would be easy to kick in the
>> support for out-of-spec operation if it's really needed. But
>> so far we don't know that it's needed, and I'd rather it not
>> be too easy to run like that.
>>
>
> I've now reverted this patch.
TI say we can use VAUX3 at 3V and expect no problems:
http://community.ti.com/forums/p/3777/14574.aspx
So how do we do it?
On Tue, 2009-03-17 at 09:36 +0200, Adrian Hunter wrote:
> Liam Girdwood wrote:
> > On Fri, 2009-03-06 at 14:48 -0800, David Brownell wrote:
> >> On Friday 06 March 2009, Mark Brown wrote:
> >>> Would it make sense to make this platform data so that if a given board
> >>> requires running the chip like this it can be enabled for those boards
> >>> but it's not something people might turn on because it seems useful?
> >> Let's hear if it's actually needed, first. :)
> >>
> >> I coded those tables so that it would be easy to kick in the
> >> support for out-of-spec operation if it's really needed. But
> >> so far we don't know that it's needed, and I'd rather it not
> >> be too easy to run like that.
> >>
> >
> > I've now reverted this patch.
>
> TI say we can use VAUX3 at 3V and expect no problems:
>
> http://community.ti.com/forums/p/3777/14574.aspx
>
> So how do we do it?
I'd prefer seeing the reply from Ghandar to David's last question before
accepting this patch again. It's still not 100% clear from TI, things
seem a little bit muddled as to whether 3V will be guaranteed to work on
*all* shipped devices.
Thanks
Liam
Liam Girdwood wrote:
> On Tue, 2009-03-17 at 09:36 +0200, Adrian Hunter wrote:
>> Liam Girdwood wrote:
>>> On Fri, 2009-03-06 at 14:48 -0800, David Brownell wrote:
>>>> On Friday 06 March 2009, Mark Brown wrote:
>>>>> Would it make sense to make this platform data so that if a given board
>>>>> requires running the chip like this it can be enabled for those boards
>>>>> but it's not something people might turn on because it seems useful?
>>>> Let's hear if it's actually needed, first. :)
>>>>
>>>> I coded those tables so that it would be easy to kick in the
>>>> support for out-of-spec operation if it's really needed. But
>>>> so far we don't know that it's needed, and I'd rather it not
>>>> be too easy to run like that.
>>>>
>>> I've now reverted this patch.
>> TI say we can use VAUX3 at 3V and expect no problems:
>>
>> http://community.ti.com/forums/p/3777/14574.aspx
>>
>> So how do we do it?
>
> I'd prefer seeing the reply from Ghandar to David's last question before
> accepting this patch again. It's still not 100% clear from TI, things
> seem a little bit muddled as to whether 3V will be guaranteed to work on
> *all* shipped devices.
Ghandar has responded. What would you like to do?
On Wednesday 25 March 2009, Adrian Hunter wrote:
> >> http://community.ti.com/forums/p/3777/14574.aspx
> >>
> >> So how do we do it?
> >
> > I'd prefer seeing the reply from Ghandar to David's last question before
> > accepting this patch again. It's still not 100% clear from TI, things
> > seem a little bit muddled as to whether 3V will be guaranteed to work on
> > *all* shipped devices.
>
> Ghandar has responded. ?What would you like to do?
Update the patch to include a comment (by the table def)
that TI says they're revising the twl5030/tps659x0 specs
to support that 3.0V setting, then merge it.
(Umm, though I'd be sure to find out specifically which
selectors they're supporting that way, first...)
I don't think they'll be revising specs on chips they've
shipped already ... but this isn't likely to matter on
those older systems, anyway; example, the 3430 SDP uses
VAUX3, but at the always-supported 2.8V setting.
>From 51f946af56a5de9c25b2eb6e6a33660283f84195 Mon Sep 17 00:00:00 2001
From: Adrian Hunter <[email protected]>
Date: Fri, 6 Mar 2009 14:51:30 +0200
Subject: [PATCH] regulator: twl4030 VAUX3 supports 3.0V
TWL4030 and TWL5030 support 3.0V on VAUX3.
Signed-off-by: Adrian Hunter <[email protected]>
---
drivers/regulator/twl4030-regulator.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator/twl4030-regulator.c b/drivers/regulator/twl4030-regulator.c
index f3ec98c..e2032fb 100644
--- a/drivers/regulator/twl4030-regulator.c
+++ b/drivers/regulator/twl4030-regulator.c
@@ -193,6 +193,9 @@ static int twl4030reg_set_mode(struct regulator_dev *rdev, unsigned mode)
*
* VSEL values documented as "TI cannot support these values" are flagged
* in these tables as UNSUP() values; we normally won't assign them.
+ *
+ * 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
@@ -223,7 +226,7 @@ static const u16 VAUX2_VSEL_table[] = {
};
static const u16 VAUX3_VSEL_table[] = {
1500, 1800, 2500, 2800,
- UNSUP(3000), UNSUP(3000), UNSUP(3000), UNSUP(3000),
+ 3000, 3000, 3000, 3000,
};
static const u16 VAUX4_VSEL_table[] = {
700, 1000, 1200, UNSUP(1300),
--
1.5.6.3
On Thu, 2009-03-26 at 16:21 +0200, Adrian Hunter wrote:
> >From 51f946af56a5de9c25b2eb6e6a33660283f84195 Mon Sep 17 00:00:00 2001
> From: Adrian Hunter <[email protected]>
> Date: Fri, 6 Mar 2009 14:51:30 +0200
> Subject: [PATCH] regulator: twl4030 VAUX3 supports 3.0V
>
> TWL4030 and TWL5030 support 3.0V on VAUX3.
>
> Signed-off-by: Adrian Hunter <[email protected]>
> ---
> drivers/regulator/twl4030-regulator.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
Applied.
Thanks
Liam