Re: [RFC PATCH 5/6] ARM: OMAP3+: ABB: introduce ABB driver

[Nishanth Menon <nm@ti.com>]

On 14:34-20130401, Mike Turquette wrote:
> Quoting Nishanth Menon (2013-04-01 12:28:20)
> > On Mon, Apr 1, 2013 at 1:10 PM, Mike Turquette <mturquette@linaro.org> wrote:
> > > Let's figure out what is happening to the VC/VP code first and then
> > > figure out what to do about ABB.
> > >
> > http://picpaste.com/KmqDYTn0.jpg
> > is an quick depiction of the thought I have in my mind.
> > 
> 
> OK, looks like the Super Regulator Approach(tm).
:D I hope it can be modelled after TI SoCs and then expanded to other
SoCs as needed.
> 
> > We do have, in the upcoming SoCs, where Nominal Voltages per device,
> > will now be encoded into the efuse itself(so called class 0 voltage).
> > Future SoCs will need to be able to use ABB along with standard
> > regulators (without use of VC-VP) - in fact, even today, SoCs like AM
> > and DM series of processors have the same requirement.
> > 
> 
> This de-linking of ABB from VC/VP probably supports modeling ABB ldo's
> as Linux regulators.  That would provide a common interface where either
> the VC/VP code or another regulator could call something like
> regulator_set_mode.
> 
> If we're going to export something which can get called by different
> actors it's best to use an already exported interface which the
> regulator framework supplies, instead of exporting something new and
> omap-specific.
Yep - that was my original thought - though modeling it as a regulator
in itself is, IMHO, I think is a good idea.

> 
> > We also will have to support class 2 variants of AVS (which will use
> > standard regulators to set voltage).
> > 
> > As of date, CCF does not control regulators - which means the interim
> > solution would be for the device control to manipulate both clock and
> > regulator voltage (similar to what cpufreq-cpu0 driver does today).
> > these drivers should not know the existance of SoC specific
> > intricacies - so ABB linked to voltage values make more sense if ABB
> > sequencing is handled in "TI regulator"
> > 
> > Intent of VC/VP regulator is to be replaceable, on required platforms,
> > with appropriate regulator which do not use VC/VP paths (e.g. on SoCs
> > that do not have it).
> > 
> 
> Well if everything is nicely modeled then I suppose per-board and
> per-soc DT will give you the ability to link things up nicely.  E.g.
> replacing VC/VP with an external physical LDO, etc.

True - that is precisely what are attempting to do in (hopefully) edible
stages :).

-- 
Regards,
Nishanth Menon