All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: Michael Turquette <mike.turquette@linaro.org>,
	Viresh Kumar <viresh.kumar@linaro.org>
Cc: Mark Brown <broonie@kernel.org>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Rafael Wysocki <rjw@rjwysocki.net>,
	Rob Herring <rob.herring@linaro.org>,
	Arnd Bergmann <arnd.bergmann@linaro.org>,
	Linaro Kernel Mailman List <linaro-kernel@lists.linaro.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Grant Likely <grant.likely@linaro.org>,
	"olof@lixom.net" <olof@lixom.net>,
	Sudeep Holla <Sudeep.Holla@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Viswanath Puttagunta <viswanath.puttagunta@linaro.org>,
	Lucas Stach <l.stach@pengutronix.de>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Thomas Abraham <ta.omasab@gmail.com>,
	Abhilash Kesavan <kesavan.abhilash@gmail.com>,
	Kevin Hilman <khilman@linaro.org>,
	santosh shilimkar <santosh.shilimkar@oracle.com>
Subject: Re: [PATCH V4 1/3] OPP: Redefine bindings to overcome shortcomings
Date: Tue, 12 May 2015 14:14:19 -0500	[thread overview]
Message-ID: <5552510B.9010306@ti.com> (raw)
In-Reply-To: <20150512190134.16410.89041@quantum>

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.

-- 
Regards,
Nishanth Menon

WARNING: multiple messages have this Message-ID (diff)
From: nm@ti.com (Nishanth Menon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V4 1/3] OPP: Redefine bindings to overcome shortcomings
Date: Tue, 12 May 2015 14:14:19 -0500	[thread overview]
Message-ID: <5552510B.9010306@ti.com> (raw)
In-Reply-To: <20150512190134.16410.89041@quantum>

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.

-- 
Regards,
Nishanth Menon

  reply	other threads:[~2015-05-12 19:15 UTC|newest]

Thread overview: 124+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-30 12:07 [PATCH V4 0/3] OPP: Introduce OPP (V2) bindings Viresh Kumar
2015-04-30 12:07 ` Viresh Kumar
     [not found] ` <cover.1430394884.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-04-30 12:07   ` [PATCH V4 1/3] OPP: Redefine bindings to overcome shortcomings Viresh Kumar
2015-04-30 12:07     ` Viresh Kumar
     [not found]     ` <d225e73f183e01fa0b71e4b9248b6a19a3f7d697.1430394884.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-05-04 12:12       ` Mark Brown
2015-05-04 12:12         ` Mark Brown
2015-05-05 10:48         ` Viresh Kumar
2015-05-05 10:48           ` Viresh Kumar
2015-05-05 10:57           ` Mark Brown
2015-05-05 10:57             ` Mark Brown
     [not found]             ` <20150505105714.GA22845-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2015-05-05 11:43               ` Viresh Kumar
2015-05-05 11:43                 ` Viresh Kumar
2015-05-05 17:12                 ` Mark Brown
2015-05-05 17:12                   ` Mark Brown
2015-05-06  6:53                   ` Viresh Kumar
2015-05-06  6:53                     ` Viresh Kumar
2015-05-07  5:52                     ` Stephen Boyd
2015-05-07  5:52                       ` Stephen Boyd
2015-05-07 11:02                       ` Mark Brown
2015-05-07 11:02                         ` Mark Brown
2015-05-07 21:18                         ` Stephen Boyd
2015-05-07 21:18                           ` Stephen Boyd
2015-05-07 22:18                           ` Mark Brown
2015-05-07 22:18                             ` Mark Brown
     [not found]                             ` <20150507221842.GW22845-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2015-05-08  6:47                               ` Viresh Kumar
