All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Doug Smythies <dsmythies@telus.net>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Len Brown <len.brown@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>
Subject: Re: [PATCH] cpufreq: intel_pstate: Override parameters if HWP forced by BIOS
Date: Thu, 9 Sep 2021 19:22:19 +0200	[thread overview]
Message-ID: <CAJZ5v0j1JjLr0co06yJCCNV2p06e91Zh7tkMXoGTE=waB5Xo1Q@mail.gmail.com> (raw)
In-Reply-To: <CAJZ5v0hO7SajJ5HFVDcma6nOfzy-289MdwUSiJbY8Hm3mxvXnQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3686 bytes --]

On Thu, Sep 9, 2021 at 6:12 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Thu, Sep 9, 2021 at 3:20 PM Doug Smythies <dsmythies@telus.net> wrote:
> >
> > On Thu, Sep 9, 2021 at 4:18 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > >
> > > On Thu, Sep 9, 2021 at 8:52 AM Srinivas Pandruvada
> > > <srinivas.pandruvada@linux.intel.com> wrote:
> > > >
> > > > On Wed, 2021-09-08 at 20:48 -0700, Doug Smythies wrote:
> > > > > If HWP has been already been enabled by BIOS, it may be
> > > > > necessary to override some kernel command line parameters.
> > > > > Once it has been enabled it requires a reset to be disabled.
> > > > >
> > > > > Signed-off-by: Doug Smythies <dsmythies@telus.net>
> > > > > ---
> > > > >  drivers/cpufreq/intel_pstate.c | 22 ++++++++++++++++------
> > > > >  1 file changed, 16 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/drivers/cpufreq/intel_pstate.c
> > > > > b/drivers/cpufreq/intel_pstate.c
> > > > > index bb4549959b11..073bae5d4498 100644
> > > > > --- a/drivers/cpufreq/intel_pstate.c
> > > > > +++ b/drivers/cpufreq/intel_pstate.c
> > > > > @@ -3267,7 +3267,7 @@ static int __init intel_pstate_init(void)
> > > > >                  */
> > > > >                 if ((!no_hwp && boot_cpu_has(X86_FEATURE_HWP_EPP)) ||
> > > > >                     intel_pstate_hwp_is_enabled()) {
> > > > > -                       hwp_active++;
> > > > > +                       hwp_active = 1;
> > > > Why this change?
> > >
> > > I think hwp_active can be changed to bool and then it would make sense
> > > to update this line.
> > >
> > > > >                         hwp_mode_bdw = id->driver_data;
> > > > >                         intel_pstate.attr = hwp_cpufreq_attrs;
> > > > >                         intel_cpufreq.attr = hwp_cpufreq_attrs;
> > > > > @@ -3347,17 +3347,27 @@ device_initcall(intel_pstate_init);
> > > > >
> > > > >  static int __init intel_pstate_setup(char *str)
> > > > >  {
> > > > > +       /*
> > > > > +        * If BIOS is forcing HWP, then parameter
> > > > > +        * overrides might be needed. Only print
> > > > > +        * the message once, and regardless of
> > > > > +        * any overrides.
> > > > > +        */
> > > > > +       if(!hwp_active
> > > > This part of code is from early_param, Is it possible that
> > > > hwp_active is not 0?
> > >
> > > Well, it wouldn't matter even if it were nonzero.  This check is just
> > > pointless anyway.
> > >
> > > > > && boot_cpu_has(X86_FEATURE_HWP))
> > > > > +               if(intel_pstate_hwp_is_enabled()){
> > >
> > > This should be
> > >
> > > if (boot_cpu_has(X86_FEATURE_HWP) && intel_pstate_hwp_is_enabled()) {
> >
> > Disagree.
> > This routine gets executed once per intel_pstate related grub command
> > line entry. The purpose of the "if(!hwp_active" part is to prevent the
> > printing of the message to the logs multiple times.
>
> Ah OK.  Fair enough.
>
> You can do all of the checks in one conditional, though.  They will be
> processed left-to-right anyway.
>
> But then it would be good to avoid calling
> intel_pstate_hwp_is_enabled() multiple times if it returns false.
>
> And having said all that I'm not sure why you are trying to make
> no_hwp depend on !hwp_active?  I will not be taken into account anyway
> if intel_pstate_hwp_is_enabled() returns 'true'?
>
> So if no_hwp is covered regardless, you may move the
> intel_pstate_hwp_is_enabled() inside the no_load conditional.
>
> Alternatively, and I would do that, intel_pstate_hwp_is_enabled()
> could be evaluated earlier in intel_pstate_init() and if it returned
> 'true', both no_load and no_hwp would be disregarded.

Something like the attached, for the record.

[-- Attachment #2: intel_pstate-arguments.patch --]
[-- Type: text/x-patch, Size: 1463 bytes --]

---
 drivers/cpufreq/intel_pstate.c |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -3205,11 +3205,15 @@ static int __init intel_pstate_init(void
 	if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
 		return -ENODEV;
 
-	if (no_load)
-		return -ENODEV;
-
 	id = x86_match_cpu(hwp_support_ids);
 	if (id) {
+		bool hwp_forced = intel_pstate_hwp_is_enabled();
+
+		if (hwp_forced)
+			pr_info("HWP enabled by BIOS\n");
+		else if (no_load)
+			return -ENODEV;
+
 		copy_cpu_funcs(&core_funcs);
 		/*
 		 * Avoid enabling HWP for processors without EPP support,
@@ -3219,8 +3223,7 @@ static int __init intel_pstate_init(void
 		 * If HWP is enabled already, though, there is no choice but to
 		 * deal with it.
 		 */
-		if ((!no_hwp && boot_cpu_has(X86_FEATURE_HWP_EPP)) ||
-		    intel_pstate_hwp_is_enabled()) {
+		if ((!no_hwp && boot_cpu_has(X86_FEATURE_HWP_EPP)) || hwp_forced) {
 			hwp_active++;
 			hwp_mode_bdw = id->driver_data;
 			intel_pstate.attr = hwp_cpufreq_attrs;
@@ -3236,6 +3239,9 @@ static int __init intel_pstate_init(void
 			goto hwp_cpu_matched;
 		}
 	} else {
+		if (no_load)
+			return -ENODEV;
+
 		id = x86_match_cpu(intel_pstate_cpu_ids);
 		if (!id) {
 			pr_info("CPU model not supported\n");

  reply	other threads:[~2021-09-09 17:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09  3:48 [PATCH] cpufreq: intel_pstate: Override parameters if HWP forced by BIOS Doug Smythies
2021-09-09  6:33 ` Srinivas Pandruvada
2021-09-09 11:18   ` Rafael J. Wysocki
2021-09-09 13:20     ` Doug Smythies
2021-09-09 16:12       ` Rafael J. Wysocki
2021-09-09 17:22         ` Rafael J. Wysocki [this message]
2021-09-10  3:14           ` Doug Smythies
2021-09-10 11:18             ` Rafael J. Wysocki
2021-09-10 15:34               ` Doug Smythies
2021-09-10 15:45                 ` Rafael J. Wysocki
2021-09-09 13:30   ` Doug Smythies
2021-09-09 14:52     ` Srinivas Pandruvada
2021-09-10  4:11       ` Doug Smythies

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='CAJZ5v0j1JjLr0co06yJCCNV2p06e91Zh7tkMXoGTE=waB5Xo1Q@mail.gmail.com' \
    --to=rafael@kernel.org \
    --cc=dsmythies@telus.net \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=srinivas.pandruvada@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.