linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Lukasz Luba <lukasz.luba@arm.com>
Cc: amit.kachhap@gmail.com, viresh.kumar@linaro.org,
	rafael@kernel.org, amitk@kernel.org, rui.zhang@intel.com,
	dietmar.eggemann@arm.com, Pierre.Gondois@arm.com,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH 0/2] Ignore Energy Model with abstract scale in IPA and DTPM
Date: Tue, 8 Feb 2022 08:39:03 +0100	[thread overview]
Message-ID: <f63be987-a1a5-cf7e-8302-4ae6e87b6699@linaro.org> (raw)
In-Reply-To: <616307f7-b419-8e36-6879-6cf6f4e02d5a@arm.com>

On 07/02/2022 12:44, Lukasz Luba wrote:
> 
> 
> On 2/7/22 10:41 AM, Daniel Lezcano wrote:
>> On 07/02/2022 08:30, Lukasz Luba wrote:
>>> Hi all,
>>>
>>> The Energy Model supports abstract scale power values. This might cause
>>> issues for some mechanisms like thermal governor IPA or DTPM, which
>>> expect that all devices provide sane power values. This patch set 
>>> prevents
>>> from registering such devices for IPA and DTPM.
>>
>>
>> Does it mean for example big and little have both 0-100 ?
>>
>>
> 
> Unfortunately, these can be any numbers. I hope at least the CPUs
> Big and Little power have sense: Little power is not higher
> than Big power. The purpose of EM is to enable EAS, so this power
> relation between Big and Little should have sense. Someone
> who is not willing to or cannot expose real power values, still
> wants the EAS to operate (my assumption and hope). The SCMI FW can
> provide abstract power values. It's in the SCMI spec. Thus,
> creating these abstract scale power values for big.LITTLE the right
> way should result in properly working EAS.
> 
> I can also have hope for GPU vs. Big power, but it is a weaker hope.
> The second is more tricky to distinguish even if you have a domain
> knowledge, but not the real measurements with you. The GPU power
> values is also a 'sensitive' knowledge to share. Open source guys can do
> that (after measurements), but some vendor's engineers probably can't.

So basically, we don't know, right ?

At this point the different subsystems (cpufreq cooling device and dtpm) 
disabled by these patches can deal with abstract scale values, like they 
do today with the very approximate power numbers we have defined in the DT.

Let's wait and see how the different SoC vendors implement the SCMI spec.




-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

  reply	other threads:[~2022-02-08  7:39 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-07  7:30 [PATCH 0/2] Ignore Energy Model with abstract scale in IPA and DTPM Lukasz Luba
2022-02-07  7:30 ` [PATCH 1/2] thermal: cooling: Check Energy Model type in cpufreq_cooling and devfreq_cooling Lukasz Luba
2022-02-08  0:50   ` Matthias Kaehlcke
2022-02-08  9:32     ` Lukasz Luba
2022-02-08 17:25       ` Matthias Kaehlcke
2022-02-09 11:16         ` Lukasz Luba
2022-02-09 22:17           ` Matthias Kaehlcke
2022-02-16 15:35             ` Lukasz Luba
2022-02-16 17:33               ` Doug Anderson
2022-02-16 22:13                 ` Matthias Kaehlcke
2022-02-16 22:43                   ` Lukasz Luba
2022-02-17  0:26                     ` Matthias Kaehlcke
2022-02-17 10:15                     ` Daniel Lezcano
2022-02-17  9:59                   ` Daniel Lezcano
2022-02-17 10:10                 ` Daniel Lezcano
2022-02-17 10:47                   ` Lukasz Luba
2022-02-17 11:28                     ` Daniel Lezcano
2022-02-17 12:11                       ` Lukasz Luba
2022-02-17 12:33                         ` Daniel Lezcano
2022-02-17 12:37                           ` Lukasz Luba
2022-02-17 16:46                         ` Matthias Kaehlcke
2022-02-17 16:37                     ` Doug Anderson
2022-02-17 17:14                       ` Matthias Kaehlcke
2022-02-17 18:05                         ` Lukasz Luba
2022-02-17 18:27                       ` Daniel Lezcano
2022-02-16 17:21       ` Doug Anderson
2022-02-16 23:28         ` Lukasz Luba
2022-02-17 16:50           ` Doug Anderson
2022-02-17 17:58             ` Lukasz Luba
2022-02-17 18:18   ` Lukasz Luba
2022-02-22 17:05     ` Lukasz Luba
2022-02-22 18:12       ` Daniel Lezcano
2022-02-22 18:31         ` Lukasz Luba
2022-02-22 22:10           ` Daniel Lezcano
2022-02-23  9:10             ` Lukasz Luba
2022-02-07  7:30 ` [PATCH 2/2] powercap: DTPM: Check Energy Model type for power values scale Lukasz Luba
2022-02-07 10:41 ` [PATCH 0/2] Ignore Energy Model with abstract scale in IPA and DTPM Daniel Lezcano
2022-02-07 11:44   ` Lukasz Luba
2022-02-08  7:39     ` Daniel Lezcano [this message]
2022-02-08  9:47       ` Lukasz Luba

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=f63be987-a1a5-cf7e-8302-4ae6e87b6699@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=Pierre.Gondois@arm.com \
    --cc=amit.kachhap@gmail.com \
    --cc=amitk@kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=rafael@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=viresh.kumar@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).