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] " 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®