Re: [RFC 2/2] PM / OPP: extend DT parsing to allow voltage ranges

[Nishanth Menon <nm@ti.com>]

On Tue, May 20, 2014 at 9:41 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
> Am Dienstag, den 20.05.2014, 09:32 -0500 schrieb Nishanth Menon:
>> On 05/20/2014 09:27 AM, Lucas Stach wrote:
>> > Following the introduction of voltage ranges into OPP
>> > we need a way to encode them in the device tree in a
>> > similar fashion to the non-ranged versions.
>> >
>> > To keep compatibility with old DTs the parsing function
>> > is changed to understand both versions.
>> >
>> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
>> > ---
>> >  Documentation/devicetree/bindings/power/opp.txt | 23 ++++++++++++++++++
>> >  drivers/base/power/opp.c                        | 31 ++++++++++++++++++-------
>> >  2 files changed, 46 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt
>> > index 74499e5033fc..5b520ff321f5 100644
>> > --- a/Documentation/devicetree/bindings/power/opp.txt
>> > +++ b/Documentation/devicetree/bindings/power/opp.txt
>> > @@ -10,6 +10,16 @@ Properties:
>> >     freq: clock frequency in kHz
>> >     vol: voltage in microvolt
>> >
>> > +or
>> > +
>> > +- operating-points-range: An array of 4-tuple items, each item consisting
>> > +  of a frequency and a related voltage range in the following form:
>> > +  <freq min-vol-uV nom-vol-uV max-vol-uV>
>> > +   freq: clock frequency in kHz
>> > +   min-vol-uV: absolute minimum required voltage for this frequency
>> > +   nom-vol-uV: nominal voltage for this frequency
>> > +   max-vol-uV: absolute maximum allowed voltage for this frequency
>>
>> And, Why cant we function at min-volt-uV? because PMIC cannot support
>> it? then why add voltage tolerance? This is not clear in the dt
>> description.
>>
> The min-vol-uV is meant as the absolute minimum voltage where the device
> is still able to work.
> But still vendors are giving nominal voltages that should be met if
> possible. So for example for a CPU device we might always want to try to
> match the nominal voltage, but in case the regulator isn't able to
> supply a this voltage it's still ok to use a voltage in the
> min...nominal range.

So,the chip either is supposed to function OR not function for a
frequency at a voltage right?

Then, we have a problem here -> if min_uV is selected by a regulator
(for the sake of argument), then device is expected to function. So,
then why choose nom_uV on a regulator that can do min_uV? if the
device is NOT *guaranteed* to work at min_uV, then defining min_uV as
"functional voltage if nom_uV is not available" is wrong as well - no?

Is'nt that a wrong definition?


>
> Another case may be where we are scaling CPU voltage and have to
> maintain a certain voltage difference between CPU and SoC power domain.
> So there may be cases where we might decide that it's better (faster) to
> scale CPU only to it's min voltage to avoid touching the SoC regulator.

That is not the job of OPP definition for device X - voltage domain to
voltage domain dependency is part of something else (for example: an
voltage domain driver like an RFC[1] or equivalent)

[1]
http://marc.info/?l=linux-omap&m=139275579731801&w=2

--
Regards,
Nishanth Menon