diff mbox series

[1/4] dt-bindings: opp: Introduce opp-sustainable bindings

Message ID 20201028140847.1018-2-lukasz.luba@arm.com
State Changes Requested
Headers show
Series Add sustainable OPP concept | expand

Checks

Context Check Description
robh/checkpatch success

Commit Message

Lukasz Luba Oct. 28, 2020, 2:08 p.m. UTC
Add opp-sustainable as an additional property in the OPP node to describe
the sustainable performance level of the device. This will help to
estimate the sustainable performance of the whole system.

Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
---
 Documentation/devicetree/bindings/opp/opp.txt | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Lukasz Luba Oct. 29, 2020, 10:04 a.m. UTC | #1
On 10/28/20 9:47 PM, Nishanth Menon wrote:
> On 14:08-20201028, Lukasz Luba wrote:
>> Add opp-sustainable as an additional property in the OPP node to describe
>> the sustainable performance level of the device. This will help to
>> estimate the sustainable performance of the whole system.
>>
>> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
>> ---
>>   Documentation/devicetree/bindings/opp/opp.txt | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
>> index 9847dfeeffcb..cd01028de305 100644
>> --- a/Documentation/devicetree/bindings/opp/opp.txt
>> +++ b/Documentation/devicetree/bindings/opp/opp.txt
>> @@ -154,6 +154,10 @@ Optional properties:
>>   - opp-suspend: Marks the OPP to be used during device suspend. If multiple OPPs
>>     in the table have this, the OPP with highest opp-hz will be used.
>>   
>> +- opp-sustainable: Marks the OPP as sustainable. This property can be used for
>> +  estimating sustainable performance of the whole system. If multiple OPPs in
>> +  the table have this, the OPP with highest opp-hz will be used.
> 
> 
> By "sustainable", do you mean sustainable across Process, Voltage and
> Temperature corners upto the max rated operational Power-ON hours
> without IDLE state being achieved on the processor?

Yes, in case of CPU: running 100% without idle at that particular OPP.
Running above that OPP would lead to cross control temperature.

> 
> OR do you mean to leave it up to interpretation?

I can tell how I would use them. There is thermal governor IPA, which
needs sustainable power either form DT or uses internal algorithm to
estimate it based on lowest allowed freq OPPs. Then it estimated
internal coefficients based on that value, which is not optimal
for lowest OPPs. When some higher OPP could be marked as sustainable,
it would lead to better estimation and better power budget split.

Regards,
Lukasz
Nishanth Menon Oct. 29, 2020, 12:59 p.m. UTC | #2
On 10:04-20201029, Lukasz Luba wrote:
> 
> 
> On 10/28/20 9:47 PM, Nishanth Menon wrote:
> > On 14:08-20201028, Lukasz Luba wrote:
> > > Add opp-sustainable as an additional property in the OPP node to describe
> > > the sustainable performance level of the device. This will help to
> > > estimate the sustainable performance of the whole system.
> > > 
> > > Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
> > > ---
> > >   Documentation/devicetree/bindings/opp/opp.txt | 4 ++++
> > >   1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> > > index 9847dfeeffcb..cd01028de305 100644
> > > --- a/Documentation/devicetree/bindings/opp/opp.txt
> > > +++ b/Documentation/devicetree/bindings/opp/opp.txt
> > > @@ -154,6 +154,10 @@ Optional properties:
> > >   - opp-suspend: Marks the OPP to be used during device suspend. If multiple OPPs
> > >     in the table have this, the OPP with highest opp-hz will be used.
> > > +- opp-sustainable: Marks the OPP as sustainable. This property can be used for
> > > +  estimating sustainable performance of the whole system. If multiple OPPs in
> > > +  the table have this, the OPP with highest opp-hz will be used.
> > 
> > 
> > By "sustainable", do you mean sustainable across Process, Voltage and
> > Temperature corners upto the max rated operational Power-ON hours
> > without IDLE state being achieved on the processor?
> 
> Yes, in case of CPU: running 100% without idle at that particular OPP.
> Running above that OPP would lead to cross control temperature.

We need to tighten the definitions a lot more here and add that to the
binding. What we are stating, if I am not misunderstanding is an OPP
that is guaranteed by SoC vendor that across Process Voltage and
Temperature corners - aka across the entire production spectrum
for the part number, *all* devices will operate at this OPP for the
mandated power-on-hours rating without hitting IDLE.

