On Tue, Nov 29, 2011 at 16:49:49, Kristo, Tero wrote:
[...]
> >
> > Other TI PMICs like TPS65910 also have two I2C interfaces. Since
> > the datasheets refers to these as Control (CTL) and SmartReflex (SR) interfaces,
> > instead of the OMAP specific TWL_VP_SMPS_MODE, how about renaming the flag to
> > TWL_SR_SMPS_MODE?
>
> I was actually thinking about naming it something like SR mode, however
> I think I will drop the flag away as unnecessary once I add the function
> pointers for the voltage_get / voltage_scale in to the platform data.
>
Sounds ok.
> >
> > AFAIK the second I2C interface in all these PMICs is meant only
> > for the SMPS outputs. Moreover, which of the two interfaces to use
> > would be known during the init phase.
>
> Thats my understanding also.
>
> >
> > Is there a scenario where someone would want to change this at runtime?
>
> Only testing purposes come to my mind, it is easier to try out some
> interesting stuff if you can change it runtime, other than that, not
> really. This set is also setting the used mode during init time also,
> and there is no runtime configuration possibility.
>
So there's not much value is trying to implement runtime switch between
the interfaces in the driver.
> >
> > At least for TPS65910, it is possible to use the SR-I2C interface
> > just like the CTL interface. In other words, even SoCs which do not
> > have VP/VC can choose to change the SMPS voltage using the SR-I2C
> > interface. The only catch is that only the SMPS registers can be
> > accessed from this interface.
>
> Yea, the SR-I2C should be possible to use with non VP/VC setup, if
> someone really wanted to do this. If anybody would actually want to do
> it is another question, as you can control everything from the normal
> I2C control interface. If you don't have dedicated VP hardware, the use
> for the secondary I2C channel is not that obvious.
>
Well multi-processor scenario is something that come to mind. If there's
a different core which can also talk to the PMIC, it could use one and the
host processor can use another. There are obvious issues like race conditions
etc which have to be taken into account but it's very much possible.
> >
> > If this is the case with TWL series also, we could have non VP/VC
> > specific smps_get/set_voltage APIs for the SR-I2C interface which
> > SoCs with VP/VC override at init time. Note that the driver will have
> > two smps_get/set_voltage implementations, one corresponding to CTL-I2C
> > and the other corresponding to SR-I2C. During the init phase, which set
> > of APIs to use is indicated via a flag like TWL_SR_SMPS_MODE.
> >
> > With such a change, the voltage change during DVFS would also boil down
> > to normal regulator calls for changing the voltage. SoCs which do not
> > have the VP/VC functionality can use the default implementations
> > via the SR-I2C or CTL-I2C (decided at init time) and SoCs with VP/VC
> > use their specific implementations.
>
> Yea, for next version I am planning to add voltage_get / voltage_set and
> the voltagedomain pointer as platform data for the regulator, these can
> be defined if the user wants to use them, otherwise twl-regulator will
> use the default implementation.
>
Ok.
Regards,
Vaibhav
��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
