Voltage tweaking in powernow_k8

Hi. What do you think about adding a way to perform voltage corrections into the powernow-k8 module? I've been using a custom (hacked) powernow-k8.c since months, because my motherboard wrongly provides always more voltage than is required by my Turion 64 processor, giving an unwanted overvolting and much more heat.

There is also a patch (unknown author) that provides a new parameter to the module:

http://people.fh-landshut.de/~sprecht/gentoo/powernow-k8-vcore_list-2.6.18.patch

It adds the parameter vcore_list that can be used to override voltages provides by BIOS. It seems to work ok (at least for me). Some people use this patch to perform undervolting, but there are also many broken motherboards giving wrong voltage (mostly for Turions).

For example, this is my particule case:

modprobe powernow_k8 vcore_list=1200,900

powernow-k8: Found 1 AMD Turion(tm) 64 Mobile Technology MT-30 processors (version 2.00.00)
powernow-k8: Requested Voltage for id0 is 1200 mV default voltage is 1300
powernow-k8: Performing required adjustment of 100 mV or 4 25mV steps
powernow-k8: Requested Voltage for id1 is 900 mV default voltage is 1000
powernow-k8: Performing required adjustment of 100 mV or 4 25mV steps
powernow-k8: 0 : fid 0x8 (1600 MHz), vid 0xe
powernow-k8: 1 : fid 0x0 (800 MHz), vid 0x1a

I agree that the patch does look a bit ugly, but I find it easier and more convenient than to hack into the ACPI values.

It is possible to get something like this into the mainline?

AMD policy is that the ACPI values must be used. I can't support a patch that overrides the ACPI values.

I have no objection to it being in the code, but I can't support it.

-Mark Langsdorf
Operating Systems Research Center
AMD

Hi, thanks for replying.

I understand your position about this. Please, correct me if I'm giving a wrong interpretation to your message; in the way I read it, you are unable to support those changes (because of your position at AMD you are required to strictly follow the policy), but you could live with those changes provided that your name is not attached to them...

Admittely, it is not such an elegant solution, but people are indeed doing other hacks anyway, like statically overriding the ACPI table with a hacked DSDT at kernel compile time (distributions like gentoo have HOWTOs for this). I'm not sure if this would be a preferred approach, but it does look even uglier to me. If you have any suggestion or alternative proposal, I would be interested in your opinion.

It may be a good idea to print warnings when the parameter is used, to clearly state the unsupported and potentally dangerous effect of the parameter (though it would not be enough to change your view, I guess...).

Correct.

Also, if I make changes to the driver for future processors, or to fix bugs, I won't make any great effort to fix bugs in this code or to make sure my code supports this code. And I will not do bug fixes on this code.

I still wouldn't be able to support it, no. That's out of my hands.

-Mark Langsdorf
Operating System Research Center
AMD

I'm not enthusiastic about merging this code at all.
The big problem I see is that a lot of the reasons people want to do this is "The bios say xyz, but the datasheet says it can do xyz+-1" In many cases, the bios *really* does know best. Board layout differences, differences in quality of VRMs etc between vendors may mean that yes, you can get away with tweaking things on one board, but someone else with the "same" board may notice stability problems.
The kind of bugs that manifest with incorrectly configured frequency scaling are nigh on impossible to track down, and as someone who sits on the recieving end of user bugreports, I don't want to have to deal with that, and I can't imagine other distributors would feel differently.

Dave

http://www.codemonkey.org.uk

Yes, I must admit so. It seems that many people just want to do heavy overclock. And it can be difficult to detect a broken BIOS... though I've discovered an interesting method: when the customer support tells you to install crystalcpuid (a Windows utility) and then they reply that Linux is not a supported OS, then there are high chance that their BIOS is broken :-)

There seems to be some comments on certain laptops giving overpower to Turions, but I can't confirm how many of them are real BIOS bugs. I will probably continue with this as an unofficial patch. Thank you anyway for looking into this.

What I wouldn't object to however, if we do find tables that are *clearly* broken, and we can't convince the manufacturer to do a fixed BIOS release, adding override tables in the driver matching on DMI of the broken systems would be fine by me.

But as you say, knowing whether the BIOS is broken, or if the manufacturer had good reason to configure the tables that way is very hard to determine.

Dave

http://www.codemonkey.org.uk