Example: So -40C to 125C, across the process (hot/cold/nominal), 100s of
thousands/millions of units can operate upto 125,0000 power-on-hours
while running a tight deadloop OR maybe high processing function or even
cpuburn[1]?


Can you give me one SoC vendor and part that guarantees this? I am
wondering if this is all theoretical... There are tons of parameters
that come into play for "reliability" "sustainability" etc. Those are
tricky terminology that typically makes legal folks pretty happy to
debate for decades..

just my 2 cents.
> 
> > 
> > OR do you mean to leave it up to interpretation?
> 
> I can tell how I would use them. There is thermal governor IPA, which
> needs sustainable power either form DT or uses internal algorithm to
> estimate it based on lowest allowed freq OPPs. Then it estimated
> internal coefficients based on that value, which is not optimal
> for lowest OPPs. When some higher OPP could be marked as sustainable,
> it would lead to better estimation and better power budget split.

Seeing your series, I got an idea about how you plan on using it, I
just think we need to be more precise in our definition..

[1] https://patrickmn.com/projects/cpuburn/
Lukasz Luba Oct. 29, 2020, 1:33 p.m. UTC | #3
On 10/29/20 12:59 PM, Nishanth Menon wrote:
> On 10:04-20201029, Lukasz Luba wrote:
>>
>>
>> On 10/28/20 9:47 PM, Nishanth Menon wrote:
>>> On 14:08-20201028, Lukasz Luba wrote:
>>>> Add opp-sustainable as an additional property in the OPP node to describe
>>>> the sustainable performance level of the device. This will help to
>>>> estimate the sustainable performance of the whole system.
>>>>
>>>> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
>>>> ---
>>>>    Documentation/devicetree/bindings/opp/opp.txt | 4 ++++
>>>>    1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
>>>> index 9847dfeeffcb..cd01028de305 100644
>>>> --- a/Documentation/devicetree/bindings/opp/opp.txt
>>>> +++ b/Documentation/devicetree/bindings/opp/opp.txt
>>>> @@ -154,6 +154,10 @@ Optional properties:
>>>>    - opp-suspend: Marks the OPP to be used during device suspend. If multiple OPPs
>>>>      in the table have this, the OPP with highest opp-hz will be used.
>>>> +- opp-sustainable: Marks the OPP as sustainable. This property can be used for
>>>> +  estimating sustainable performance of the whole system. If multiple OPPs in
>>>> +  the table have this, the OPP with highest opp-hz will be used.
>>>
>>>
>>> By "sustainable", do you mean sustainable across Process, Voltage and
>>> Temperature corners upto the max rated operational Power-ON hours
>>> without IDLE state being achieved on the processor?
>>
>> Yes, in case of CPU: running 100% without idle at that particular OPP.
>> Running above that OPP would lead to cross control temperature.
> 
> We need to tighten the definitions a lot more here and add that to the
> binding. What we are stating, if I am not misunderstanding is an OPP
> that is guaranteed by SoC vendor that across Process Voltage and
> Temperature corners - aka across the entire production spectrum
> for the part number, *all* devices will operate at this OPP for the
> mandated power-on-hours rating without hitting IDLE.
> 
> Example: So -40C to 125C, across the process (hot/cold/nominal), 100s of
> thousands/millions of units can operate upto 125,0000 power-on-hours
> while running a tight deadloop OR maybe high processing function or even
> cpuburn[1]?

I think I know what you mean. But this would lead to redefining a lot
more that just this optional field. This wide range -40C to 125C is for
automotive chips, then what about opp-suspend, when the device cannot
even reach that OPP under some stress test e.g. outside temp
~100-110C...
Or opp-turbo, shell all the OPPs have multidimensional table to reflect
the temperature dependency for all affected optional fields?

> 
> 
> Can you give me one SoC vendor and part that guarantees this? I am
> wondering if this is all theoretical... There are tons of parameters
> that come into play for "reliability" "sustainability" etc. Those are
> tricky terminology that typically makes legal folks pretty happy to
> debate for decades..

Yes, but the outside temperature is probably most important for this use
case.

