From: "Michael S. Zick" <lkml@morethan.org>
To: Matthew Garrett <mjg@redhat.com>
Cc: Harald Welte <HaraldWelte@viatech.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Duane Griffin <duaneg@dghda.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Dave Jones <davej@redhat.com>
Subject: Re: [PATCH 2/2] CPUFREQ: Mark e_powersaver driver as EXPERIMENTAL and DANGEROUS
Date: Mon, 8 Jun 2009 08:00:07 -0500 [thread overview]
Message-ID: <200906080800.10312.lkml@morethan.org> (raw)
In-Reply-To: <20090608120846.GA13328@srcf.ucam.org>
On Mon June 8 2009, Matthew Garrett wrote:
> On Mon, Jun 08, 2009 at 06:29:36PM +0800, Harald Welte wrote:
> > The e_powersaver driver for VIA's C7 CPU's needs to be marked as
> > DANGEROUS as it configures the CPU to power states that are out
> > of specification.
> >
> > According to Centaur, all systems with C7 and Nano CPU's support
> > the ACPI p-state method. Thus, the acpi-cpufreq driver should
> > be used instead.
>
> Do we know if vendors are actually shipping with the appropriate BIOS
> tables? The number of people using e_powersaver seems to be suspiciously
> large, though perhaps that's just because the help text implied it was
> the right choice for C7.
>
In part, it was because acpi_freq would not load - H.W. in another post
has proposed a fix for that.
My test machine is a "first production" of the Everex Cloudbook - -
About as early as you can get of something in the public hands -
If there is something lacking in a machine's BIOS - it should be
missing in this one - I can test for that condition.
(This one is hitting user code with the silicon still setup
in the state set by "#reset" - untouched by the BIOS.)
Of course, that says nothing about other and/or newer machines -
At the moment I am toying with the idea of a cpu-quirks routine
that could check/correct for an incompletely setup chip.
On the Model-D chips, that could also switch the processor over
to its on-silicon thermal/power/freq adaptive controller.
All of the Netbooks that I know of have shipped with the Model-D
processor (ULV) - so the above cpu-quirks routine would "fix" those.
Machines running other C7 models...
They will just have to trust the BIOS and/or a repaired e_powersaver.
Mike
next prev parent reply other threads:[~2009-06-08 13:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-08 10:29 [PATCH 2/2] CPUFREQ: Mark e_powersaver driver as EXPERIMENTAL and DANGEROUS Harald Welte
2009-06-08 12:08 ` Matthew Garrett
2009-06-08 13:00 ` Michael S. Zick [this message]
2009-06-08 18:13 ` Harald Welte
2009-06-08 18:38 ` Michael S. Zick
2009-06-08 13:06 ` Michael S. Zick
2009-06-08 13:15 ` Michael S. Zick
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=200906080800.10312.lkml@morethan.org \
--to=lkml@morethan.org \
--cc=HaraldWelte@viatech.com \
--cc=davej@redhat.com \
--cc=duaneg@dghda.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg@redhat.com \
--cc=torvalds@linux-foundation.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.