From: Lukasz Luba <lukasz.luba@arm.com>
To: Qais Yousef <qyousef@layalina.io>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Xuewen Yan <xuewen.yan94@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
rafael@kernel.org, rui.zhang@intel.com,
amit.kucheria@verdurent.com, amit.kachhap@gmail.com,
daniel.lezcano@linaro.org, viresh.kumar@linaro.org,
len.brown@intel.com, pavel@ucw.cz, mhiramat@kernel.org,
wvw@google.com
Subject: Re: [PATCH v5 22/23] PM: EM: Add em_dev_compute_costs() as API for device drivers
Date: Wed, 20 Dec 2023 11:14:29 +0000 [thread overview]
Message-ID: <4c719764-7f30-4a22-8fcf-ebfd3cdcddb1@arm.com> (raw)
In-Reply-To: <44cb77d0-1d9a-47af-b699-e3019b520574@arm.com>
Hi Dietmar, Qais, Xuewen,
On 12/18/23 11:56, Lukasz Luba wrote:
> Hi Dietmar and Qais,
>
> On 12/17/23 18:03, Qais Yousef wrote:
>> On 12/12/23 19:50, Dietmar Eggemann wrote:
>>> On 29/11/2023 12:08, Lukasz Luba wrote:
>>>> The device drivers can modify EM at runtime by providing a new EM
>>>> table.
>>>> The EM is used by the EAS and the em_perf_state::cost stores
>>>> pre-calculated value to avoid overhead. This patch provides the API for
>>>> device drivers to calculate the cost values properly (and not duplicate
>>>> the same code).
>>>
>>> New interface w/o any users? Can we not remove this from this patch-set
>>> and introduce it with the first user(s)?
>
> I didn't wanted to introduce the user of this in the same patch set.
> I will send a follow up patch for Exynos SoC. More about this below.
>
>>
>> It's a chicken and egg problem. No interface, will not enable the new
>> users to
>> appear too. So assuming the interface makes sense, I vote to keep it.
>
> There are already in mainline platforms which will benefit from this
> feature and would use this API. The platform which support chip
> binning and adjust the voltage based on that information. It can be a
> driver which can even be built as a module. One example is Exynos5 ASV
> (Adaptive Supply Voltage) part of the Exynos chipid driver [1].
> Here is the dmesg log with some additional debug from this driver.
> As you can see the EM finished the registration and also update (the
> new feature from this patch set), but it worked on old Voltages from
> OPPs. (Also, this driver can be built as a module).
>
> -------------------------------------------------
> [ 4.651049] cpu cpu4: EM: created perf domain
> [ 4.654073] cpu cpu0: EM: OPP:1200000 is inefficient
> [ 4.654108] cpu cpu0: EM: OPP:1100000 is inefficient
> [ 4.654140] cpu cpu0: EM: OPP:900000 is inefficient
> [ 4.654173] cpu cpu0: EM: OPP:800000 is inefficient
> [ 4.654204] cpu cpu0: EM: OPP:600000 is inefficient
> [ 4.654235] cpu cpu0: EM: OPP:500000 is inefficient
> [ 4.654266] cpu cpu0: EM: OPP:400000 is inefficient
> [ 4.654297] cpu cpu0: EM: OPP:200000 is inefficient
> [ 4.654342] cpu cpu0: EM: updated
> ....
> [ 4.750026] exynos-chipid 10000000.chipid: cpu0 opp0, freq: 1500 missing
> [ 4.755329] exynos-chipid 10000000.chipid: Checking asv_volt=1175000
> opp_volt=1275000
> [ 4.763213] exynos-chipid 10000000.chipid: Checking asv_volt=1125000
> opp_volt=1250000
> [ 4.770982] exynos-chipid 10000000.chipid: Checking asv_volt=1075000
> opp_volt=1250000
> [ 4.778820] exynos-chipid 10000000.chipid: Checking asv_volt=1037500
> opp_volt=1250000
> [ 4.786515] exynos-chipid 10000000.chipid: Checking asv_volt=1000000
> opp_volt=1100000
> [ 4.794356] exynos-chipid 10000000.chipid: Checking asv_volt=962500
> opp_volt=1100000
> [ 4.802018] exynos-chipid 10000000.chipid: Checking asv_volt=925000
> opp_volt=1100000
> [ 4.816323] exynos-chipid 10000000.chipid: Checking asv_volt=900000
> opp_volt=1000000
> [ 4.824109] exynos-chipid 10000000.chipid: Checking asv_volt=900000
> opp_volt=1000000
> [ 4.839933] exynos-chipid 10000000.chipid: Checking asv_volt=900000
> opp_volt=1000000
> [ 4.854762] exynos-chipid 10000000.chipid: Checking asv_volt=900000
> opp_volt=1000000
> [ 4.866191] exynos-chipid 10000000.chipid: Checking asv_volt=900000
> opp_volt=900000
> [ 4.878812] exynos-chipid 10000000.chipid: Checking asv_volt=900000
> opp_volt=900000
> [ 4.886052] exynos-chipid 10000000.chipid: cpu4 opp0, freq: 2100 missing
> [ 4.892800] exynos-chipid 10000000.chipid: Checking asv_volt=1225000
> opp_volt=1312500
> [ 4.900542] exynos-chipid 10000000.chipid: Checking asv_volt=1162500
> opp_volt=1262500
> [ 4.908342] exynos-chipid 10000000.chipid: Checking asv_volt=1112500
> opp_volt=1237500
> [ 4.916066] exynos-chipid 10000000.chipid: Checking asv_volt=1075000
> opp_volt=1250000
> [ 4.923926] exynos-chipid 10000000.chipid: Checking asv_volt=1037500
> opp_volt=1250000
> [ 4.931707] exynos-chipid 10000000.chipid: Checking asv_volt=1000000
> opp_volt=1100000
> [ 4.939582] exynos-chipid 10000000.chipid: Checking asv_volt=975000
> opp_volt=1100000
> [ 4.947225] exynos-chipid 10000000.chipid: Checking asv_volt=950000
> opp_volt=1100000
> [ 4.954885] exynos-chipid 10000000.chipid: Checking asv_volt=925000
> opp_volt=1000000
> [ 4.962601] exynos-chipid 10000000.chipid: Checking asv_volt=900000
> opp_volt=1000000
> [ 4.974047] exynos-chipid 10000000.chipid: Checking asv_volt=900000
> opp_volt=1000000
> [ 4.974071] exynos-chipid 10000000.chipid: Checking asv_volt=900000
> opp_volt=1000000
> [ 4.993670] exynos-chipid 10000000.chipid: Checking asv_volt=900000
> opp_volt=900000
> [ 5.001163] exynos-chipid 10000000.chipid: Checking asv_volt=900000
> opp_volt=900000
> [ 5.008818] exynos-chipid 10000000.chipid: Checking asv_volt=900000
> opp_volt=900000
> [ 5.016318] exynos-chipid 10000000.chipid: Checking asv_volt=900000
> opp_volt=900000
> [ 5.023955] exynos-chipid 10000000.chipid: Checking asv_volt=900000
> opp_volt=900000
> [ 5.039723] exynos-chipid 10000000.chipid: Checking asv_volt=900000
> opp_volt=900000
> [ 5.054445] exynos-chipid 10000000.chipid: Checking asv_volt=900000
> opp_volt=900000
> [ 5.066709] exynos-chipid 10000000.chipid: Exynos: CPU[EXYNOS5800]
> PRO_ID[0xe5422000] REV[0x1] Detected
>
> -------------------------------------------------
>
> The new EM which would be updated from that driver, would have lower
> voltages as well as different 'inefficient OPPs'. The maximum voltage
> difference based on the tables is 13.54% which means for the dynamic
> power:
> 1362500 = 1.135416667 * 1200000
> P_dyn = C* f * (V*1.1354 * V*1.1354) = C*f*V^2 * 1.289
>
> That's ~29% different dynamic power (for one core).
>
> This Voltage adjustment is due to chip lottery. Different SoC vendors
> use different name for this fact.
> I only have this Exynos platform, but when this API
> and v5 features get in, the vendors can modify their drivers and test.
>
> This should help both: EAS and IPA/DTPM.
>
> Regards,
> Lukasz
>
> [1]
> https://elixir.bootlin.com/linux/latest/source/drivers/soc/samsung/exynos5422-asv.c
>
Because you wanted to see how this API is going to be used after
boot, I have send a follow-up patch for the OPP framework and Exynos
chip driver [1].
You can see there that all drivers which would need this feature would
share/use the same code in OPP. That OPP uses the EM new APIs.
I don't want to combine this as well in one step in this patch set.
I rather follow step-by-step development like in Arm SCMI.
Regards,
Lukasz
https://lore.kernel.org/lkml/20231220110339.1065505-1-lukasz.luba@arm.com/
next prev parent reply other threads:[~2023-12-20 11:13 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-29 11:08 [PATCH v5 00/23] Introduce runtime modifiable Energy Model Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 01/23] PM: EM: Add missing newline for the message log Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 02/23] PM: EM: Refactor em_cpufreq_update_efficiencies() arguments Lukasz Luba
2023-12-17 17:58 ` Qais Yousef
2023-12-19 10:30 ` Lukasz Luba
2023-12-28 16:59 ` Qais Yousef
2024-01-02 9:40 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 03/23] PM: EM: Find first CPU active while updating OPP efficiency Lukasz Luba
2023-12-17 17:58 ` Qais Yousef
2023-12-19 10:53 ` Lukasz Luba
2023-12-28 17:13 ` Qais Yousef
2024-01-02 9:42 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 04/23] PM: EM: Refactor em_pd_get_efficient_state() to be more flexible Lukasz Luba
2023-12-12 18:49 ` Dietmar Eggemann
2023-12-19 10:58 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 05/23] PM: EM: Refactor a new function em_compute_costs() Lukasz Luba
2023-12-17 17:58 ` Qais Yousef
2023-12-19 10:59 ` Lukasz Luba
2023-12-28 17:14 ` Qais Yousef
2024-01-02 9:43 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 06/23] PM: EM: Check if the get_cost() callback is present in em_compute_costs() Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 07/23] PM: EM: Refactor how the EM table is allocated and populated Lukasz Luba
2023-12-12 18:50 ` Dietmar Eggemann
2023-12-19 13:19 ` Lukasz Luba
2023-12-17 17:59 ` Qais Yousef
2023-11-29 11:08 ` [PATCH v5 08/23] PM: EM: Introduce runtime modifiable table Lukasz Luba
2023-12-12 18:50 ` Dietmar Eggemann
2023-12-19 11:33 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 09/23] PM: EM: Use runtime modified EM for CPUs energy estimation in EAS Lukasz Luba
2023-12-17 17:59 ` Qais Yousef
2023-12-19 4:03 ` Xuewen Yan
2023-12-19 8:32 ` Lukasz Luba
2023-12-28 17:32 ` Qais Yousef
2024-01-02 11:17 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 10/23] PM: EM: Add API for memory allocations for new tables Lukasz Luba
2023-12-17 17:59 ` Qais Yousef
2023-12-19 8:45 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 11/23] PM: EM: Add API for updating the runtime modifiable EM Lukasz Luba
2023-12-12 18:50 ` Dietmar Eggemann
2023-12-20 8:06 ` Lukasz Luba
2024-01-04 15:45 ` Dietmar Eggemann
2024-01-04 16:55 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 12/23] PM: EM: Add helpers to read under RCU lock the EM table Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 13/23] PM: EM: Add performance field to struct em_perf_state Lukasz Luba
2023-12-17 18:00 ` Qais Yousef
2023-12-20 8:21 ` Lukasz Luba
2023-12-28 17:45 ` Qais Yousef
2023-11-29 11:08 ` [PATCH v5 14/23] PM: EM: Support late CPUs booting and capacity adjustment Lukasz Luba
2023-12-12 18:50 ` Dietmar Eggemann
2023-12-20 8:23 ` Lukasz Luba
2023-12-17 18:00 ` Qais Yousef
2024-01-02 11:39 ` Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 15/23] PM: EM: Optimize em_cpu_energy() and remove division Lukasz Luba
2023-12-12 18:50 ` Dietmar Eggemann
2023-12-20 8:42 ` Lukasz Luba
2024-01-04 16:30 ` Dietmar Eggemann
2024-01-04 16:56 ` Lukasz Luba
2023-12-28 18:06 ` Qais Yousef
2024-01-02 11:47 ` Lukasz Luba
2024-01-04 19:23 ` Qais Yousef
2024-01-10 13:53 ` Lukasz Luba
2024-01-15 12:21 ` Qais Yousef
2024-01-15 12:36 ` Lukasz Luba
2024-01-16 13:10 ` Qais Yousef
2024-01-16 15:34 ` Lukasz Luba
2024-01-16 19:33 ` Qais Yousef
2023-11-29 11:08 ` [PATCH v5 16/23] powercap/dtpm_cpu: Use new Energy Model interface to get table Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 17/23] powercap/dtpm_devfreq: " Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 18/23] drivers/thermal/cpufreq_cooling: Use new Energy Model interface Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 19/23] drivers/thermal/devfreq_cooling: " Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 20/23] PM: EM: Change debugfs configuration to use runtime EM table data Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 21/23] PM: EM: Remove old table Lukasz Luba
2023-11-29 11:08 ` [PATCH v5 22/23] PM: EM: Add em_dev_compute_costs() as API for device drivers Lukasz Luba
2023-12-12 18:50 ` Dietmar Eggemann
2023-12-17 18:03 ` Qais Yousef
2023-12-18 11:56 ` Lukasz Luba
2023-12-20 11:14 ` Lukasz Luba [this message]
2023-11-29 11:08 ` [PATCH v5 23/23] Documentation: EM: Update with runtime modification design Lukasz Luba
2023-12-12 18:51 ` Dietmar Eggemann
2023-12-19 9:35 ` Lukasz Luba
2023-12-19 4:42 ` Xuewen Yan
2023-12-19 8:47 ` Lukasz Luba
2023-12-19 6:22 ` Xuewen Yan
2023-12-19 9:32 ` Lukasz Luba
2023-12-20 2:08 ` Xuewen Yan
2023-12-20 7:57 ` Lukasz Luba
2023-12-12 18:48 ` [PATCH v5 00/23] Introduce runtime modifiable Energy Model Dietmar Eggemann
2023-12-13 9:23 ` Lukasz Luba
2023-12-13 11:34 ` Dietmar Eggemann
2023-12-13 11:45 ` Rafael J. Wysocki
2023-12-13 12:20 ` Lukasz Luba
2023-12-12 18:49 ` Rafael J. Wysocki
2023-12-13 9:32 ` Lukasz Luba
2023-12-13 13:40 ` Hongyan Xia
2023-12-13 13:16 ` Lukasz Luba
2023-12-17 18:22 ` Qais Yousef
2023-12-19 10:22 ` Lukasz Luba
2023-12-28 18:41 ` Qais Yousef
2024-01-02 12:12 ` 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=4c719764-7f30-4a22-8fcf-ebfd3cdcddb1@arm.com \
--to=lukasz.luba@arm.com \
--cc=amit.kachhap@gmail.com \
--cc=amit.kucheria@verdurent.com \
--cc=daniel.lezcano@linaro.org \
--cc=dietmar.eggemann@arm.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=pavel@ucw.cz \
--cc=qyousef@layalina.io \
--cc=rafael@kernel.org \
--cc=rui.zhang@intel.com \
--cc=viresh.kumar@linaro.org \
--cc=wvw@google.com \
--cc=xuewen.yan94@gmail.com \
/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