From patchwork Tue Nov 2 18:01:43 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lukasz Luba X-Patchwork-Id: 12599433 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D617EC433EF for ; Tue, 2 Nov 2021 18:01:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B3ED961053 for ; Tue, 2 Nov 2021 18:01:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231506AbhKBSEa (ORCPT ); Tue, 2 Nov 2021 14:04:30 -0400 Received: from foss.arm.com ([217.140.110.172]:41138 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231137AbhKBSEa (ORCPT ); Tue, 2 Nov 2021 14:04:30 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EE1B511B3; Tue, 2 Nov 2021 11:01:54 -0700 (PDT) Received: from e123648.arm.com (unknown [10.57.28.163]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 7EEDF3F7B4; Tue, 2 Nov 2021 11:01:53 -0700 (PDT) From: Lukasz Luba To: linux-kernel@vger.kernel.org Cc: lukasz.luba@arm.com, dietmar.eggemann@arm.com, rafael@kernel.org, linux-pm@vger.kernel.org Subject: [PATCH 1/2] Documentation: power: Add description about new callback for EM registration Date: Tue, 2 Nov 2021 18:01:43 +0000 Message-Id: <20211102180144.1647-1-lukasz.luba@arm.com> X-Mailer: git-send-email 2.17.1 Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org The Energy Model (EM) registration for CPUs should now be done using a dedicated callback added recently into CPUFreq framework and drivers. Commit c17495b01b72 ("cpufreq: Add callback to register with energy model") The callback guaranties that the EM registration is called at the right time during driver setup. To avoid mistakes update the documentation to align with the existing code implementation. Signed-off-by: Lukasz Luba --- Documentation/power/energy-model.rst | 31 ++++++++++++++-------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst index 8a2788afe89b..7af0e1760962 100644 --- a/Documentation/power/energy-model.rst +++ b/Documentation/power/energy-model.rst @@ -138,6 +138,10 @@ or in Section 2.4 3. Example driver ----------------- +The CPUFreq framework supports dedicated callback for registering +the EM for a given CPU(s) 'policy' object: cpufreq_driver::register_em(). +That callback has to be implemented properly for a given driver, +because the framework would call it at the right time during setup. This section provides a simple example of a CPUFreq driver registering a performance domain in the Energy Model framework using the (fake) 'foo' protocol. The driver implements an est_power() function to be provided to the @@ -167,25 +171,22 @@ EM framework:: 20 return 0; 21 } 22 - 23 static int foo_cpufreq_init(struct cpufreq_policy *policy) + 23 static void foo_cpufreq_register_em(struct cpufreq_policy *policy) 24 { 25 struct em_data_callback em_cb = EM_DATA_CB(est_power); 26 struct device *cpu_dev; - 27 int nr_opp, ret; + 27 int nr_opp; 28 29 cpu_dev = get_cpu_device(cpumask_first(policy->cpus)); 30 - 31 /* Do the actual CPUFreq init work ... */ - 32 ret = do_foo_cpufreq_init(policy); - 33 if (ret) - 34 return ret; - 35 - 36 /* Find the number of OPPs for this policy */ - 37 nr_opp = foo_get_nr_opp(policy); + 31 /* Find the number of OPPs for this policy */ + 32 nr_opp = foo_get_nr_opp(policy); + 33 + 34 /* And register the new performance domain */ + 35 em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus, + 36 true); + 37 } 38 - 39 /* And register the new performance domain */ - 40 em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus, - 41 true); - 42 - 43 return 0; - 44 } + 39 static struct cpufreq_driver foo_cpufreq_driver = { + 40 .register_em = foo_cpufreq_register_em, + 41 }; From patchwork Tue Nov 2 18:01:44 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lukasz Luba X-Patchwork-Id: 12599435 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DCEE1C433EF for ; Tue, 2 Nov 2021 18:01:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BED8761105 for ; Tue, 2 Nov 2021 18:01:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231137AbhKBSEc (ORCPT ); Tue, 2 Nov 2021 14:04:32 -0400 Received: from foss.arm.com ([217.140.110.172]:41142 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234282AbhKBSEc (ORCPT ); Tue, 2 Nov 2021 14:04:32 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D614011B3; Tue, 2 Nov 2021 11:01:56 -0700 (PDT) Received: from e123648.arm.com (unknown [10.57.28.163]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 5F3C33F7B4; Tue, 2 Nov 2021 11:01:55 -0700 (PDT) From: Lukasz Luba To: linux-kernel@vger.kernel.org Cc: lukasz.luba@arm.com, dietmar.eggemann@arm.com, rafael@kernel.org, linux-pm@vger.kernel.org Subject: [PATCH 2/2] Documentation: power: Describe 'advanced' and 'simple' EM models Date: Tue, 2 Nov 2021 18:01:44 +0000 Message-Id: <20211102180144.1647-2-lukasz.luba@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20211102180144.1647-1-lukasz.luba@arm.com> References: <20211102180144.1647-1-lukasz.luba@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org The Energy Model (EM) can be registered in two ways: 1) Using a helper function, which under the hood relies on OPP framework and DT entry in CPU node: 'dynamic-power-coefficient'. This is a 'simple' EM because it's tight to the math formula: Power = dynamic-power-coefficient * V^2 * f 2) Using em_dev_register_perf_domain() API function with a driver custom callback which provides power for each performance state. This is an 'advanced' EM, since it can better reflect real power measurements for each performance state. It's not limited to any math formula and can better reflect real physics of the device. Add description of these two methods to the documentation, so developers could choose the suitable registration method (option). Signed-off-by: Lukasz Luba --- Documentation/power/energy-model.rst | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst index 7af0e1760962..5ac62a7b4b7c 100644 --- a/Documentation/power/energy-model.rst +++ b/Documentation/power/energy-model.rst @@ -84,6 +84,16 @@ CONFIG_ENERGY_MODEL must be enabled to use the EM framework. 2.2 Registration of performance domains ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Registration of 'advanced' EM +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The 'advanced' EM gets it's name due to the fact that the driver is allowed +to provide more precised power model. It's not limited to some implemented math +formula in the framework (like it's in 'simple' EM case). It can better reflect +the real power measurements performed for each performance state. Thus, this +registration method should be preferred in case considering EM static power +(leakage) is important. + Drivers are expected to register performance domains into the EM framework by calling the following API:: @@ -103,6 +113,18 @@ to: return warning/error, stop working or panic. See Section 3. for an example of driver implementing this callback, or Section 2.4 for further documentation on this API +Registration of 'simple' EM +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The 'simple' EM is registered using the framework helper function +cpufreq_register_em_with_opp(). It implements a power model which is tight to +math formula:: + + Power = C * V^2 * f + +The EM which is registered using this method might not reflect correctly the +physics of a real device, e.g. when static power (leakage) is important. + 2.3 Accessing performance domains ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^