voltage tables

voltage tables

[markus reichelt]

[-- Attachment #1.1: Type: text/plain, Size: 778 bytes --]

Hi,

just a thought.... with more and more people wondering why cpufreq
doesn't work on their over/underclocked systems, what about offering
the possibility to use static (and thus easily tweakable) voltage
tables instead of/parallel to the ACPI-approach? 

I don't know about the effort this would take to implement / the
stress it would put on maintenance, but it would be my choice. 

I'm thinking along the lines of using the ACPI values by default but
providing the means to use custom tables instead, for "experts".

Given the slim chances (yes, I'm brainstorming) of success, what
about documentation -- if one would like to look into the matter and
try to implement the above? Anything apart from reading the source
code?

-- 
left blank, right bald

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq

Re: voltage tables

[Len Brown]

On Monday 30 July 2007 19:04, markus reichelt wrote:
> Hi,
> 
> just a thought.... with more and more people wondering why cpufreq
> doesn't work on their over/underclocked systems, what about offering
> the possibility to use static (and thus easily tweakable) voltage
> tables instead of/parallel to the ACPI-approach? 
> 
> I don't know about the effort this would take to implement / the
> stress it would put on maintenance, but it would be my choice. 
> 
> I'm thinking along the lines of using the ACPI values by default but
> providing the means to use custom tables instead, for "experts".
> 
> Given the slim chances (yes, I'm brainstorming) of success, what
> about documentation -- if one would like to look into the matter and
> try to implement the above? Anything apart from reading the source
> code?

Trying to speak for Intel parts only here, since I don't know
what AMD does...

In the past, there were model specific encoding for the bit pattern
that got written to PERF_CTL.  That is how speedstep-centrino was born.
But these tables were a PITA to maintain, since they were not
necessarily documented, and every stepping might have different encodings.

Intel then documented the model-specific _PDC bits, which allowed
open source to do this the way Windows does -- by asking ACPI.
Thus acpi-cpufreq became the driver of choice, and speedstep-centrino
was deprecated.

Going forward, I believe that the hardware guys have no plans to
maintain any sort of reasonable compatibility or even straightforward
decoding of the bit pattern that gets written to PERF_CTL --
so the reason that speedstep-centrino and its hard-coded tables
became deprecated will be even more true in the future.

Further, I've not played with this, but my understanding is that
on the Extreme parts, the way to over-clock them is to have
a really good cooling solution, and then just enter the BIOS SETUP
and select a higher maximum bus/core ratio.  In theory, this should
be reflected in the ACPI BIOS P-state tables, the tables should
have accurate encodings for the necessary voltage, and assuming
the cooling works, everybody is happy.  Maybe somebody on the
list can comment on if this last part works for them.  I don't
know b/c I never over-clock the parts -- I just use next year's
parts:-)

cheers,
-Len

Re: voltage tables

[Wes Felter]

Len Brown wrote:
> On Monday 30 July 2007 19:04, markus reichelt wrote:
>> Hi,
>>
>> just a thought.... with more and more people wondering why cpufreq
>> doesn't work on their over/underclocked systems, what about offering
>> the possibility to use static (and thus easily tweakable) voltage
>> tables instead of/parallel to the ACPI-approach? 

[snip]

> Going forward, I believe that the hardware guys have no plans to
> maintain any sort of reasonable compatibility or even straightforward
> decoding of the bit pattern that gets written to PERF_CTL --
> so the reason that speedstep-centrino and its hard-coded tables
> became deprecated will be even more true in the future.

User-provided tables != hard-coded tables. What if acpi-cpufreq dumped 
the ACPI table in some semi-human-readable format and then allowed the 
user to tweak it (by guessing, since the hardware is undocumented) and 
then push the tweaked table back into the driver at runtime? The driver 
would still not contain any tables and thus the old speedstep-centrino 
maintenance problem would not exist.

There is a patch for speedstep-centrino that adds an op_points_table 
file in sysfs; it could be ported to acpi-cpufreq.

http://gentoo-wiki.com/HOWTO_Undervolt_a_Pentium_M_CPU#Getting_the_current_voltage_settings

> Further, I've not played with this, but my understanding is that
> on the Extreme parts, the way to over-clock them is to have

Most overclockers buy cheap non-extreme parts and set the FSB frequency 
out of spec; that's why the ACPI tables are wrong.

Wes Felter - wesley@felter.org

Re: voltage tables

[Nebojsa Trpkovic]

Wes Felter wrote:
> Len Brown wrote:
>> On Monday 30 July 2007 19:04, markus reichelt wrote:
>>> Hi,
>>>
>>> just a thought.... with more and more people wondering why cpufreq
>>> doesn't work on their over/underclocked systems, what about offering
>>> the possibility to use static (and thus easily tweakable) voltage
>>> tables instead of/parallel to the ACPI-approach? 
> 
> [snip]
> 
>> Going forward, I believe that the hardware guys have no plans to
>> maintain any sort of reasonable compatibility or even straightforward
>> decoding of the bit pattern that gets written to PERF_CTL --
>> so the reason that speedstep-centrino and its hard-coded tables
>> became deprecated will be even more true in the future.
> 
> User-provided tables != hard-coded tables. What if acpi-cpufreq dumped
> the ACPI table in some semi-human-readable format and then allowed the
> user to tweak it (by guessing, since the hardware is undocumented) and
> then push the tweaked table back into the driver at runtime? The driver
> would still not contain any tables and thus the old speedstep-centrino
> maintenance problem would not exist.
> 
> There is a patch for speedstep-centrino that adds an op_points_table
> file in sysfs; it could be ported to acpi-cpufreq.
> 
> http://gentoo-wiki.com/HOWTO_Undervolt_a_Pentium_M_CPU#Getting_the_current_voltage_settings
> 

any info about eventual acpi-cpufreq port?

I've found this:
http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
but was unable to find any FID/VID table in DSDT... :(