Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp4522321pxb; Tue, 2 Nov 2021 11:04:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwwooftCvpF0mILnPqjxxFxjRCoDtuaLyLmGVZpSYd6wkO/dMhLDCSjdvR6CTnVp+Blw0Y/ X-Received: by 2002:a17:906:9b8f:: with SMTP id dd15mr39534069ejc.99.1635876286229; Tue, 02 Nov 2021 11:04:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635876286; cv=none; d=google.com; s=arc-20160816; b=fnSTDAWMDZiDh8mfuXZWYcKCbpwpVypanPdPlpZvCcKyjYdr2YHjAd5DDUtQ39MXMg jQw29QQP3zzjiVCFnZC3j+QnrQ+Vbf9/MGRD8kAu/cgsivYoBkVThV1B7f5JX86Mvy5M QC0xkn52CkLDPvXIfw/4l6TnonjKSGKXQgqoYhPCiIRHcnnrvBaaZdl97PvsnGFE6Dvb kcXoEv7jt9HgXhzbUPzfLCg8IzlC9iNLWhGVSvB+FBnD0YPxhuTO3/1y5iHdhHuAPimj M+lds0VSdsY8S7I9BDaoKsRxr7Qs2oghypZRyMmkmuwGpCL0qYcj0b7bLc/OVjrsia0e GxHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from; bh=O/62+I9nGCkxgwDbZ6OkhuwZaqSzpxO6kBx7mKtrkOc=; b=YOzcR0NHyyYt/UoJaxOaj3EPqchVIVl5lvVefpbPgZ/qUcXWRcLPzqnIFZGTHbEOD/ mRok6XtX8mhoc5FoXmZ8/4yZ96XE6vc1fsfym4/YWpo/0mDCksb8aT3Ph16X2DsDF32l U76nnUsXLjvort/9X5AkhBI0MsiH3YVKMx2vqSLBQooKYXB/Ip3v8Gjmy7VswW28UPuJ ObEN2JO00mq2Hc3x5LWvXE2OVEhTVSJOnlPB/aUbv1ZMs7I188H0O9AvbemzGi8T6DR7 sirdxujDdk4j4dAID8LrZAthaEUj35K1r2SXnd3I21bxKvhlzpkxfVkjdqZrvpbGg8E8 rlVQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ht19si8526213ejc.81.2021.11.02.11.04.20; Tue, 02 Nov 2021 11:04:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234670AbhKBSEc (ORCPT + 99 others); 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-kernel@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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- 2.17.1