From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Graeme Gregory <gg@slimlogic.co.uk>
Cc: linux-kernel@vger.kernel.org, lrg@ti.com
Subject: Re: [PATCH] REGULATOR: core add 3 new modes/statuses
Date: Wed, 21 Mar 2012 11:49:46 +0000 [thread overview]
Message-ID: <20120321114944.GA3226@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4F69B254.1000603@slimlogic.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2844 bytes --]
On Wed, Mar 21, 2012 at 10:49:56AM +0000, Graeme Gregory wrote:
> On 21/03/2012 00:29, Mark Brown wrote:
> > On Tue, Mar 20, 2012 at 09:50:58PM +0000, Graeme Gregory wrote:
> >> USBBOOST this effectively turns the regulator around instead of using
> > In theory this could be done by other things so we should probably have
> > a better name, though in practice I'd be surprised to see many others.
> > It does totally break the idea of a mode, though - it's a massive change
> > in what the regulator does.
> Im not attached to the name, I just chose it as BOOST is a type of SMPS
> as well as being the common name for this function within TI. I do see
> what you mean by it not really fitting the "mode" descriptor well!
Plain BOOST does seem OK as a name - it was the USB bit.
> > Like I say I'm not entirely clear here, I keep meaning to try coding up
> > the custom API and see how it feels using it in a system - any thoughts?
> > Probably won't take me that long...
> This Im not really sure on, I don't see much info on the actual use of
> bypass mode in real devices yet. twl6035 uses it to power LDOUSB direct
> from USB bus intead of using the internal SMPS. But so far that is the
> only usecase I know of. Which of course means in bypass mode we not only
> have to change parent to some non existent virtual regulator but also
> enabled bypass mode.
There's some other stuff deployed already, though mostly internally to
drivers as the regulators concerned aren't generic regulators but are
internal to the device.
> > You also get this for ganging multiple regulators together to give a
> > higher power output, though normally you want variability so this has to
> > be handled at the hardware level. This one also has an impact on how we
> > handle voltage changes, it'd be good if we could arrange things so that
> > get_voltage() and set_voltage() work through/with a regulator that's
> > tracking.
> I could see this also working if you set a parent regulator with a
> TRACKING flag so the framework knows the link. The other thing to
> consider is the twl6035 when you disable the parent SMPS on the LDO in
> tracking mode the LDO then switches to non tracking mode and uses its
> own configuration. When you turn SMPS back on it switch back to tracking
> mode.
That one is even more fun, it's relatively straightforward if they both
have the same configuration but otherwise...
> Altogether it looks like adding these features requires a lot more work
> than I had originally hoped :-(
> I guess the best way for me to proceed is to start to think about each
> of these "modes" individually and see what support I actually need from
> regulator framework to get them implemented.
Yeah, probably. It's more likely something will happen about bypass
mode without you doing anything but I wouldn't rely on it.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2012-03-21 11:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-20 21:50 [RFC] REGULATOR: core add 3 new modes/statuses Graeme Gregory
2012-03-20 21:50 ` [PATCH] " Graeme Gregory
2012-03-21 0:29 ` Mark Brown
2012-03-21 10:49 ` Graeme Gregory
2012-03-21 11:49 ` Mark Brown [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120321114944.GA3226@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=gg@slimlogic.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.