Messages in this thread | | | Date | Wed, 21 Mar 2012 11:49:46 +0000 | From | Mark Brown <> | Subject | Re: [PATCH] REGULATOR: core add 3 new modes/statuses |
| |
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. [unhandled content-type:application/pgp-signature] | |