> 
> just my 2 cents.
>>
>>>
>>> OR do you mean to leave it up to interpretation?
>>
>> I can tell how I would use them. There is thermal governor IPA, which
>> needs sustainable power either form DT or uses internal algorithm to
>> estimate it based on lowest allowed freq OPPs. Then it estimated
>> internal coefficients based on that value, which is not optimal
>> for lowest OPPs. When some higher OPP could be marked as sustainable,
>> it would lead to better estimation and better power budget split.
> 
> Seeing your series, I got an idea about how you plan on using it, I
> just think we need to be more precise in our definition..

Thank you for having a look on that and understanding the motivation
behind this series.

How about adding a description that this sustainable OPP is considered
for normal room temp (20-25C)?

BTW, in the Arm SCMI spec definition of that value (used in patch 4/4),
there is no specific temperature for it, just:
'This is the maximum performance level that the platform can
sustain under normal conditions. In exceptional circumstances,
such as thermal runaway, the platform might not be be able to
guarantee this level.'

I can put this whole description into the DT binding, if you like.

> 
> [1] https://patrickmn.com/projects/cpuburn/
>
Nishanth Menon Oct. 29, 2020, 1:49 p.m. UTC | #4
On 13:33-20201029, Lukasz Luba wrote:
> 
> 
> On 10/29/20 12:59 PM, Nishanth Menon wrote:
> > On 10:04-20201029, Lukasz Luba wrote:
> > > 
> > > 
> > > On 10/28/20 9:47 PM, Nishanth Menon wrote:
> > > > On 14:08-20201028, Lukasz Luba wrote:
> > > > > Add opp-sustainable as an additional property in the OPP node to describe
> > > > > the sustainable performance level of the device. This will help to
> > > > > estimate the sustainable performance of the whole system.
> > > > > 
> > > > > Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
> > > > > ---
> > > > >    Documentation/devicetree/bindings/opp/opp.txt | 4 ++++
> > > > >    1 file changed, 4 insertions(+)
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> > > > > index 9847dfeeffcb..cd01028de305 100644
> > > > > --- a/Documentation/devicetree/bindings/opp/opp.txt
> > > > > +++ b/Documentation/devicetree/bindings/opp/opp.txt
> > > > > @@ -154,6 +154,10 @@ Optional properties:
> > > > >    - opp-suspend: Marks the OPP to be used during device suspend. If multiple OPPs
> > > > >      in the table have this, the OPP with highest opp-hz will be used.
> > > > > +- opp-sustainable: Marks the OPP as sustainable. This property can be used for
> > > > > +  estimating sustainable performance of the whole system. If multiple OPPs in
> > > > > +  the table have this, the OPP with highest opp-hz will be used.
> > > > 
> > > > 
> > > > By "sustainable", do you mean sustainable across Process, Voltage and
> > > > Temperature corners upto the max rated operational Power-ON hours
> > > > without IDLE state being achieved on the processor?
> > > 
> > > Yes, in case of CPU: running 100% without idle at that particular OPP.
> > > Running above that OPP would lead to cross control temperature.
> > 
> > We need to tighten the definitions a lot more here and add that to the
> > binding. What we are stating, if I am not misunderstanding is an OPP
> > that is guaranteed by SoC vendor that across Process Voltage and
> > Temperature corners - aka across the entire production spectrum
> > for the part number, *all* devices will operate at this OPP for the
> > mandated power-on-hours rating without hitting IDLE.
> > 
> > Example: So -40C to 125C, across the process (hot/cold/nominal), 100s of
> > thousands/millions of units can operate upto 125,0000 power-on-hours
> > while running a tight deadloop OR maybe high processing function or even
> > cpuburn[1]?
> 
> I think I know what you mean. But this would lead to redefining a lot
> more that just this optional field. This wide range -40C to 125C is for
> automotive chips, then what about opp-suspend, when the device cannot
> even reach that OPP under some stress test e.g. outside temp
> ~100-110C...
> Or opp-turbo, shell all the OPPs have multidimensional table to reflect
> the temperature dependency for all affected optional fields?

yes, and down the rabbit hole we will go :)

