Re: [PATCH 2/2] CPUFREQ: Mark e_powersaver driver as EXPERIMENTAL and DANGEROUS

[Michael S. Zick]

On Mon June 8 2009, Harald Welte wrote:
> On Mon, Jun 08, 2009 at 01:08:46PM +0100, 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? 
> 
> I strongly assume so, since that is also how the Windows XP driver works (as
> I've been told by Centaur).  So if a vendor decides to not ship with the
> respective BIOS tables, the power management would fail on Windows, too.
> 
> > 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.
> 
> yes, I think that is the case.  I just had a brief look at the driver earlier
> today with one of the key Centaur engineers, and he was very clear on it:  Use 
> ACPI.
> 
> There are also other reasons to use ACPI.  Let's imagine you are having a
> system that uses a certain cpu that might clock up to 1600 MHz.  But the system
> vendor decides to use the CPU passively cooled and thus wants to restrict the
> frequency to 1300MHz.  The standard practise (as recommended by VIA/Centaur BIOS
> writers guide) is to remove the > 1300MHz p-states from the ACPI tables.
> 
> So even if e_powersaver was fixed to not drive the CPU out of spec, it might
> still do that on a particular system/board, where the vendor has decided to 
> limit CPU clock for cooling reasons.
> 

I have yet to run either of my machines using only the internal adaptive controller;
__BUT__
As I read the information, under a limited cooling condition it would be safe and
stable **for the silicon** - -
But for a machine that could come into contact with human skin... that might do harm.
Skin doesn't have the heat tolerance these silicon devices do.  ;)

For an embedded appliance, or something else protected from human contact, perhaps
with no or limited BIOS support - the internal adaptive controller sounds like the
thing to be used.

Since the acpi driver will have to have the code to identify if the internal 
controller is enabled and disable it - I am considering a acpi_cpu=internal
command line flag to let the (soon to be) acpi driver just enable the internal
controller and *not* turn over control to the acpi.
This would be of interest to builders of those embedded appliances and only
would add a few lines of code to an __init section.

Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/