Re: [PATCH V4 1/3] OPP: Redefine bindings to overcome shortcomings

[Nishanth Menon <nm@ti.com>]

On 05/12/2015 02:41 PM, Mark Brown wrote:
> On Tue, May 12, 2015 at 02:14:19PM -0500, Nishanth Menon wrote:
> 
>> While TWLxx series was kind of nascent in it's ability of choosing
>> PWM/PFM or auto mode depending on the current targets, newer PMICs
>> have their own unique techniques -> but, that said, this is a
>> description of power consumption for a given OPP for the "device", How
>> would stephen's case work with a PMIC and 2 devices which have
>> different leakage characteristics (based on which end of the process
>> spectrum they come from), Lets take an example:
>> device X consumes 800mA for OPPx
>> device Y consumes 900mA for OPPy
uggh... should have been OPPx here.

> 
> The system integrator would need to be somewhat conservative when
> specifying the currents involved.  For plausible applications these are
> likely to be ballpark figures rather than anything too accurate - if
> nothing else the instantaneous current draw normally varies very
> substantially so realistically you're talking about a maximum here.  If
> the corners vary that dramatically then I'd expect you'd see different
> OPP tables being used anyway.

OK - If we state "worst case", then it is quantifiable (if SoC vendors
would like to expose such information - I doubt mine ever will ;) ).

- We might be able to quantify it better by stating worst case(under
maximum load) steady state current (to avoid including transient
spikes which are never representative) at ambient temperature(25C).

Current draw for a given OPP across temperature ranges are substantial
enough even for a given chip - most of us in SoC PM world have already
seen enough characterization graphs across process and temperature to
realize that.

>> It is a lot more impactful than using relative numbers for other
>> purposes - for example energy aware scheduling as an example -> here
>> the actuals might have better optimization, but hints of relative
>> power numbers by itself is pretty powerful information to help
>> scheduling. The usage, in this case, unlike the usage for a PMIC
>> efficiency selection, is not based on absolutes and is meant more of a
>> hint (closer to usage such as clock transition latency numbers).
> 
> You're not comparing two similar types of object here, you're trying to
> provide information on an actual physical value to get fed into other
> actual physical values.
> 

True - I was trying to highlight how the same "consumption data" could
be interpreted differently. Hence my request for more clarity on the
description. By describing the specificity of current consumption, the
binding should ideally prevent mis-interpretation in usage elsewhere.

-- 
Regards,
Nishanth Menon