> 
> > 
> > 
> > Can you give me one SoC vendor and part that guarantees this? I am
> > wondering if this is all theoretical... There are tons of parameters
> > that come into play for "reliability" "sustainability" etc. Those are
> > tricky terminology that typically makes legal folks pretty happy to
> > debate for decades..
> 
> Yes, but the outside temperature is probably most important for this use
> case.
> 
> > 
> > just my 2 cents.
> > > 
> > > > 
> > > > OR do you mean to leave it up to interpretation?
> > > 
> > > I can tell how I would use them. There is thermal governor IPA, which
> > > needs sustainable power either form DT or uses internal algorithm to
> > > estimate it based on lowest allowed freq OPPs. Then it estimated
> > > internal coefficients based on that value, which is not optimal
> > > for lowest OPPs. When some higher OPP could be marked as sustainable,
> > > it would lead to better estimation and better power budget split.
> > 
> > Seeing your series, I got an idea about how you plan on using it, I
> > just think we need to be more precise in our definition..
> 
> Thank you for having a look on that and understanding the motivation
> behind this series.
> 
> How about adding a description that this sustainable OPP is considered
> for normal room temp (20-25C)?

You could.. but then, practically as we go into smaller process nodes,
the 20-25C reliability is just theoretical. I mean, we Texans in summer
or Finns in winter would probably define "normal room temperature" as
something different in practise (ISO not withstanding ;) ).. Challenge
of reliability has always been on the edge of the PVT ranges. To ignore
that OR to have a scheme that does not scale to describe that, IMHO is a
lacking definition.

My entire point is, if we can avoid getting into rabbit hole
definitions, we probably should.. IMHO.. keep things as simple as
possible.

> 
> BTW, in the Arm SCMI spec definition of that value (used in patch 4/4),

You mean [1] Table 11 Performance Domain Levels with Special
	Significance
> there is no specific temperature for it, just:
> 'This is the maximum performance level that the platform can
> sustain under normal conditions. In exceptional circumstances,
> such as thermal runaway, the platform might not be be able to
> guarantee this level.'
> 

Hehe.. Vincent and SCMI teams have been having fun there :)... But, I
think the definition has little practical significance for the very
reasons I made above IMHO, and with full respect to SCMI team(defining
SCMI is not an easy task, I admit) - it is at best a theoretical,
"works at the engineer's cube definition", as typical "nominal
operation conditions" escape clause tend to be, OR at the worst
ignoring to define the parameters that constitute what would bound
things in a closed box precisely (example: does'nt mention process, so
just nominal OR considers all process corners - what does omission of
that factor really mean?).


> I can put this whole description into the DT binding, if you like.

Will leave it to Viresh and others to comment and guide, the terminology
got my attention, since I almost got bit by a similar usage.. my 2 cents:
I dont think that suffices unfortunately. what it lacks are the
parameters of what that terminology really means,

One actual production part that demonstrates this will probably help
guide the discussion, I guess..

/me goes back to OPP hibernation

> 

