From: Thomas Renninger <trenn@suse.de>
To: Andre Przywara <andre.przywara@amd.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
Andreas Herrmann <andreas.herrmann3@amd.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
cpufreq@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, Matthew Garret <mjg@redhat.com>
Subject: Re: [PATCH 2/8 v2] acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs
Date: Mon, 17 Sep 2012 13:40:23 +0200 [thread overview]
Message-ID: <201209171340.23801.trenn@suse.de> (raw)
In-Reply-To: <5056D420.80808@amd.com>
On Monday, September 17, 2012 09:41:20 AM Andre Przywara wrote:
> On 09/15/2012 01:20 PM, Konrad Rzeszutek Wilk wrote:
> >
...
> This was to overcome some nasty interaction between the Windows
> scheduler and their version of the ondemand governor.
Whoever is/was responsible for this, can you explain him/her that
this was a bad idea and why.
Is this part of a BKDG?
Can you point to a public spec and the exact wording of the
"Windows scheduler workaround" BIOS vendors shall do?
> + pr_info_once(PFX "overriding BIOS provided _PSD data\n");
The message shows up on nearly every platform wether a _PSD
function exists or not. This is wrong.
If it's _PSD info that should get ignored/overwritten, this should
be done where _PSD is obtained:
processor_perflib.c
Are you sure that it will never make sense for AMD to make use of
_PSD tables?
If yes, then always ignoring might be an option.
If not, this might need a more specific check, e.g.:
- Latest Windows version support called via OSI interface?
Latest Windowses should/may not need this anymore?
- Check for Desktop CPUs that are affected by the bad spec?
Hm, as powernow-k8 never made use of _PSD, ignoring it for
now sounds like a good thing to do. Still the ignoring should get
moved to processor_perflib.c, best with a pointer or at least
a comment that _PSD can be dangerous on AMD platforms. At some
day _PSD may make sense for AMD platforms as well?
Thomas
next prev parent reply other threads:[~2012-09-17 11:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-04 8:28 [PATCH 0/8 v2] acpi-cpufreq: Move modern AMD cpufreq support to acpi-cpufreq Andre Przywara
2012-09-04 8:28 ` Andre Przywara
2012-09-04 8:28 ` [PATCH 1/8 v2] acpi-cpufreq: Add support for modern AMD CPUs Andre Przywara
2012-09-04 8:28 ` Andre Przywara
2012-09-04 8:28 ` [PATCH 2/8 v2] acpi-cpufreq: Add quirk to disable _PSD usage on all " Andre Przywara
2012-09-04 8:28 ` Andre Przywara
[not found] ` <CACJDEmrOoZ_azqTrtfoGC-O=H0V=AHy8VExoFYYPhbUUx+7UAg@mail.gmail.com>
2012-09-17 7:41 ` Andre Przywara
2012-09-17 7:41 ` Andre Przywara
2012-09-17 11:40 ` Thomas Renninger [this message]
2012-09-04 8:28 ` [PATCH 3/8 v2] cpufreq: Add warning message to powernow-k8 Andre Przywara
2012-09-04 8:28 ` Andre Przywara
2012-09-04 8:28 ` [PATCH 4/8 v2] powernow-k8: delay info messages until initialization has succeeded Andre Przywara
2012-09-04 8:28 ` Andre Przywara
2012-09-04 8:28 ` [PATCH 5/8 v2] ACPI: Add fixups for AMD P-state figures Andre Przywara
2012-09-04 8:28 ` Andre Przywara
2012-09-04 8:28 ` [PATCH 6/8 v2] acpi-cpufreq: Add support for disabling dynamic overclocking Andre Przywara
2012-09-04 8:28 ` Andre Przywara
2012-09-04 8:28 ` [PATCH 7/8 v2] acpi-cpufreq: Add compatibility for legacy AMD cpb sysfs knob Andre Przywara
2012-09-04 8:28 ` Andre Przywara
2012-09-04 8:28 ` [PATCH 8/8 v2] cpufreq: Remove support for hardware P-state chips from powernow-k8 Andre Przywara
2012-09-04 8:28 ` Andre Przywara
2012-09-05 13:46 ` [PATCH 0/8 v2] acpi-cpufreq: Move modern AMD cpufreq support to acpi-cpufreq Rafael J. Wysocki
2012-09-05 14:25 ` Thomas Renninger
2012-09-05 15:05 ` Andre Przywara
2012-09-05 15:05 ` Andre Przywara
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=201209171340.23801.trenn@suse.de \
--to=trenn@suse.de \
--cc=andre.przywara@amd.com \
--cc=andreas.herrmann3@amd.com \
--cc=cpufreq@vger.kernel.org \
--cc=konrad@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mjg@redhat.com \
--cc=rjw@sisk.pl \
/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.