| Message ID | 49B11EB0.30809@nokia.com (mailing list archive) |
|---|---|
| State | Awaiting Upstream, archived |
| Headers | show |
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 <adrian.hunter@nokia.com> Applied. Thanks Liam -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <adrian.hunter@nokia.com> > --- > > 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 > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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),
TWL4030 and TWL5030 support 3.0V on VAUX3. Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com> --- According to TI: http://community.ti.com/forums/t/3777.aspx drivers/regulator/twl4030-regulator.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)