| Message ID | CAKohpo=09ZhXxh5Cm7Ww9Gy-AYRp9=j82tup6atVN+aOF8twdA@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, May 05, 2015 at 05:13:33PM +0530, Viresh Kumar wrote: > On 5 May 2015 at 16:27, Mark Brown <broonie@kernel.org> wrote: > > No, it doesn't - you're not answering the question about what this is > > for. > I don't know how this information will be used finally. Probably the > platform driver will do the configuration based on the volt-cur pair. I don't think we should be defining a binding without understanding what it is supposed to mean. > - opp-microamp: current in micro Amperes. It can contain entries for multiple > - regulators. > + regulators. This can be referenced (along with voltage and freqency) while > + programming the regulator. This still doesn't say what the value is supposed to mean which means it's not possible for someone to write generic code which handles the binding - saying that people can reference the value doesn't tell them how to interpret it. A limit? A nominal constant draw value? A value to regulate to? Those are all different things expressed as a current.
On 5 May 2015 at 22:42, Mark Brown <broonie@kernel.org> wrote: > This still doesn't say what the value is supposed to mean which means > it's not possible for someone to write generic code which handles the > binding - saying that people can reference the value doesn't tell them > how to interpret it. A limit? A nominal constant draw value? A value > to regulate to? Those are all different things expressed as a current. @Stephen: Can you please answer these queries please, so that we can get the bindings correctly ?
On 05/06, Viresh Kumar wrote: > On 5 May 2015 at 22:42, Mark Brown <broonie@kernel.org> wrote: > > This still doesn't say what the value is supposed to mean which means > > it's not possible for someone to write generic code which handles the > > binding - saying that people can reference the value doesn't tell them > > how to interpret it. A limit? A nominal constant draw value? A value > > to regulate to? Those are all different things expressed as a current. > > @Stephen: Can you please answer these queries please, so that we > can get the bindings correctly ? If you look at the cpufreq/clock/pmic code on our codeaurora.org tree you'll see that it's used to pass a value with uA units through the regulator_set_optimum_mode() API. The call to regulator_set_optimum_mode() is here[1], and the place where we parse the OPP table from DT is here[2]. My understanding is that with recent changes to the regulator framework, we would do a s/regulator_set_optimum_mode/regulator_set_load/ and things would otherwise be the same on the consumer side. On the regulator side, we would move the .get_optimum_mode op to .set_load instead of the hack where we write to the hardware in .get_optimum_mode[3]. So does that mean it corresponds to a limit, or a nominal constant draw value, or a value to regulator to? From what I can tell it's used to figure out how many phases to enable[4]. I suspect that means it's being used to figure out what value it should regulate to. In newer PMICs this is all done automatically, but at least for some of the PMICs we need to do it manually. [1] https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/clk/qcom/clock.c?h=msm-3.10#n96 [2] https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/clk/qcom/clock-krait-8974.c?h=msm-3.10#n584 [3] https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/arch/arm/mach-msm/krait-regulator.c?h=msm-3.10#n610 [4] https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/arch/arm/mach-msm/krait-regulator.c?h=msm-3.10#n486
On Wed, May 06, 2015 at 10:52:31PM -0700, Stephen Boyd wrote: > If you look at the cpufreq/clock/pmic code on our codeaurora.org > tree you'll see that it's used to pass a value with uA units > through the regulator_set_optimum_mode() API. The call to > regulator_set_optimum_mode() is here[1], and the place where we > parse the OPP table from DT is here[2]. My understanding is that I'm not looking for anyone to explain this to me in e-mail, what I'm looking for is for the binding document to be clear so someone can tell what the binding means by reading the documentation for the binding.
On 7 May 2015 at 11:22, Stephen Boyd <sboyd@codeaurora.org> wrote: > If you look at the cpufreq/clock/pmic code on our codeaurora.org > tree you'll see that it's used to pass a value with uA units > through the regulator_set_optimum_mode() API. The call to > regulator_set_optimum_mode() is here[1], and the place where we > parse the OPP table from DT is here[2]. My understanding is that > with recent changes to the regulator framework, we would do a > s/regulator_set_optimum_mode/regulator_set_load/ and things would > otherwise be the same on the consumer side. On the regulator > side, we would move the .get_optimum_mode op to .set_load instead > of the hack where we write to the hardware in > .get_optimum_mode[3]. > > So does that mean it corresponds to a limit, or a nominal > constant draw value, or a value to regulator to? From what I can > tell it's used to figure out how many phases to enable[4]. I > suspect that means it's being used to figure out what value it > should regulate to. In newer PMICs this is all done > automatically, but at least for some of the PMICs we need to do > it manually. By current phases, you probably meant [1], right ? Also what I couldn't understand is how are you controlling the current here? - Is this a current only regulator ? Probably not as your code has a uv value as well.. - Now if uV is fixed, how is the target current controlled separately ? - Should we have a min/max/target value of this current ? Like what we are doing for voltage. Or is this just the 'target' current ? - And finally how exactly should we write this in bindings to make it clear to all users ? Thanks. -- viresh [1] http://en.wikipedia.org/wiki/Three-phase_electric_power
On 05/07, Mark Brown wrote: > On Wed, May 06, 2015 at 10:52:31PM -0700, Stephen Boyd wrote: > > > If you look at the cpufreq/clock/pmic code on our codeaurora.org > > tree you'll see that it's used to pass a value with uA units > > through the regulator_set_optimum_mode() API. The call to > > regulator_set_optimum_mode() is here[1], and the place where we > > parse the OPP table from DT is here[2]. My understanding is that > > I'm not looking for anyone to explain this to me in e-mail, what I'm > looking for is for the binding document to be clear so someone can tell > what the binding means by reading the documentation for the binding. Ok. Perhaps the simplest thing to do then is to reuse wording from the regulator_set_load() API documentation? That's the only usage of this value I'm aware of. Something like: The current load of the device when using this OPP. Used to set the most efficient regulator operating mode. We don't need any sort of min/max for this property either, so a single value should be all that's required.
On 05/07, Viresh Kumar wrote: > On 7 May 2015 at 11:22, Stephen Boyd <sboyd@codeaurora.org> wrote: > > If you look at the cpufreq/clock/pmic code on our codeaurora.org > > tree you'll see that it's used to pass a value with uA units > > through the regulator_set_optimum_mode() API. The call to > > regulator_set_optimum_mode() is here[1], and the place where we > > parse the OPP table from DT is here[2]. My understanding is that > > with recent changes to the regulator framework, we would do a > > s/regulator_set_optimum_mode/regulator_set_load/ and things would > > otherwise be the same on the consumer side. On the regulator > > side, we would move the .get_optimum_mode op to .set_load instead > > of the hack where we write to the hardware in > > .get_optimum_mode[3]. > > > > So does that mean it corresponds to a limit, or a nominal > > constant draw value, or a value to regulator to? From what I can > > tell it's used to figure out how many phases to enable[4]. I > > suspect that means it's being used to figure out what value it > > should regulate to. In newer PMICs this is all done > > automatically, but at least for some of the PMICs we need to do > > it manually. > > By current phases, you probably meant [1], right ? > > Also what I couldn't understand is how are you controlling the > current here? > > - Is this a current only regulator ? Probably not as your code has > a uv value as well.. No. > > - Now if uV is fixed, how is the target current controlled separately ? uV is not fixed > > - Should we have a min/max/target value of this current ? Like what > we are doing for voltage. Or is this just the 'target' current ? I don't think so. It's just about setting the load through the regulator_set_load() API when this OPP is used. > > - And finally how exactly should we write this in bindings to make > it clear to all users ? > Let's take this up on my reply to Mark.
On Thu, May 07, 2015 at 02:18:55PM -0700, Stephen Boyd wrote: > On 05/07, Mark Brown wrote: > > I'm not looking for anyone to explain this to me in e-mail, what I'm > > looking for is for the binding document to be clear so someone can tell > > what the binding means by reading the documentation for the binding. > Ok. Perhaps the simplest thing to do then is to reuse wording > from the regulator_set_load() API documentation? That's the only > usage of this value I'm aware of. Something like: > The current load of the device when using this OPP. Used > to set the most efficient regulator operating mode. > We don't need any sort of min/max for this property either, so a > single value should be all that's required. That makes sense to me. Perhaps "current drawn by the device" rather than "current load of the device" since current is sadly overloaded :/
On 8 May 2015 at 03:48, Mark Brown <broonie@kernel.org> wrote: > That makes sense to me. Perhaps "current drawn by the device" rather > than "current load of the device" since current is sadly overloaded :/ Thanks Mark. I have reworded it as: - opp-microamp: Current drawn by the device in micro Amperes. It is used to set the most efficient regulator operating mode. Should only be set if opp-microvolt is set for the OPP. Entries for multiple regulators must be present in the same order as regulators are specified in device's DT node. If this property isn't required for few regulators, then this should be marked as zero for them. If it isn't required for any regulator, then this property need not be present. Please let me know if this looks fine now.
On 8 May 2015 at 03:00, Stephen Boyd <sboyd@codeaurora.org> wrote: > On 05/07, Viresh Kumar wrote: >> - Now if uV is fixed, how is the target current controlled separately ? > > uV is not fixed I meant uV is fixed for this particular OPP, i.e. min/tar/max value. What about the other changes? Does these fix the use cases you shared earlier ? I will send a new updated version then..
On Fri, May 08, 2015 at 12:17:44PM +0530, Viresh Kumar wrote: > Thanks Mark. I have reworded it as: > > - opp-microamp: Current drawn by the device in micro Amperes. It is used to set > the most efficient regulator operating mode. > > Should only be set if opp-microvolt is set for the OPP. > > Entries for multiple regulators must be present in the same order as > regulators are specified in device's DT node. If this property isn't required > for few regulators, then this should be marked as zero for them. If it isn't > required for any regulator, then this property need not be present. > Please let me know if this looks fine now. That should be fine, microamperes is usually one word.
On 8 May 2015 at 16:28, Mark Brown <broonie@kernel.org> wrote:
> That should be fine, microamperes is usually one word.
Will fix that. Thanks a lot Mark.
On 05/08/2015 01:47 AM, Viresh Kumar wrote: > On 8 May 2015 at 03:48, Mark Brown <broonie@kernel.org> wrote: > >> That makes sense to me. Perhaps "current drawn by the device" rather >> than "current load of the device" since current is sadly overloaded :/ > > Thanks Mark. I have reworded it as: > > - opp-microamp: Current drawn by the device in micro Amperes. It is used to set > the most efficient regulator operating mode. just one minor concern being in the SoC end of the world :). In most times, the current consumption for a specific OPP varies depending on the specific location in the process node the die is -> this is even true among a single lot of wafers as well. some SoC vendors use hot, nominal and cold terminology to indicate the characteristics of the specific sample. it might help state which sample end of the spectrum we are talking about here. reason being: if I put in values based on my board measurement, the results may not be similar to what someone else's sample be. Depending on technology, speed binning strategy used by the vendor, temperature and few other characteristics, these numbers could be widely divergent. > > Should only be set if opp-microvolt is set for the OPP. > > Entries for multiple regulators must be present in the same order as > regulators are specified in device's DT node. If this property isn't required > for few regulators, then this should be marked as zero for them. If it isn't > required for any regulator, then this property need not be present. > > > Please let me know if this looks fine now. >
On 10-05-15, 20:07, Nishanth Menon wrote: > just one minor concern being in the SoC end of the world :). In most > times, the current consumption for a specific OPP varies depending on > the specific location in the process node the die is -> this is even > true among a single lot of wafers as well. some SoC vendors use hot, > nominal and cold terminology to indicate the characteristics of the > specific sample. > > it might help state which sample end of the spectrum we are talking > about here. reason being: if I put in values based on my board > measurement, the results may not be similar to what someone else's > sample be. Depending on technology, speed binning strategy used by the > vendor, temperature and few other characteristics, these numbers could > be widely divergent. I don't have any clue about this.. :( @Mark/stephen: Any inputs ?
Quoting Viresh Kumar (2015-05-11 22:20:33) > On 10-05-15, 20:07, Nishanth Menon wrote: > > just one minor concern being in the SoC end of the world :). In most > > times, the current consumption for a specific OPP varies depending on > > the specific location in the process node the die is -> this is even > > true among a single lot of wafers as well. some SoC vendors use hot, > > nominal and cold terminology to indicate the characteristics of the > > specific sample. > > > > it might help state which sample end of the spectrum we are talking > > about here. reason being: if I put in values based on my board > > measurement, the results may not be similar to what someone else's > > sample be. Depending on technology, speed binning strategy used by the > > vendor, temperature and few other characteristics, these numbers could > > be widely divergent. > > I don't have any clue about this.. :( > > @Mark/stephen: Any inputs ? Nishanth, I do not think the idea of the mA property is to perfectly model current consumption at a given opp. Instead it is a nominal value that may be useful, e.g. for configuring a regulator in Stephen's case. The TWLxxxx series of PMICs from TI have configurable SMPS which could possibly benefit from this info as well. Most of the time those are left in an "automatic mode", but there are manual programming steps to achieve higher efficiencies and this property could potentially help you do that. Regards, Mike
Mike, On 05/12/2015 02:01 PM, Michael Turquette wrote: > Quoting Viresh Kumar (2015-05-11 22:20:33) >> On 10-05-15, 20:07, Nishanth Menon wrote: >>> just one minor concern being in the SoC end of the world :). In most >>> times, the current consumption for a specific OPP varies depending on >>> the specific location in the process node the die is -> this is even >>> true among a single lot of wafers as well. some SoC vendors use hot, >>> nominal and cold terminology to indicate the characteristics of the >>> specific sample. >>> >>> it might help state which sample end of the spectrum we are talking >>> about here. reason being: if I put in values based on my board >>> measurement, the results may not be similar to what someone else's >>> sample be. Depending on technology, speed binning strategy used by the >>> vendor, temperature and few other characteristics, these numbers could >>> be widely divergent. >> >> I don't have any clue about this.. :( >> >> @Mark/stephen: Any inputs ? > > I do not think the idea of the mA property is to perfectly model current > consumption at a given opp. Instead it is a nominal value that may be > useful, e.g. for configuring a regulator in Stephen's case. > > The TWLxxxx series of PMICs from TI have configurable SMPS which could > possibly benefit from this info as well. Most of the time those are left > in an "automatic mode", but there are manual programming steps to > achieve higher efficiencies and this property could potentially help you > do that. 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 Taking the simpler example of TWLxxx, the PMIC switches to PWM mode at 850mA for efficiency reasons, below 850mA, it is better to operate for accuracy and efficiency reasons at PFM mode. by putting 800mA we break efficiency on device Y, and if we choose to put 900mA or 850mA, we break efficiency on device X. 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). This is the reason I suggested to have a clear guidance in the bindings, since we'd very much like bindings to be ABI.
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 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. > 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.
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.
On Tue, May 12, 2015 at 02:57:29PM -0500, Nishanth Menon wrote: > On 05/12/2015 02:41 PM, Mark Brown wrote: > > On Tue, May 12, 2015 at 02:14:19PM -0500, Nishanth Menon wrote: > > 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). Qualcomm do. It kind of depends on the system how worst case it needs to be - it'll depend on the expected performance of both the system and potentially the regulator. For some systems it may be important to have some accounting for transients. Equally systems would only need to be as accurate as the underlying hardware was able to make use of.
On Wed, May 13, 2015 at 6:54 AM, Mark Brown <broonie@kernel.org> wrote: > On Tue, May 12, 2015 at 02:57:29PM -0500, Nishanth Menon wrote: >> On 05/12/2015 02:41 PM, Mark Brown wrote: >> > On Tue, May 12, 2015 at 02:14:19PM -0500, Nishanth Menon wrote: > >> > 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). > > Qualcomm do. It kind of depends on the system how worst case it needs > to be - it'll depend on the expected performance of both the system and > potentially the regulator. For some systems it may be important to have > some accounting for transients. Equally systems would only need to be > as accurate as the underlying hardware was able to make use of. True, some parts of the system like choice in regulator sizing has to account for transients. How about rephrasing as following: - opp-microamp: The maximum current drawn by the device in microamperes considering system specific parameters (such as transients, process, aging, etc.) as necessary, at an ambient temperature of 25C. This may be used to set the most efficient regulator operating mode. Valid only if opp-microvolt is set for the OPP. Entries for multiple regulators must be present in the same order as regulators are specified in device's DT node. If this property isn't required for few regulators, then this should be marked as zero for them. If it isn't required for any regulator, then this property need not be present. --- Regards, Nishanth Menon
On Wed, May 13, 2015 at 09:24:57AM -0500, Nishanth Menon wrote: > - opp-microamp: The maximum current drawn by the device in microamperes > considering system specific parameters (such as transients, process, > aging, etc.) > as necessary, at an ambient temperature of 25C. This may be used to set > the most efficient regulator operating mode. Why specify the temperature? That 25C is going to be terribly inefficient for my snowplow engine control system (or whatever).
On 05/13/2015 10:07 AM, Mark Brown wrote: > On Wed, May 13, 2015 at 09:24:57AM -0500, Nishanth Menon wrote: > >> - opp-microamp: The maximum current drawn by the device in microamperes >> considering system specific parameters (such as transients, process, >> aging, etc.) >> as necessary, at an ambient temperature of 25C. This may be used to set >> the most efficient regulator operating mode. > > Why specify the temperature? That 25C is going to be terribly > inefficient for my snowplow engine control system (or whatever). > :) was trying to put a constraint since we do know that leakage changes over temperature profile and the fact that operating temperature ranges vary depending on device and market. rephrased again below: - opp-microamp: The maximum current drawn by the device in microamperes considering system specific parameters (such as transients, process, aging, maximum operating temperature range etc.) as necessary. This may be used to set the most efficient regulator operating mode.
diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt index c96dc77121b7..a57e88ab4554 100644 --- a/Documentation/devicetree/bindings/power/opp.txt +++ b/Documentation/devicetree/bindings/power/opp.txt @@ -59,16 +59,18 @@ properties. regulators are specified in device's DT node. - opp-microamp: current in micro Amperes. It can contain entries for multiple - regulators. + regulators. This can be referenced (along with voltage and freqency) while + programming the regulator. A single regulator's current is specified with an array of size one or three. Single entry is for target current and three entries are for <target min max> currents. Entries for multiple regulators must be present in the same order as - regulators are specified in device's DT node. If few regulators don't provide - capability to configure current, then values for then should be marked as - zero. + regulators are specified in device's DT node. If current value for few + regulators isn't required to be passed, then values for such regulators should + be marked as zero. If it isn't required for any regulator, then this property + need not be present. - clock-latency-ns: Specifies the maximum possible transition latency (in