[1] https://developer.arm.com/documentation/den0056/b
Lukasz Luba Oct. 29, 2020, 2:20 p.m. UTC | #5
On 10/29/20 1:49 PM, Nishanth Menon wrote:
> On 13:33-20201029, Lukasz Luba wrote:
>>
>>
>> On 10/29/20 12:59 PM, Nishanth Menon wrote:
>>> On 10:04-20201029, Lukasz Luba wrote:
>>>>
>>>>
>>>> On 10/28/20 9:47 PM, Nishanth Menon wrote:
>>>>> On 14:08-20201028, Lukasz Luba wrote:
>>>>>> Add opp-sustainable as an additional property in the OPP node to describe
>>>>>> the sustainable performance level of the device. This will help to
>>>>>> estimate the sustainable performance of the whole system.
>>>>>>
>>>>>> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
>>>>>> ---
>>>>>>     Documentation/devicetree/bindings/opp/opp.txt | 4 ++++
>>>>>>     1 file changed, 4 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
>>>>>> index 9847dfeeffcb..cd01028de305 100644
>>>>>> --- a/Documentation/devicetree/bindings/opp/opp.txt
>>>>>> +++ b/Documentation/devicetree/bindings/opp/opp.txt
>>>>>> @@ -154,6 +154,10 @@ Optional properties:
>>>>>>     - opp-suspend: Marks the OPP to be used during device suspend. If multiple OPPs
>>>>>>       in the table have this, the OPP with highest opp-hz will be used.
>>>>>> +- opp-sustainable: Marks the OPP as sustainable. This property can be used for
>>>>>> +  estimating sustainable performance of the whole system. If multiple OPPs in
>>>>>> +  the table have this, the OPP with highest opp-hz will be used.
>>>>>
>>>>>
>>>>> By "sustainable", do you mean sustainable across Process, Voltage and
>>>>> Temperature corners upto the max rated operational Power-ON hours
>>>>> without IDLE state being achieved on the processor?
>>>>
>>>> Yes, in case of CPU: running 100% without idle at that particular OPP.
>>>> Running above that OPP would lead to cross control temperature.
>>>
>>> We need to tighten the definitions a lot more here and add that to the
>>> binding. What we are stating, if I am not misunderstanding is an OPP
>>> that is guaranteed by SoC vendor that across Process Voltage and
>>> Temperature corners - aka across the entire production spectrum
>>> for the part number, *all* devices will operate at this OPP for the
>>> mandated power-on-hours rating without hitting IDLE.
>>>
>>> Example: So -40C to 125C, across the process (hot/cold/nominal), 100s of
>>> thousands/millions of units can operate upto 125,0000 power-on-hours
>>> while running a tight deadloop OR maybe high processing function or even
>>> cpuburn[1]?
>>
>> I think I know what you mean. But this would lead to redefining a lot
>> more that just this optional field. This wide range -40C to 125C is for
>> automotive chips, then what about opp-suspend, when the device cannot
>> even reach that OPP under some stress test e.g. outside temp
>> ~100-110C...
>> Or opp-turbo, shell all the OPPs have multidimensional table to reflect
>> the temperature dependency for all affected optional fields?
> 
> yes, and down the rabbit hole we will go :)
> 
>>
>>>
>>>
>>> Can you give me one SoC vendor and part that guarantees this? I am
>>> wondering if this is all theoretical... There are tons of parameters
>>> that come into play for "reliability" "sustainability" etc. Those are
>>> tricky terminology that typically makes legal folks pretty happy to
>>> debate for decades..
>>
>> Yes, but the outside temperature is probably most important for this use
>> case.
>>
>>>
>>> just my 2 cents.
>>>>
>>>>>
>>>>> OR do you mean to leave it up to interpretation?
>>>>
>>>> I can tell how I would use them. There is thermal governor IPA, which
>>>> needs sustainable power either form DT or uses internal algorithm to
>>>> estimate it based on lowest allowed freq OPPs. Then it estimated
>>>> internal coefficients based on that value, which is not optimal
>>>> for lowest OPPs. When some higher OPP could be marked as sustainable,
>>>> it would lead to better estimation and better power budget split.
>>>
>>> Seeing your series, I got an idea about how you plan on using it, I
>>> just think we need to be more precise in our definition..
>>
>> Thank you for having a look on that and understanding the motivation
>> behind this series.
>>
>> How about adding a description that this sustainable OPP is considered
>> for normal room temp (20-25C)?
> 
> You could.. but then, practically as we go into smaller process nodes,
> the 20-25C reliability is just theoretical. I mean, we Texans in summer
> or Finns in winter would probably define "normal room temperature" as
> something different in practise (ISO not withstanding ;) ).. Challenge
> of reliability has always been on the edge of the PVT ranges. To ignore
> that OR to have a scheme that does not scale to describe that, IMHO is a
> lacking definition.
> 
> My entire point is, if we can avoid getting into rabbit hole
> definitions, we probably should.. IMHO.. keep things as simple as
> possible.
> 
>>
>> BTW, in the Arm SCMI spec definition of that value (used in patch 4/4),
> 
> You mean [1] Table 11 Performance Domain Levels with Special
> 	Significance

Yes, the table 11 from that SCMI doc (under link you provided).

