* voltage tables @ 2007-07-30 23:04 markus reichelt 2007-07-31 2:41 ` Len Brown 0 siblings, 1 reply; 4+ messages in thread From: markus reichelt @ 2007-07-30 23:04 UTC (permalink / raw) To: cpufreq [-- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: voltage tables 2007-07-30 23:04 voltage tables markus reichelt @ 2007-07-31 2:41 ` Len Brown 2007-07-31 19:56 ` Wes Felter 0 siblings, 1 reply; 4+ messages in thread From: Len Brown @ 2007-07-31 2:41 UTC (permalink / raw) To: cpufreq 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: voltage tables 2007-07-31 2:41 ` Len Brown @ 2007-07-31 19:56 ` Wes Felter 2007-10-11 15:43 ` Nebojsa Trpkovic 0 siblings, 1 reply; 4+ messages in thread From: Wes Felter @ 2007-07-31 19:56 UTC (permalink / raw) To: cpufreq 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: voltage tables 2007-07-31 19:56 ` Wes Felter @ 2007-10-11 15:43 ` Nebojsa Trpkovic 0 siblings, 0 replies; 4+ messages in thread From: Nebojsa Trpkovic @ 2007-10-11 15:43 UTC (permalink / raw) To: cpufreq 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... :( ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-10-11 15:43 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-07-30 23:04 voltage tables markus reichelt 2007-07-31 2:41 ` Len Brown 2007-07-31 19:56 ` Wes Felter 2007-10-11 15:43 ` Nebojsa Trpkovic
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.