From: "Zhang, Rui" <rui.zhang@intel.com>
To: "ville.syrjala@linux.intel.com" <ville.syrjala@linux.intel.com>
Cc: "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
"daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Pandruvada, Srinivas" <srinivas.pandruvada@intel.com>
Subject: Re: [PATCH v2 09/15] powercap/intel_rapl: Cleanup Power Limits support
Date: Wed, 6 Sep 2023 03:14:06 +0000 [thread overview]
Message-ID: <ae58059aed29f2c9e1e99ad67046881e43942eaf.camel@intel.com> (raw)
In-Reply-To: <ZPbJBanVmoMuOhMR@intel.com>
Hi, Ville,
On Tue, 2023-09-05 at 09:21 +0300, Ville Syrjälä wrote:
> On Wed, Apr 19, 2023 at 10:44:13AM +0800, Zhang Rui wrote:
> > The same set of operations are shared by different Powert Limits,
> > including Power Limit get/set, Power Limit enable/disable, clamping
> > enable/disable, time window get/set, and max power get/set, etc.
> >
> > But the same operation for different Power Limit has different
> > primitives because they use different registers/register bits.
> >
> > A lot of dirty/duplicate code was introduced to handle this
> > difference.
> >
> > Introduce a universal way to issue Power Limit operations.
> > Instead of using hardcoded primitive name directly, use Power Limit
> > id
> > + operation type, and hide all the Power Limit difference details
> > in a
> > central place, get_pl_prim(). Two helpers, rapl_read_pl_data() and
> > rapl_write_pl_data(), are introduced at the same time to simplify
> > the
> > code for issuing Power Limit operations.
> >
> > Signed-off-by: Zhang Rui <rui.zhang@intel.com>
> > Tested-by: Wang Wendy <wendy.wang@intel.com>
> > ---
> > drivers/powercap/intel_rapl_common.c | 343 ++++++++++++-----------
> > ----
> > include/linux/intel_rapl.h | 1 -
> > 2 files changed, 146 insertions(+), 198 deletions(-)
> >
> > diff --git a/drivers/powercap/intel_rapl_common.c
> > b/drivers/powercap/intel_rapl_common.c
> > index 8e77df42257a..7f80c35e5c86 100644
> > --- a/drivers/powercap/intel_rapl_common.c
> > +++ b/drivers/powercap/intel_rapl_common.c
> <snip>
> > @@ -818,6 +778,33 @@ static int rapl_write_data_raw(struct
> > rapl_domain *rd,
> > return ret;
> > }
> >
> > +static int rapl_read_pl_data(struct rapl_domain *rd, int pl,
> > + enum pl_prims pl_prim, bool xlate,
> > u64 *data)
> > +{
> > + enum rapl_primitives prim = get_pl_prim(pl, pl_prim);
> > +
> > + if (!is_pl_valid(rd, pl))
> > + return -EINVAL;
> > +
> > + return rapl_read_data_raw(rd, prim, xlate, data);
> > +}
> > +
> > +static int rapl_write_pl_data(struct rapl_domain *rd, int pl,
> > + enum pl_prims pl_prim,
> > + unsigned long long value)
> > +{
> > + enum rapl_primitives prim = get_pl_prim(pl, pl_prim);
> > +
> > + if (!is_pl_valid(rd, pl))
> > + return -EINVAL;
> > +
> > + if (rd->state & DOMAIN_STATE_BIOS_LOCKED) {
> > + pr_warn("%s:%s:%s locked by BIOS\n", rd->rp->name,
> > rd->name, pl_names[pl]);
> > + return -EACCES;
>
> This seems to be causing a lot of WARN level dmesg spam [1] during
> suspend/resume on several machines. I suppose previously the
> warning was only printed when trying to change the limits explicitly,
Before this patch, when enabling a power limit, it doesn't give a
warning but returns -EACCES directly.
After this patch, it gives a warning when any change is made to a
locked power limit, and this includes enabling/setting the power limit,
changing the time window, etc.
So I think in your case, the RAPL Package domain is enabled upon resume
for some reason, maybe requested by thermald, and that's why we see
this new warning.
The below change keeps the previous logic, can you confirm this?
IMO, the new logic is right because making any change to a
locked power limit is meaningless.
Srinivas,
Do we check if a domain/power_limit is locked before we enabling it in
thermald?
thanks,
rui
diff --git a/drivers/powercap/intel_rapl_common.c
b/drivers/powercap/intel_rapl_common.c
index 5c2e6d5eea2a..f6816a91d027 100644
--- a/drivers/powercap/intel_rapl_common.c
+++ b/drivers/powercap/intel_rapl_common.c
@@ -893,7 +893,7 @@ static int rapl_write_pl_data(struct rapl_domain
*rd, int pl,
if (!is_pl_valid(rd, pl))
return -EINVAL;
- if (rd->rpl[pl].locked) {
+ if (rd->rpl[pl].locked && pl_prim == PL_LIMIT) {
pr_warn("%s:%s:%s locked by BIOS\n", rd->rp->name, rd-
>name, pl_names[pl]);
return -EACCES;
}
next prev parent reply other threads:[~2023-09-06 3:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-19 2:44 [PATCH v2 0/15] powercap/intel_rapl: Introduce RAPL TPMI support Zhang Rui
2023-04-19 2:44 ` [PATCH v2 01/15] powercap/intel_rapl: Remove unused field in struct rapl_if_priv Zhang Rui
2023-04-19 2:44 ` [PATCH v2 02/15] powercap/intel_rapl: Allow probing without CPUID match Zhang Rui
2023-04-19 2:44 ` [PATCH v2 03/15] powercap/intel_rapl: Support per Interface rapl_defaults Zhang Rui
2023-04-19 2:44 ` [PATCH v2 04/15] powercap/intel_rapl: Support per Interface primitive information Zhang Rui
2023-04-19 2:44 ` [PATCH v2 05/15] powercap/intel_rapl: Support per domain energy/power/time unit Zhang Rui
2023-04-19 2:44 ` [PATCH v2 06/15] powercap/intel_rapl: Use index to initialize primitive information Zhang Rui
2023-04-19 2:44 ` [PATCH v2 07/15] powercap/intel_rapl: Change primitive order Zhang Rui
2023-04-19 2:44 ` [PATCH v2 08/15] powercap/intel_rapl: Use bitmap for Power Limits Zhang Rui
2023-04-19 2:44 ` [PATCH v2 09/15] powercap/intel_rapl: Cleanup Power Limits support Zhang Rui
2023-09-05 6:21 ` Ville Syrjälä
2023-09-06 3:14 ` Zhang, Rui [this message]
2023-09-06 15:32 ` Pandruvada, Srinivas
2023-04-19 2:44 ` [PATCH v2 10/15] powercap/intel_rapl: Add support for lock bit per Power Limit Zhang Rui
2023-04-19 2:44 ` [PATCH v2 11/15] powercap/intel_rapl: Remove redundant cpu parameter Zhang Rui
2023-04-19 2:44 ` [PATCH v2 12/15] powercap/intel_rapl: Make cpu optional for rapl_package Zhang Rui
2023-04-19 2:44 ` [PATCH v2 13/15] powercap/intel_rapl: Introduce RAPL I/F type Zhang Rui
2023-04-19 2:44 ` [PATCH v2 14/15] powercap/intel_rapl: Introduce core support for TPMI interface Zhang Rui
2023-04-19 2:44 ` [PATCH v2 15/15] powercap/intel_rapl_tpmi: Introduce RAPL TPMI interface driver Zhang Rui
2023-05-24 16:54 ` [PATCH v2 0/15] powercap/intel_rapl: Introduce RAPL TPMI support Rafael J. Wysocki
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=ae58059aed29f2c9e1e99ad67046881e43942eaf.camel@intel.com \
--to=rui.zhang@intel.com \
--cc=daniel.lezcano@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=srinivas.pandruvada@intel.com \
--cc=ville.syrjala@linux.intel.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