On 13:15-20130402, Grygorii Strashko wrote:
> On 04/02/2013 06:35 AM, Nishanth Menon wrote:
> >On 17:05-20130401, Mike Turquette wrote:
> >>OK, so we're in agreement on what The Future looks like. What does that
> >>mean for Andrii's patchset?
> >Unless anyone has an fundamental issue with the approach of an "Super
> >regulator" controlling "sub regulators", I think, in-line with your
> >view, we should probably make ABB as an regulator instead of inventing
> >our own API and hooking it around clock notifiers.
> Hi Nishanth, All
> One question here, regarding "Super regulator" - How are you going
> to differentiate
> OPP changing and AVS Voltage adjustment requests to the "Super regulator"??
> As you know, to select OPP changing direction, ABB type (or VC/VP
> parameters)
> properly you need Nominal (and only Nominal) voltage as input.
> And in real world, AVS can adjust voltage, as example, for OPP100
> even low than for OPP50.
> OMAP4 example:
> MPU OPP Vsr Vnom ABB
> OPP50 0.862249970436096 1.025 NOM
> OPP100 1.03509700298309 1.2 NOM
> OPPTurbo 1.09257805347443 1.325 NOM
> OPPNitro 1.18703103065491 1.388 FAST
> OPPNitroSB 1.29427194595337 1.398 FAST
> So, while adjusting voltage, AVS can hit other OPP voltage and, as
> result, ABB mode may be changed.
The expectation is that we will use Vnom in the "super regulator". Vnom
does not change per OPP across devices. Expectation will be to use Vnom
as indexing key inside regulator framework.
>
> I think, your vision would be more clear if you could be able to
> provide Sequence diagram in addition.
I should be able to do better, I should be able to post a RFC revision
of the "super regulator" verifiable on Beagle XM using I2C1 (instead of
i2c_sr) as start, I will give it hooks to handle "Efuse Vnom" support
which our upcoming SoC needs as well.
>
> And would it be allowed to use DT for such regulator chain definitions
> (or board-generic.c should be used instead), just for clarification,
> because I have not to much DT experience:
> omap443x.dtsi:
> vdd_mpu: regulator-omap-ti1 { << -- Super regulator
I would not link only *OMAP* to this - as originally stated, this is
needed by OMAP, AM, DM and potentially, Keystone family of TI
processors.
How about we debate this with the "super regulator" patch?
[...]
--
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