>> there is no specific temperature for it, just:
>> 'This is the maximum performance level that the platform can
>> sustain under normal conditions. In exceptional circumstances,
>> such as thermal runaway, the platform might not be be able to
>> guarantee this level.'
>>
> 
> Hehe.. Vincent and SCMI teams have been having fun there :)... But, I
> think the definition has little practical significance for the very
> reasons I made above IMHO, and with full respect to SCMI team(defining
> SCMI is not an easy task, I admit) - it is at best a theoretical,
> "works at the engineer's cube definition", as typical "nominal
> operation conditions" escape clause tend to be, OR at the worst
> ignoring to define the parameters that constitute what would bound
> things in a closed box precisely (example: does'nt mention process, so
> just nominal OR considers all process corners - what does omission of
> that factor really mean?).
> 
> 
>> I can put this whole description into the DT binding, if you like.
> 
> Will leave it to Viresh and others to comment and guide, the terminology
> got my attention, since I almost got bit by a similar usage.. my 2 cents:
> I dont think that suffices unfortunately. what it lacks are the
> parameters of what that terminology really means,
> 
> One actual production part that demonstrates this will probably help
> guide the discussion, I guess..
> 
> /me goes back to OPP hibernation
> 
>>
> 
> [1] https://developer.arm.com/documentation/den0056/b
>
Rob Herring Oct. 30, 2020, 7:34 p.m. UTC | #6
On Wed, Oct 28, 2020 at 02:08:44PM +0000, Lukasz Luba wrote:
> Add opp-sustainable as an additional property in the OPP node to describe
> the sustainable performance level of the device. This will help to
> estimate the sustainable performance of the whole system.
> 
> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
> ---
>  Documentation/devicetree/bindings/opp/opp.txt | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> index 9847dfeeffcb..cd01028de305 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -154,6 +154,10 @@ Optional properties:
>  - opp-suspend: Marks the OPP to be used during device suspend. If multiple OPPs
>    in the table have this, the OPP with highest opp-hz will be used.
>  
> +- opp-sustainable: Marks the OPP as sustainable. This property can be used for
> +  estimating sustainable performance of the whole system. If multiple OPPs in
> +  the table have this, the OPP with highest opp-hz will be used.
> +

Isn't this just the inverse of the turbo? or boost? flag we already 
have? 

Couldn't this be learned? I ran at this frequency and then overheated. 
That could be dependent on ambient temperatures or dust build up on 
fans/heatsink.

Rob
Lukasz Luba Nov. 2, 2020, 8:40 a.m. UTC | #7
Hi Rob,

On 10/30/20 7:34 PM, Rob Herring wrote:
> On Wed, Oct 28, 2020 at 02:08:44PM +0000, Lukasz Luba wrote:
>> Add opp-sustainable as an additional property in the OPP node to describe
>> the sustainable performance level of the device. This will help to
>> estimate the sustainable performance of the whole system.
>>
>> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
>> ---
>>   Documentation/devicetree/bindings/opp/opp.txt | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
>> index 9847dfeeffcb..cd01028de305 100644
>> --- a/Documentation/devicetree/bindings/opp/opp.txt
>> +++ b/Documentation/devicetree/bindings/opp/opp.txt
>> @@ -154,6 +154,10 @@ Optional properties:
>>   - opp-suspend: Marks the OPP to be used during device suspend. If multiple OPPs
>>     in the table have this, the OPP with highest opp-hz will be used.
>>   
>> +- opp-sustainable: Marks the OPP as sustainable. This property can be used for
>> +  estimating sustainable performance of the whole system. If multiple OPPs in
>> +  the table have this, the OPP with highest opp-hz will be used.
>> +
> 
> Isn't this just the inverse of the turbo? or boost? flag we already
> have?

True, it could be possible to use those flags. Then a function which
returns one OPP below, would be 'sustainable'. I've already
suggested to skip binding and only have get/set functions for OPP
framework to mark 'sustainable' level, but Viresh is against.
We have discussed this new opp sustainable with Viresh and since it
would be only used by IPA but the definition is a bit blurry,
we decided to drop this series. Maybe in future when there will be
another user, we will come back to this.
I am going to use Energy Model and mark the em_perf_state as sustained.

> 
> Couldn't this be learned? I ran at this frequency and then overheated.
> That could be dependent on ambient temperatures or dust build up on
> fans/heatsink.

Yes it could be learned. IPA tries to do that for different workloads,
but it needs some starting conditions (coefficients and sustainable
power) to converge in short time. Sustainable power is currently
estimated based on lowest OPP. With that new 'sustainable' flag,
it would be much easier for IPA to converge.

Regards,
Lukasz

> 
> Rob
>
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index 9847dfeeffcb..cd01028de305 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -154,6 +154,10 @@  Optional properties:
 - opp-suspend: Marks the OPP to be used during device suspend. If multiple OPPs
   in the table have this, the OPP with highest opp-hz will be used.
 
+- opp-sustainable: Marks the OPP as sustainable. This property can be used for
+  estimating sustainable performance of the whole system. If multiple OPPs in
+  the table have this, the OPP with highest opp-hz will be used.
+
 - opp-supported-hw: This property allows a platform to enable only a subset of
   the OPPs from the larger set present in the OPP table, based on the current
   version of the hardware (already known to the operating system).