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@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