2015-05-08  6:47                                 ` Viresh Kumar
2015-05-08 10:58                                 ` Mark Brown
2015-05-08 10:58                                   ` Mark Brown
2015-05-08 11:01                                   ` Viresh Kumar
2015-05-08 11:01                                     ` Viresh Kumar
2015-05-11  1:07                                 ` Nishanth Menon
2015-05-11  1:07                                   ` Nishanth Menon
2015-05-12  5:20                                   ` Viresh Kumar
2015-05-12  5:20                                     ` Viresh Kumar
2015-05-12 19:01                                     ` Michael Turquette
2015-05-12 19:01                                       ` Michael Turquette
2015-05-12 19:14                                       ` Nishanth Menon [this message]
2015-05-12 19:14                                         ` Nishanth Menon
2015-05-12 19:41                                         ` Mark Brown
2015-05-12 19:41                                           ` Mark Brown
2015-05-12 19:57                                           ` Nishanth Menon
2015-05-12 19:57                                             ` Nishanth Menon
2015-05-13 11:54                                             ` Mark Brown
2015-05-13 11:54                                               ` Mark Brown
     [not found]                                               ` <20150513115422.GQ3066-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2015-05-13 14:24                                                 ` Nishanth Menon
2015-05-13 14:24                                                   ` Nishanth Menon
2015-05-13 15:07                                                   ` Mark Brown
2015-05-13 15:07                                                     ` Mark Brown
2015-05-13 15:43                                                     ` Nishanth Menon
2015-05-13 15:43                                                       ` Nishanth Menon
2015-05-07 12:13                       ` Viresh Kumar
2015-05-07 12:13                         ` Viresh Kumar
2015-05-07 21:30                         ` Stephen Boyd
2015-05-07 21:30                           ` Stephen Boyd
2015-05-08  6:49                           ` Viresh Kumar
2015-05-08  6:49                             ` Viresh Kumar
2015-05-11  1:02       ` Nishanth Menon
2015-05-11  1:02         ` Nishanth Menon
2015-05-12  5:16         ` Viresh Kumar
2015-05-12  5:16           ` Viresh Kumar
2015-05-12 16:04           ` Nishanth Menon
2015-05-12 16:04             ` Nishanth Menon
2015-05-13  5:05             ` Viresh Kumar
2015-05-13  5:05               ` Viresh Kumar
2015-05-13 15:00               ` Nishanth Menon
2015-05-13 15:00                 ` Nishanth Menon
2015-05-13 15:16                 ` Mark Brown
2015-05-13 15:16                   ` Mark Brown
2015-05-13 16:14                   ` Nishanth Menon
2015-05-13 16:14                     ` Nishanth Menon
2015-05-13 16:21                     ` Mark Brown
2015-05-13 16:21                       ` Mark Brown
2015-05-13 16:34                       ` Nishanth Menon
2015-05-13 16:34                         ` Nishanth Menon
2015-05-12 16:19     ` Felipe Balbi
2015-05-12 16:19       ` Felipe Balbi
2015-05-13  4:45       ` Viresh Kumar
2015-05-13  4:45         ` Viresh Kumar
2015-05-12 21:42     ` Michael Turquette
2015-05-12 21:42       ` Michael Turquette
2015-05-13  8:55       ` Viresh Kumar
2015-05-13  8:55         ` Viresh Kumar
2015-05-13 11:03         ` Mark Brown
2015-05-13 11:03           ` Mark Brown
2015-05-14  0:32           ` Michael Turquette
2015-05-14  0:32             ` Michael Turquette
     [not found]             ` <CAKohpokeKtcJdrBcPZBBPR2zfJgpvuM_=wRaX5q1Uto2qx1oHQ@mail.gmail.com>
2015-05-15 14:15               ` Viresh Kumar
2015-05-15 14:15                 ` Viresh Kumar
2015-05-15 15:43                 ` Nishanth Menon
2015-05-15 15:43                   ` Nishanth Menon
2015-05-15 17:27             ` Rob Herring
2015-05-15 17:27               ` Rob Herring
2015-05-21  6:02         ` Nishanth Menon
2015-05-21  6:02           ` Nishanth Menon
2015-05-22 14:04           ` Viresh Kumar
2015-05-22 14:04             ` Viresh Kumar
2015-05-22 16:04             ` Rob Herring
2015-05-22 16:04               ` Rob Herring
2015-05-22 17:42               ` Nishanth Menon
2015-05-22 17:42                 ` Nishanth Menon
2015-05-26  5:25                 ` Viresh Kumar
2015-05-26  5:25                   ` Viresh Kumar
2015-05-20  0:51     ` Stephen Boyd
2015-05-20  0:51       ` Stephen Boyd
2015-05-20  2:07       ` Viresh Kumar
2015-05-20  2:07         ` Viresh Kumar
2015-05-20 19:39         ` Stephen Boyd
2015-05-20 19:39           ` Stephen Boyd
2015-05-21  4:33           ` Viresh Kumar
2015-05-21  4:33             ` Viresh Kumar
2015-05-25 11:59             ` Viresh Kumar
2015-05-25 11:59               ` Viresh Kumar
2015-04-30 12:08 ` [PATCH V4 2/3] OPP: Allow multiple OPP tables to be passed via DT Viresh Kumar
2015-04-30 12:08   ` Viresh Kumar
2015-05-12 16:09   ` Nishanth Menon
2015-05-12 16:09     ` Nishanth Menon
2015-05-13  4:41     ` Viresh Kumar
2015-05-13  4:41       ` Viresh Kumar
2015-05-20  0:52   ` Stephen Boyd
2015-05-20  0:52     ` Stephen Boyd
2015-04-30 12:08 ` [PATCH V4 3/3] OPP: Add 'opp-next' in operating-points-v2 bindings Viresh Kumar
2015-04-30 12:08   ` Viresh Kumar
2015-05-12 21:47   ` Michael Turquette
2015-05-12 21:47     ` Michael Turquette

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5552510B.9010306@ti.com \
    --to=nm@ti.com \
    --cc=Sudeep.Holla@arm.com \
    --cc=arnd.bergmann@linaro.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=kesavan.abhilash@gmail.com \
    --cc=khilman@linaro.org \
    --cc=l.stach@pengutronix.de \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mike.turquette@linaro.org \
    --cc=olof@lixom.net \
    --cc=rjw@rjwysocki.net \
    --cc=rob.herring@linaro.org \
    --cc=santosh.shilimkar@oracle.com \
    --cc=sboyd@codeaurora.org \
    --cc=ta.omasab@gmail.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=viresh.kumar@linaro.org \
    --cc=viswanath.puttagunta@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.