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: Fri, 10 Sep 2021 17:45:38 +0200	[thread overview]
Message-ID: <CAJZ5v0jwLrnz+93yjP0s8ctbka95_tuLZocuFP1g5ryef5QRLQ@mail.gmail.com> (raw)
In-Reply-To: <CAAYoRsVOh+TxZK8BWfM=u6YqEhSY-Pgpt+aavZGBLogVTEocKw@mail.gmail.com>

On Fri, Sep 10, 2021 at 5:35 PM Doug Smythies <dsmythies@telus.net> wrote:
>
> On Fri, Sep 10, 2021 at 4:18 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > On Fri, Sep 10, 2021 at 5:14 AM Doug Smythies <dsmythies@telus.net> wrote:
> > > On Thu, Sep 9, 2021 at 10:22 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > 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.
> > >
> > > O.K. and Thanks.
> > > I was trying to avoid this line getting into the log:
> > >
> > > [    0.000000] intel_pstate: HWP disabled
> > >
> > > only to overridden later by, now, these lines:
> > >
> > > [    0.373742] intel_pstate: HWP enabled by BIOS
> > > [    0.374177] intel_pstate: Intel P-state driver initializing
> > > [    0.375097] intel_pstate: HWP enabled
> > >
> > > Let me see if I can go with your suggestion and get to
> > > what I had hoped to get in the logs.
> >
> > It would be sufficient to put the "disabled" printk() after the
> > "no_hwp" if () statement in intel_pstate_init().  See attached.
>
> Agreed, thanks. Yes, I was thinking similar.
>
> > BTW, I've changed the message to "HWP not enabled", because that's
> > what really happens to be precise.
>
> Agreed. Good idea.
>
> Give me a fews days to create and test a formal patch.

OK

> I currently have limited access to a computer that doesn't force
> HWP via BIOS.

  reply	other threads:[~2021-09-10 15:45 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
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 [this message]
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=CAJZ5v0jwLrnz+93yjP0s8ctbka95_tuLZocuFP1g5ryef5QRLQ@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.