Athlon L110 CPU and powernow-k8

Athlon L110 CPU and powernow-k8

[Josselin Mouette]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

Hi,

I have a Packard-Bell Dot-M/A which is based on an Athlon L110 CPU, and
I noticed that powernow-k8 does not recognize this CPU’s frequencies,
which leads to an insane power consumption, leaving it at 1,2 GHz
permanently.

The Gateway LT31, based on the same CPU, has the same issue, as reported
Krists Krilovs: http://www.pow.za.net/

In both cases, the issue is the same: the DSDT table provided by the
BIOS does not include the P-states. Waiting for a hypothetical BIOS
update that would fix this bug requires some faith that I don’t have. It
is possible to work around this by compiling the kernel with a custom
DSDT table with appropriate P-states patched in, however I consider this
a developer hack. (Krists Krilovs has the patched DSDT for the LT31, and
I can provide the one for the Dot-M/A upon request as well - I used the
same P-states.)

I wonder what is possible to do to support this CPU correctly in the
kernel. The only sane solution I can think of is to hardcode the
P-states for this CPU model in the powernow-k8 driver itself. 

I’m quite a newbie when it comes to ACPI, but I can provide any
information that could help to fix this. If you think it’s feasible by a
random hacker, I can also have a look given the correct pointers.

Cheers,
-- 
 .''`.      Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-    […] I will see what I can do for you.”  -- Jörg Schilling

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: Athlon L110 CPU and powernow-k8

[Josselin Mouette]

[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]

Le lundi 19 avril 2010 à 06:43 -0700, Langsdorf, Mark a écrit : 
> > I wonder what is possible to do to support this CPU correctly in the
> > kernel. The only sane solution I can think of is to hardcode the
> > P-states for this CPU model in the powernow-k8 driver itself. 
> 
> I think that hard-coding P-states into the PowerNow 
> driver is not a mantainable solution.

I agree this is not optimal, but I think there are similar bits in other
drivers. 

> I don't quite understand why the you think that
> a custom DSDT as a BIOS hack, but think that
> adding custom frequencies to the driver itself is
> acceptable.

The first solution implies building a custom kernel before being able to
use the system. The second solution does not. I’m looking for a solution
that works out of the box, and does not require to be able to compile
ASL code nor a kernel.

> The last time this issue came up on cpufreq, Dave
> Jones nixed a general solution to add custom P-states
> through the driver on the grounds that people would
> undervolt their systems, causing a lot of screwy,
> unpredictable behavior.  I agreed with his opinion
> then and I don't see anything in this mesage to
> change that view.

If you want to screw your system, this is already feasible by hacking
the DSDT table itself. Granted, this is not the kind of stuff the
average n00b would do.

Given how Acer doesn’t give a shit about OSes other than XP - not even
other Windows versions - I don’t think they are likely to provide a
fixed BIOS. If they can be convinced, I don’t know how. And if they
can’t - what are we left with?

Cheers,
-- 
 .''`.      Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-    […] I will see what I can do for you.”  -- Jörg Schilling

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Athlon L110 CPU and powernow-k8

[Langsdorf, Mark]

> Date: Fri, 16 Apr 2010 22:40:58 +0200
> From: Josselin Mouette <joss@debian.org>
> To: linux-kernel@vger.kernel.org
> Subject: Athlon L110 CPU and powernow-k8
> X-Mailer: Evolution 2.29.92.1
> Message-ID: <1271450458.6794.33.camel@tomoyo>
> 
> In both cases, the issue is the same: the DSDT table provided by the
> BIOS does not include the P-states. Waiting for a hypothetical BIOS
> update that would fix this bug requires some faith that I 
> don't have. It is possible to work around this by compiling the
> kernel with a custom DSDT table with appropriate P-states patched
> in, however I consider this a developer hack. 
>
> I wonder what is possible to do to support this CPU correctly in the
> kernel. The only sane solution I can think of is to hardcode the
> P-states for this CPU model in the powernow-k8 driver itself. 

I think that hard-coding P-states into the PowerNow 
driver is not a mantainable solution.

I don't quite understand why the you think that
a custom DSDT as a BIOS hack, but think that
adding custom frequencies to the driver itself is
acceptable.

The last time this issue came up on cpufreq, Dave
Jones nixed a general solution to add custom P-states
through the driver on the grounds that people would
undervolt their systems, causing a lot of screwy,
unpredictable behavior.  I agreed with his opinion
then and I don't see anything in this mesage to
change that view.


--Mark Langsdorf
Operating System Research Center
AMD