All of lore.kernel.org
 help / color / mirror / Atom feed
From: Giovanni Gherdovich <ggherdovich@suse.cz>
To: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>
Cc: Len Brown <lenb@kernel.org>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cpufreq: intel_pstate: Force intel_pstate to load when HWP disabled in firmware
Date: Thu, 13 May 2021 12:10:04 +0200	[thread overview]
Message-ID: <bb90b6cac2f4adcc6c80b7fddf54dbe0a6b8ff66.camel@suse.cz> (raw)
In-Reply-To: <3fdc70c267d40561bed10fc722a8223a0b161200.camel@linux.intel.com>

On Thu, 2021-05-13 at 02:24 -0700, Srinivas Pandruvada wrote:
> On Thu, 2021-05-13 at 09:59 +0200, Giovanni Gherdovich wrote:
> > On CPUs succeeding SKX, eg. ICELAKE_X, intel_pstate doesn't load
> > unless
> > CPUID advertises support for the HWP feature. Some OEMs, however, may
> > offer
> > users the possibility to disable HWP from the BIOS config utility by
> > altering the output of CPUID.
>
> Is someone providing a utility? What is the case for broken HWP?

Yes, I know of at least one server manufacturer that ships a BIOS config
utility where the user can disable HWP.

On such server machine, which has an ICELAKE_X CPU, if the user unchecks HWP
via BIOS then intel_pstate will refuse to load saying:

    intel_pstate: CPU model not supported

because ICELAKE_X is not in the list intel_pstate_cpu_ids (defined in
intel_pstate.c) of CPUs that intel_pstate supports when HWP is absent from
CPUID; that list ends at SKYLAKE_X.

An alternative approach to register intel_pstate in the case I'm describing
would be to add ICELAKE_X (and every CPU model after that, forever?) to the
list intel_pstate_cpu_ids.

> It is possible that some user don't want to use HWP, because there
> workloads works better without HWP. But that doesn't mean HWP is
> broken.

That's true, a user may legitimate want to disable HWP, and we have the
intel_pstate=no_hwp option for that. But for that option to work CPUID must
still show that the CPU is HWP-capable; when disablement happens in BIOS, it's
not the case.

The wording "hwp_broken_firmware" deliberately has a negative connotation (the
intended meaning is: "firmware is broken, regarding HWP"), carrying the
not-so-subtle message "OEM folks, please don't do this". My understanding is
that the preferred way to disable HWP is with intel_pstate=no_hwp, the
firmware should stay out of it.

I hope this clarifies the problem (there is an ICELAKE_X somewhere out there
that can't load intel_pstate, which is not nice) and the intention
(discouraging disablement of HWP via firmware).


Giovanni


  reply	other threads:[~2021-05-13 10:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-13  7:59 [PATCH] cpufreq: intel_pstate: Force intel_pstate to load when HWP disabled in firmware Giovanni Gherdovich
2021-05-13  9:24 ` Srinivas Pandruvada
2021-05-13 10:10   ` Giovanni Gherdovich [this message]
2021-05-13 11:03     ` Srinivas Pandruvada
2021-05-13 12:10       ` Giovanni Gherdovich
2021-05-13 13:20       ` [PATCH v2] cpufreq: intel_pstate: Add Icelake servers support in no-HWP mode Giovanni Gherdovich
2021-05-14 15:31         ` Doug Smythies
2021-05-14 20:33           ` Giovanni Gherdovich
2021-05-14 22:12             ` Doug Smythies
2021-09-07 15:45               ` Doug Smythies
2021-09-07 16:01                 ` Srinivas Pandruvada
2021-09-07 20:16                   ` Doug Smythies
2021-09-08  2:04                     ` Srinivas Pandruvada
2021-09-08  3:43                       ` Doug Smythies
2021-09-14 18:41                         ` Doug Smythies
2021-09-15  9:38                           ` Srinivas Pandruvada
2021-05-15  2:58             ` Srinivas Pandruvada
2021-05-17 15:26           ` Rafael J. Wysocki
2021-05-18 11:33             ` Giovanni Gherdovich
2021-05-19  5:37               ` Doug Smythies
2021-05-18 12:34             ` [PATCH v3 1/2] " Giovanni Gherdovich
2021-05-18 12:34               ` [PATCH v3 2/2] cpufreq: intel_pstate: Add Cometlake " Giovanni Gherdovich
2021-05-21 16:49               ` [PATCH v3 1/2] cpufreq: intel_pstate: Add Icelake servers " 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=bb90b6cac2f4adcc6c80b7fddf54dbe0a6b8ff66.camel@suse.cz \
    --to=ggherdovich@suse.cz \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=viresh.kumar@linaro.org \
    /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.