Message ID | 20230925081139.1305766-9-lukasz.luba@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:cae8:0:b0:403:3b70:6f57 with SMTP id r8csp1054282vqu; Mon, 25 Sep 2023 01:20:47 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFCpPYh1Lc+lVEMiqzhWPiQdcXwUVGPpGGwODlCLTzOpxSLEtJJ+OEv3pSvyDfpNb5UWYqe X-Received: by 2002:a9d:63d0:0:b0:6c4:897a:31d0 with SMTP id e16-20020a9d63d0000000b006c4897a31d0mr7239796otl.24.1695630047313; Mon, 25 Sep 2023 01:20:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695630047; cv=none; d=google.com; s=arc-20160816; b=wGhwAX+ML4WdvkGrUNxv+ldBqlZMbeL0Wck8Daa2CDuwGi8nQKMGbkmV8BgyBwoiAj 90YMPsnkrQgiAawZi0cI4kN4LOSyx81fLvsCpFPfy+d35ZjB77mFYjg728yBoAoXNFFy 9GjdCxU8faTup4QDvF5L5lehSKShahkwrbfqmfIpgJJ86eFfdoe6pyJqQnXYobHm6rR5 lgceYFPXmGiFgG1pz3F20HJxiuwyAjq8LGhY832mOlNzwWNX+Uu8IqtN+JsfVv+3euwn gKNd3+LWMlF2G0jgdLpEAKo6HfRvqIj496ouqsXxwPcPaGbDjAWw1XE0Z8hceJxgpDMV 8lgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=zWVE9oZix7BsBjximY0f8NX0YqxMrKBiowdm1HBWcJQ=; fh=jF+j1UEDAwnYbShW3HmO1TshMsWh36Jt7pSLTP62NeE=; b=t8yUov2t9UotHz+bmpNGi/Ig2qm4oAzuT/u4JNhdV7HKtD+Qpe7uct2s3aqdEd2Y+U +Z2nwJ3lQn5aKn0D8+5N/AjnCMUaYJxjev4KnASbB0zyCKkiEK4o9STaupVq5Y5zWvFJ woDiYXqxOMZ4WE1Ta/fHSRIaEI6+cvKilnCJveFfRfKbOVAF1oZIsZg96Pby8krCPB5j EPv+e9rvZ0YQ5fOfOmWqahJMME7NUgSi6WcfyltiUEtTdFBwic6sv0ecvQqUR6mnHreO zWgLD/wwTZ/tM0iXnagZd0bj2BKfDUnkVFt8oU7jRNXWH0xN9gwosg3/b8iMngIUy3Sg jE3w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id d19-20020a637353000000b0055b43079640si9710207pgn.707.2023.09.25.01.20.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 01:20:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id D304280E224D; Mon, 25 Sep 2023 01:12:12 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232693AbjIYIME (ORCPT <rfc822;ezelljr.billy@gmail.com> + 30 others); Mon, 25 Sep 2023 04:12:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42418 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232768AbjIYILl (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 25 Sep 2023 04:11:41 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 672141AC; Mon, 25 Sep 2023 01:11:34 -0700 (PDT) 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 5E703DA7; Mon, 25 Sep 2023 01:12:12 -0700 (PDT) Received: from e129166.arm.com (unknown [10.57.93.139]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id B604D3F5A1; Mon, 25 Sep 2023 01:11:31 -0700 (PDT) From: Lukasz Luba <lukasz.luba@arm.com> To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, rafael@kernel.org Cc: lukasz.luba@arm.com, dietmar.eggemann@arm.com, 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, qyousef@layalina.io, wvw@google.com Subject: [PATCH v4 08/18] PM: EM: Add update_power() callback for runtime modifications Date: Mon, 25 Sep 2023 09:11:29 +0100 Message-Id: <20230925081139.1305766-9-lukasz.luba@arm.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230925081139.1305766-1-lukasz.luba@arm.com> References: <20230925081139.1305766-1-lukasz.luba@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Mon, 25 Sep 2023 01:12:13 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777996972814941705 X-GMAIL-MSGID: 1777996972814941705 |
Series |
Introduce runtime modifiable Energy Model
|
|
Commit Message
Lukasz Luba
Sept. 25, 2023, 8:11 a.m. UTC
The Energy Model (EM) is going to support runtime modifications. This
new callback would be used in the upcoming EM changes. The drivers
or frameworks which want to modify the EM have to implement the
update_power() callback.
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
---
include/linux/energy_model.h | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
Comments
On Mon, Sep 25, 2023 at 10:11 AM Lukasz Luba <lukasz.luba@arm.com> wrote: > > The Energy Model (EM) is going to support runtime modifications. This > new callback would be used in the upcoming EM changes. The drivers > or frameworks which want to modify the EM have to implement the > update_power() callback. > > Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> > --- > include/linux/energy_model.h | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h > index d236e08e80dc..546dee90f716 100644 > --- a/include/linux/energy_model.h > +++ b/include/linux/energy_model.h > @@ -168,6 +168,26 @@ struct em_data_callback { > */ > int (*get_cost)(struct device *dev, unsigned long freq, > unsigned long *cost); > + > + /** > + * update_power() - Provide new power at the given performance state of > + * a device The meaning of the above is unclear to me. > + * @dev : Device for which we do this operation (can be a CPU) It is unclear what "we" means in this context. Maybe say "Target device (can be a CPU)"? > + * @freq : Frequency at the performance state in kHz What performance state does this refer to? And the frequency of what? > + * @power : New power value at the performance state > + * (modified) Similarly unclear as the above. > + * @priv : Pointer to private data useful for tracking context > + * during runtime modifications of EM. Who's going to set this pointer and use this data? > + * > + * The update_power() is used by runtime modifiable EM. It aims to I would drop "The" from the above. > + * provide updated power value for a given frequency, which is stored > + * in the performance state. A given frequency of what and the performance state of what does this refer to? > + The power value provided by this callback > + * should fit in the [0, EM_MAX_POWER] range. > + * > + * Return 0 on success, or appropriate error value in case of failure. > + */ > + int (*update_power)(struct device *dev, unsigned long freq, > + unsigned long *power, void *priv); > }; > #define EM_SET_ACTIVE_POWER_CB(em_cb, cb) ((em_cb).active_power = cb) > #define EM_ADV_DATA_CB(_active_power_cb, _cost_cb) \ > @@ -175,6 +195,7 @@ struct em_data_callback { > .get_cost = _cost_cb } > #define EM_DATA_CB(_active_power_cb) \ > EM_ADV_DATA_CB(_active_power_cb, NULL) > +#define EM_UPDATE_CB(_update_power_cb) { .update_power = &_update_power_cb } > > struct em_perf_domain *em_cpu_get(int cpu); > struct em_perf_domain *em_pd_get(struct device *dev); > @@ -331,6 +352,7 @@ struct em_data_callback {}; > #define EM_ADV_DATA_CB(_active_power_cb, _cost_cb) { } > #define EM_DATA_CB(_active_power_cb) { } > #define EM_SET_ACTIVE_POWER_CB(em_cb, cb) do { } while (0) > +#define EM_UPDATE_CB(_update_cb) { } > > static inline > int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states, > --
On 9/26/23 19:59, Rafael J. Wysocki wrote: > On Mon, Sep 25, 2023 at 10:11 AM Lukasz Luba <lukasz.luba@arm.com> wrote: >> >> The Energy Model (EM) is going to support runtime modifications. This >> new callback would be used in the upcoming EM changes. The drivers >> or frameworks which want to modify the EM have to implement the >> update_power() callback. >> >> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> >> --- >> include/linux/energy_model.h | 22 ++++++++++++++++++++++ >> 1 file changed, 22 insertions(+) >> >> diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h >> index d236e08e80dc..546dee90f716 100644 >> --- a/include/linux/energy_model.h >> +++ b/include/linux/energy_model.h >> @@ -168,6 +168,26 @@ struct em_data_callback { >> */ >> int (*get_cost)(struct device *dev, unsigned long freq, >> unsigned long *cost); >> + >> + /** >> + * update_power() - Provide new power at the given performance state of >> + * a device > > The meaning of the above is unclear to me. I can try to rephrase this a bit: ' Provide a new power value for the device at the given frequency. This allows to reflect changed power profile in runtime.' > >> + * @dev : Device for which we do this operation (can be a CPU) > > It is unclear what "we" means in this context. Maybe say "Target > device (can be a CPU)"? That sounds better indeed. > >> + * @freq : Frequency at the performance state in kHz > > What performance state does this refer to? And the frequency of what? We just call the entry in EM the 'performance state' (so frequency and power). I will rephrase this as well: 'Frequency of the @dev expressed in kHz' > >> + * @power : New power value at the performance state >> + * (modified) > > Similarly unclear as the above. OK, it can be re-written as: 'Power value of the @dev at the given @freq (modified)' > >> + * @priv : Pointer to private data useful for tracking context >> + * during runtime modifications of EM. > > Who's going to set this pointer and use this data? The driver or kernel module, which is aware about thermal events. Those events might be coming from FW to kernel, but we need to maintain the same 'context' for all OPPs when we start the EM update. This 'priv' field is used for passing the 'context' back to the caller, so the caller can consistently the update. The update might be with some math formula which multiplies the power by some factor value (based on thermal model and current temperature). > >> + * >> + * The update_power() is used by runtime modifiable EM. It aims to > > I would drop "The" from the above. OK > >> + * provide updated power value for a given frequency, which is stored >> + * in the performance state. > > A given frequency of what and the performance state of what does this refer to? I will change that and add the '@dev' word to make this more precised. 'update_power() is used by runtime modifiable EM. It aims to update the @dev EM power values for all registered frequencies.'
On Fri, Sep 29, 2023 at 10:59 AM Lukasz Luba <lukasz.luba@arm.com> wrote: > > On 9/26/23 19:59, Rafael J. Wysocki wrote: > > On Mon, Sep 25, 2023 at 10:11 AM Lukasz Luba <lukasz.luba@arm.com> wrote: > >> > >> The Energy Model (EM) is going to support runtime modifications. This > >> new callback would be used in the upcoming EM changes. The drivers > >> or frameworks which want to modify the EM have to implement the > >> update_power() callback. > >> > >> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> > >> --- > >> include/linux/energy_model.h | 22 ++++++++++++++++++++++ > >> 1 file changed, 22 insertions(+) > >> > >> diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h > >> index d236e08e80dc..546dee90f716 100644 > >> --- a/include/linux/energy_model.h > >> +++ b/include/linux/energy_model.h > >> @@ -168,6 +168,26 @@ struct em_data_callback { > >> */ > >> int (*get_cost)(struct device *dev, unsigned long freq, > >> unsigned long *cost); > >> + > >> + /** > >> + * update_power() - Provide new power at the given performance state of > >> + * a device > > > > The meaning of the above is unclear to me. > > I can try to rephrase this a bit: > ' Provide a new power value for the device at the given frequency. This > allows to reflect changed power profile in runtime.' Maybe "Estimate power for a given device frequency" > > > >> + * @dev : Device for which we do this operation (can be a CPU) > > > > It is unclear what "we" means in this context. Maybe say "Target > > device (can be a CPU)"? > > That sounds better indeed. > > > > >> + * @freq : Frequency at the performance state in kHz > > > > What performance state does this refer to? And the frequency of what? > > We just call the entry in EM the 'performance state' (so frequency and > power). I will rephrase this as well: > 'Frequency of the @dev expressed in kHz' Or "Device frequency for which to estimate power"? > > > >> + * @power : New power value at the performance state > >> + * (modified) > > > > Similarly unclear as the above. > > OK, it can be re-written as: > 'Power value of the @dev at the given @freq (modified)' This is not a power value, but a return pointer AFAICS. So "location to store the return power value". > > > >> + * @priv : Pointer to private data useful for tracking context > >> + * during runtime modifications of EM. > > > > Who's going to set this pointer and use this data? > > The driver or kernel module, which is aware about thermal events. Those > events might be coming from FW to kernel, but we need to maintain > the same 'context' for all OPPs when we start the EM update. > > This 'priv' field is used for passing the 'context' back to the > caller, so the caller can consistently the update. The update might > be with some math formula which multiplies the power by some factor > value (based on thermal model and current temperature). I would say "Additional data for the callback function, provided by the entity setting the callback pointer". > > > >> + * > >> + * The update_power() is used by runtime modifiable EM. It aims to > > > > I would drop "The" from the above. > > OK > > > > >> + * provide updated power value for a given frequency, which is stored > >> + * in the performance state. > > > > A given frequency of what and the performance state of what does this refer to? > > I will change that and add the '@dev' word to make this more precised. That would help. Overall, I would say "is used by ... to obtain a new power value for a given frequency of @dev". > > 'update_power() is used by runtime modifiable EM. It aims to update the > @dev EM power values for all registered frequencies.'
diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h index d236e08e80dc..546dee90f716 100644 --- a/include/linux/energy_model.h +++ b/include/linux/energy_model.h @@ -168,6 +168,26 @@ struct em_data_callback { */ int (*get_cost)(struct device *dev, unsigned long freq, unsigned long *cost); + + /** + * update_power() - Provide new power at the given performance state of + * a device + * @dev : Device for which we do this operation (can be a CPU) + * @freq : Frequency at the performance state in kHz + * @power : New power value at the performance state + * (modified) + * @priv : Pointer to private data useful for tracking context + * during runtime modifications of EM. + * + * The update_power() is used by runtime modifiable EM. It aims to + * provide updated power value for a given frequency, which is stored + * in the performance state. The power value provided by this callback + * should fit in the [0, EM_MAX_POWER] range. + * + * Return 0 on success, or appropriate error value in case of failure. + */ + int (*update_power)(struct device *dev, unsigned long freq, + unsigned long *power, void *priv); }; #define EM_SET_ACTIVE_POWER_CB(em_cb, cb) ((em_cb).active_power = cb) #define EM_ADV_DATA_CB(_active_power_cb, _cost_cb) \ @@ -175,6 +195,7 @@ struct em_data_callback { .get_cost = _cost_cb } #define EM_DATA_CB(_active_power_cb) \ EM_ADV_DATA_CB(_active_power_cb, NULL) +#define EM_UPDATE_CB(_update_power_cb) { .update_power = &_update_power_cb } struct em_perf_domain *em_cpu_get(int cpu); struct em_perf_domain *em_pd_get(struct device *dev); @@ -331,6 +352,7 @@ struct em_data_callback {}; #define EM_ADV_DATA_CB(_active_power_cb, _cost_cb) { } #define EM_DATA_CB(_active_power_cb) { } #define EM_SET_ACTIVE_POWER_CB(em_cb, cb) do { } while (0) +#define EM_UPDATE_CB(_update_cb) { } static inline int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,