* speedstep-centrino on dothan
@ 2005-07-06 9:22 st3
2005-07-06 14:06 ` Dominik Brodowski
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: st3 @ 2005-07-06 9:22 UTC (permalink / raw)
To: linux-kernel
Currently, the speedstep-centrino support has built-in frequency/voltage
pairs only for Banias CPUs. For Dothan CPUs, these tables are read from
BIOS ACPI.
But ACPI encoding may not be available or not reliable, so why shouldn't we
provide built-in tables for Dothan CPUs, too? Intel has released this
datasheet:
http://www.intel.com/design/mobile/datashts/302189.htm
with frequency/voltage pairs for every version of Dothan CPUs.
Moreover, I checked on Pentium M 725 and Pentium M 715 that the lowest
frequency at which the CPU can be set safely is not the 600MHz given in
datasheets, but 400MHz instead, with VID#A, VID#B, VID#C and VID#D (see
datasheet for more details) set to 0.908V.
I can provide a patch, let me know.
--
ciao
st3
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: speedstep-centrino on dothan 2005-07-06 9:22 speedstep-centrino on dothan st3 @ 2005-07-06 14:06 ` Dominik Brodowski 2005-07-06 19:45 ` st3 2005-07-06 16:30 ` Pedro Ramalhais 2005-07-06 19:58 ` Bill Davidsen 2 siblings, 1 reply; 22+ messages in thread From: Dominik Brodowski @ 2005-07-06 14:06 UTC (permalink / raw) To: st3; +Cc: linux-kernel Hi, On Wed, Jul 06, 2005 at 11:22:02AM +0200, st3@riseup.net wrote: > Currently, the speedstep-centrino support has built-in frequency/voltage > pairs only for Banias CPUs. For Dothan CPUs, these tables are read from > BIOS ACPI. > > But ACPI encoding may not be available or not reliable, so why shouldn't we > provide built-in tables for Dothan CPUs, too? Intel has released this > datasheet: > > http://www.intel.com/design/mobile/datashts/302189.htm > > with frequency/voltage pairs for every version of Dothan CPUs. However, it is not known which one of VID#A, VID#B, VID#C or VID#D is to be used on a specific system. Dominik ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan 2005-07-06 14:06 ` Dominik Brodowski @ 2005-07-06 19:45 ` st3 0 siblings, 0 replies; 22+ messages in thread From: st3 @ 2005-07-06 19:45 UTC (permalink / raw) To: linux-kernel On Wed, 6 Jul 2005 16:06:53 +0200 Dominik Brodowski <linux@dominikbrodowski.net> wrote: > Hi, > > On Wed, Jul 06, 2005 at 11:22:02AM +0200, st3@riseup.net wrote: > > Currently, the speedstep-centrino support has built-in frequency/voltage > > pairs only for Banias CPUs. For Dothan CPUs, these tables are read from > > BIOS ACPI. > > > > But ACPI encoding may not be available or not reliable, so why shouldn't we > > provide built-in tables for Dothan CPUs, too? Intel has released this > > datasheet: > > > > http://www.intel.com/design/mobile/datashts/302189.htm > > > > with frequency/voltage pairs for every version of Dothan CPUs. > > However, it is not known which one of VID#A, VID#B, VID#C or VID#D is to be > used on a specific system. Ok, so we could patch it in order to use acpi if available, and else use, say, VID#C (every different VID is suitable for any system I tested so far; moreover, voltages are very similar). The safe choice is VID#A, the best one is VID#D =) Another option: add a module_param for that, and make it configurable in Kconfig whether to use ACPI tables or select between different VID profiles through the parameter (not just for Banias, as of current version), defaulting to VID#A. anyway I will: 1) look for more specifications from Intel; 2) check VID setup on different systems (who can say that OEMs really use them differently?). Then, i found out that running CPU (in my case, Dothan 715) at 400MHz saves lot of battery, really (on a Toshiba Satellite A50 with standard battery, idling, 6h20 vs. 5h at 600MHz): it would be very nice to add support for these frequencies to speedstep-centrino. -- ciao st3 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan 2005-07-06 9:22 speedstep-centrino on dothan st3 2005-07-06 14:06 ` Dominik Brodowski @ 2005-07-06 16:30 ` Pedro Ramalhais 2005-07-06 19:58 ` Bill Davidsen 2 siblings, 0 replies; 22+ messages in thread From: Pedro Ramalhais @ 2005-07-06 16:30 UTC (permalink / raw) To: linux-kernel st3@riseup.net wrote: > Currently, the speedstep-centrino support has built-in frequency/voltage > pairs only for Banias CPUs. For Dothan CPUs, these tables are read from > BIOS ACPI. > > But ACPI encoding may not be available or not reliable, so why shouldn't we > provide built-in tables for Dothan CPUs, too? Intel has released this > datasheet: > > http://www.intel.com/design/mobile/datashts/302189.htm > > with frequency/voltage pairs for every version of Dothan CPUs. > > Moreover, I checked on Pentium M 725 and Pentium M 715 that the lowest > frequency at which the CPU can be set safely is not the 600MHz given in > datasheets, but 400MHz instead, with VID#A, VID#B, VID#C and VID#D (see > datasheet for more details) set to 0.908V. > > I can provide a patch, let me know. > > > -- > ciao > st3 > I looked into it 2 weeks ago, and i couldn't find a complete voltage table for the Dothan C1 stepping (which my laptop has). I only found a table with (IIRC) the max and min voltages for the max and min frequencies. I also didn't understand the meaning of the different VID#{A,B,C,D,E} values. Are these voltages related to the quality of the power supply, or the quality of the processor? How do we know which one to choose? Regards, -- Pedro Ramalhais ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan 2005-07-06 9:22 speedstep-centrino on dothan st3 2005-07-06 14:06 ` Dominik Brodowski 2005-07-06 16:30 ` Pedro Ramalhais @ 2005-07-06 19:58 ` Bill Davidsen 2005-07-06 21:11 ` Dave Jones 2005-07-07 21:59 ` st3 2 siblings, 2 replies; 22+ messages in thread From: Bill Davidsen @ 2005-07-06 19:58 UTC (permalink / raw) To: linux-kernel st3@riseup.net wrote: > Currently, the speedstep-centrino support has built-in frequency/voltage > pairs only for Banias CPUs. For Dothan CPUs, these tables are read from > BIOS ACPI. > > But ACPI encoding may not be available or not reliable, so why shouldn't we > provide built-in tables for Dothan CPUs, too? Intel has released this > datasheet: > > http://www.intel.com/design/mobile/datashts/302189.htm > > with frequency/voltage pairs for every version of Dothan CPUs. > > Moreover, I checked on Pentium M 725 and Pentium M 715 that the lowest > frequency at which the CPU can be set safely is not the 600MHz given in > datasheets, but 400MHz instead, with VID#A, VID#B, VID#C and VID#D (see > datasheet for more details) set to 0.908V. > > I can provide a patch, let me know. Slower is better, and not depending on ACPI for anything which can be gotten elsewhere is a good thing. Sounds like a good idea to me. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan 2005-07-06 19:58 ` Bill Davidsen @ 2005-07-06 21:11 ` Dave Jones 2005-07-06 21:55 ` st3 2005-07-07 21:59 ` st3 1 sibling, 1 reply; 22+ messages in thread From: Dave Jones @ 2005-07-06 21:11 UTC (permalink / raw) To: Bill Davidsen; +Cc: linux-kernel On Wed, Jul 06, 2005 at 03:58:53PM -0400, Bill Davidsen wrote: > st3@riseup.net wrote: > >Currently, the speedstep-centrino support has built-in frequency/voltage > >pairs only for Banias CPUs. For Dothan CPUs, these tables are read from > >BIOS ACPI. > > > >But ACPI encoding may not be available or not reliable, so why shouldn't we > >provide built-in tables for Dothan CPUs, too? Intel has released this > >datasheet: > > > >http://www.intel.com/design/mobile/datashts/302189.htm > > > >with frequency/voltage pairs for every version of Dothan CPUs. > > > >Moreover, I checked on Pentium M 725 and Pentium M 715 that the lowest > >frequency at which the CPU can be set safely is not the 600MHz given in > >datasheets, but 400MHz instead, with VID#A, VID#B, VID#C and VID#D (see > >datasheet for more details) set to 0.908V. > > > >I can provide a patch, let me know. > > Slower is better, and not depending on ACPI for anything which can be > gotten elsewhere is a good thing. Sounds like a good idea to me. This can't be done safely through any other means than ACPI right now. It needs to know intimate things about which VID line is wired to what, which is board specific. Dave ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan 2005-07-06 21:11 ` Dave Jones @ 2005-07-06 21:55 ` st3 2005-07-07 20:00 ` enhanced intel speedstep feature was " st3 0 siblings, 1 reply; 22+ messages in thread From: st3 @ 2005-07-06 21:55 UTC (permalink / raw) To: Dave Jones; +Cc: linux-kernel On Wed, 6 Jul 2005 17:11:59 -0400 Dave Jones <davej@redhat.com> wrote: > This can't be done safely through any other means than ACPI right now. > It needs to know intimate things about which VID line is wired to what, > which is board specific. I don't think it's related to 'which VID line is wired to what': this isn't board specific, as it's given in datasheets provided by Intel (6 pins, etc). The only issue is that there are four different versions of Dothan CPUs for A1, A2, B0, B1, C0 steppings. There is only one version for C1 stepping. For those different versions, Intel provides different typical voltage ranges. For example, in read a post by Michael Clark in which he claims his IBM T42 has VID#A version of Dothan 745. I read ACPI tables on my laptop (Toshiba Satellite A50, with Dothan 715) and I saw I got a VID#A version of Dothan 715 (is there somebody around with some other versions?). Additionally, for lower frequencies VID#{A,B,C,D,E} voltages are the same. So I ask: wouldn't it be good to find a way to add some lower frequencies, while still reading ACPI tables for the other ones? Or to make profiles configurable as a module parameter (as boot)? My problem isn't really ACPI, but rather that one can't use lower and very useful frequencies. Moreover, we could provide built-in tables for C1 stepping. -- ciao st3 ^ permalink raw reply [flat|nested] 22+ messages in thread
* enhanced intel speedstep feature was Re: speedstep-centrino on dothan 2005-07-06 21:55 ` st3 @ 2005-07-07 20:00 ` st3 2005-07-07 20:06 ` Dave Jones 0 siblings, 1 reply; 22+ messages in thread From: st3 @ 2005-07-07 20:00 UTC (permalink / raw) To: linux-kernel, cpufreq Pedro Ramalhais found another interesting thing in: ftp://download.intel.com/design/Pentium4/manuals/25366816.pdf that's the IA32_CLOCK_MODULATION (still called MSR_IA32_THERM_CONTROL in include/asm-i386/msr.h, and I think this would need a fix) register, that let set a reduced CPU duty cycle. So just today I coded something to use it. Just add to speedstep-centrino.c: [yes I know, this isn't the Right Coding Style, but it's just to give an idea of the whole thing] static int sccm_level = 0; module_param(sccm_level, uint, 0644); MODULE_PARM_DESC(sccm_level, "Software Controlled Clock Modulation level: 0 for disabling, 7 for 12.5\% duty cycle"); in the first part, right after the third #define and this function after centrino_target(): static int centrino_target_sccm () { unsigned int msr, h; rdmsr(MSR_IA32_THERM_CONTROL, msr, h); msr &= (0<<1); msr &= (0<<2); msr &= (0<<3); switch (sccm_level) { case 0: msr &= (0<<4); case 1: msr |= (1<<4); msr |= (1<<3); msr |= (1<<2); msr |= (1<<1); break; case 2: msr |= (i<<4); msr |= (1<<3); msr |= (1<<2); break; case 3: msr |= (1<<4); msr |= (1<<3); msr |= (1<<1); break; case 4: msr |= (1<<4); msr |= (1<<3); break; case 5: msr |= (1<<4); msr |= (1<<2); msr |= (1<<1); break; case 6: msr |= (1<<4); msr |= (1<<2); break; case 7: msr |= (1<<4); msr |= (1<<1); break; } wrmsr (MSR_IA32_THERM_CONTROL, msr, h); } Then you'll just have to insmod speedstep-centrino.ko sccm_level=x, where x can be 0 to disable software cycle control modulation, 1 to enable a reduced duty cycle of 87.5%, 7 to enable a duty cycle of 12.5% and so on. Enabling, say, a duty cycle of 12.5% means that the CPU chip will be driven by clock just one time every eight, thus reducing power consumption and temperature (and it speeds down dramatically the CPU, too =). I tested it so far on my Pentium M Dothan 715 and on a Dothan 725. What do you think, could this be useful? I could provide a patch or a stand-alone module. Should I write an interface to sysfs? -- ciao st3 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan 2005-07-07 20:00 ` enhanced intel speedstep feature was " st3 @ 2005-07-07 20:06 ` Dave Jones 2005-07-07 20:22 ` st3 0 siblings, 1 reply; 22+ messages in thread From: Dave Jones @ 2005-07-07 20:06 UTC (permalink / raw) To: st3; +Cc: linux-kernel, cpufreq On Thu, Jul 07, 2005 at 10:00:27PM +0200, st3@riseup.net wrote: > Enabling, say, a duty cycle of 12.5% means that the CPU chip will be driven > by clock just one time every eight, thus reducing power consumption and > temperature (and it speeds down dramatically the CPU, too =). > > I tested it so far on my Pentium M Dothan 715 and on a Dothan 725. > > What do you think, could this be useful? I could provide a patch or a > stand-alone module. Should I write an interface to sysfs? You just reinvented the p4-clockmod driver :-) This hasn't been seen to save any power whatsoever that I've seen. I've heard a few reports that it reduces heat for a few folks, but betting on it increasing your battery life is probably a push. Dave ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan 2005-07-07 20:06 ` Dave Jones @ 2005-07-07 20:22 ` st3 2005-07-07 20:40 ` Dave Jones ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: st3 @ 2005-07-07 20:22 UTC (permalink / raw) To: Dave Jones; +Cc: linux-kernel, cpufreq On Thu, 7 Jul 2005 16:06:48 -0400 Dave Jones <davej@redhat.com> wrote: > On Thu, Jul 07, 2005 at 10:00:27PM +0200, st3@riseup.net wrote: > > Enabling, say, a duty cycle of 12.5% means that the CPU chip will be driven > > by clock just one time every eight, thus reducing power consumption and > > temperature (and it speeds down dramatically the CPU, too =). > > > > I tested it so far on my Pentium M Dothan 715 and on a Dothan 725. > > > > What do you think, could this be useful? I could provide a patch or a > > stand-alone module. Should I write an interface to sysfs? > > You just reinvented the p4-clockmod driver :-) Oops. =) > This hasn't been seen to save any power whatsoever that I've seen. It drops down power rating by 1500-1800mW on my Toshiba Satellite A50 while idling at 400MHz. > I've heard a few reports that it reduces heat for a few folks, but > betting on it increasing your battery life is probably a push. Just a latest question: can be p4-clockmod used together with speedstep-centrino? If not, would it make any sense to patch speedstep-centrino to use this feature too? -- ciao st3 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan 2005-07-07 20:22 ` st3 @ 2005-07-07 20:40 ` Dave Jones 2005-07-07 20:51 ` Joseph Pingenot 2005-07-07 21:10 ` Dominik Brodowski 2 siblings, 0 replies; 22+ messages in thread From: Dave Jones @ 2005-07-07 20:40 UTC (permalink / raw) To: st3; +Cc: linux-kernel, cpufreq On Thu, Jul 07, 2005 at 10:22:25PM +0200, st3@riseup.net wrote: > > This hasn't been seen to save any power whatsoever that I've seen. > > It drops down power rating by 1500-1800mW on my Toshiba Satellite A50 > while idling at 400MHz. > > > I've heard a few reports that it reduces heat for a few folks, but > > betting on it increasing your battery life is probably a push. > > Just a latest question: can be p4-clockmod used together with > speedstep-centrino? If not, would it make any sense to patch > speedstep-centrino to use this feature too? There was some discussion on cpufreq list long ago to make cpufreq drivers stackable, but it's never been a high enough priority for anyone to actually do the work. Dave ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan 2005-07-07 20:22 ` st3 2005-07-07 20:40 ` Dave Jones @ 2005-07-07 20:51 ` Joseph Pingenot 2005-07-07 21:08 ` Dominik Brodowski 2005-07-07 21:10 ` Dominik Brodowski 2 siblings, 1 reply; 22+ messages in thread From: Joseph Pingenot @ 2005-07-07 20:51 UTC (permalink / raw) To: st3; +Cc: Dave Jones, linux-kernel, cpufreq >Just a latest question: can be p4-clockmod used together with >speedstep-centrino? If not, would it make any sense to patch >speedstep-centrino to use this feature too? I'm a little confused. How is this different from the ACPI CPU throttling states (/proc/acpi/processor/CPUn/limit to set, throttling to see all T-states available)? On my 1.5-year-old Pentium-M, frequency scaling and T-states are different beasties, and act entirely differently. I'm currently in the process of rewriting my governor's brain to deal with the two more intelligently. -Joseph -- Joseph===============================================trelane@digitasaru.net Graduate Student in Physics, Freelance Free Software Developer ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan 2005-07-07 20:51 ` Joseph Pingenot @ 2005-07-07 21:08 ` Dominik Brodowski 2005-07-07 21:34 ` Joseph Pingenot 0 siblings, 1 reply; 22+ messages in thread From: Dominik Brodowski @ 2005-07-07 21:08 UTC (permalink / raw) To: st3, Dave Jones, linux-kernel, cpufreq On Thu, Jul 07, 2005 at 03:51:17PM -0500, Joseph Pingenot wrote: > >Just a latest question: can be p4-clockmod used together with > >speedstep-centrino? If not, would it make any sense to patch > >speedstep-centrino to use this feature too? > > I'm a little confused. How is this different from the ACPI CPU throttling > states (/proc/acpi/processor/CPUn/limit to set, throttling to see all > T-states available)? T-states _tend_ to be utilized using chipset logic, while p4-clockmod is done in-CPU. > On my 1.5-year-old Pentium-M, frequency scaling and T-states are different > beasties, and act entirely differently. I'm currently in the process of > rewriting my governor's brain to deal with the two more intelligently. In your case, I would care about throttling. In very most cases it actually increases energy consumption, as the state being entered is technically the same to ACPI C2 (IIRC), so it is only "forced" idling and only useful if "forced" idling is needed to not need active cooling. Dominik ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan 2005-07-07 21:08 ` Dominik Brodowski @ 2005-07-07 21:34 ` Joseph Pingenot 2005-07-07 21:51 ` Dominik Brodowski 0 siblings, 1 reply; 22+ messages in thread From: Joseph Pingenot @ 2005-07-07 21:34 UTC (permalink / raw) To: st3, Dave Jones, linux-kernel, cpufreq >From Dominik Brodowski on Thursday, 07 July, 2005: >On Thu, Jul 07, 2005 at 03:51:17PM -0500, Joseph Pingenot wrote: >> >Just a latest question: can be p4-clockmod used together with >> >speedstep-centrino? If not, would it make any sense to patch >> >speedstep-centrino to use this feature too? >> I'm a little confused. How is this different from the ACPI CPU throttling >> states (/proc/acpi/processor/CPUn/limit to set, throttling to see all >> T-states available)? >T-states _tend_ to be utilized using chipset logic, while p4-clockmod is >done in-CPU. >> On my 1.5-year-old Pentium-M, frequency scaling and T-states are different >> beasties, and act entirely differently. I'm currently in the process of >> rewriting my governor's brain to deal with the two more intelligently. >In your case, I would care about throttling. In very most cases it actually >increases energy consumption, as the state being entered is technically the >same to ACPI C2 (IIRC), so it is only "forced" idling and only useful if >"forced" idling is needed to not need active cooling. Why would this cause more energy consumption? -Joseph -- trelane@digitasaru.net-------------------------------------------------- Graduate student in physics, Free Software developer. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan 2005-07-07 21:34 ` Joseph Pingenot @ 2005-07-07 21:51 ` Dominik Brodowski 0 siblings, 0 replies; 22+ messages in thread From: Dominik Brodowski @ 2005-07-07 21:51 UTC (permalink / raw) To: st3, Dave Jones, linux-kernel, cpufreq On Thu, Jul 07, 2005 at 04:34:14PM -0500, Joseph Pingenot wrote: > >From Dominik Brodowski on Thursday, 07 July, 2005: > >On Thu, Jul 07, 2005 at 03:51:17PM -0500, Joseph Pingenot wrote: > >> >Just a latest question: can be p4-clockmod used together with > >> >speedstep-centrino? If not, would it make any sense to patch > >> >speedstep-centrino to use this feature too? > >> I'm a little confused. How is this different from the ACPI CPU throttling > >> states (/proc/acpi/processor/CPUn/limit to set, throttling to see all > >> T-states available)? > >T-states _tend_ to be utilized using chipset logic, while p4-clockmod is > >done in-CPU. > >> On my 1.5-year-old Pentium-M, frequency scaling and T-states are different > >> beasties, and act entirely differently. I'm currently in the process of > >> rewriting my governor's brain to deal with the two more intelligently. > >In your case, I would care about throttling. In very most cases it actually > >increases energy consumption, as the state being entered is technically the > >same to ACPI C2 (IIRC), so it is only "forced" idling and only useful if > >"forced" idling is needed to not need active cooling. > > Why would this cause more energy consumption? Let's say a specific computing task needs 1s to run at 100% CPU load. The CPU consumes 22 W at normal operation, and 7.3 W when in ACPI C2 state which is technically equivalent to throttling. [note: these are _real_ values from a real datasheet for a real CPU you see in common usage] If you're at 0% CPU throttling rate, you need 22 Ws for this computing task, if you're at 25% 24 Ws, at 50% 29 Ws, and at 75% that is 44 Ws for this computing task. So for any sepcific computing task the energy consumption increases largely. But what if the system idle otherwise? If the CPU is put into an idle state the other time (e.g. there is no other computing task for the CPU to do in a four-second span), it depends on the idle state being used: if it is C2, these four seconds mean 44Ws of energy being used; if it is C3, the CPU only needs 5.1Ws, so at 0% CPU throttling you get 37 Ws; if it is C4, the CPU only needs 0.55Ws, so you only get 24 Ws which is much less than the 44Ws you have at 75% throttling. Please note that the weak spot in this calculation is the idle state the CPU is forced to when doing idling. My investigations lead to the assumption that it is the "Stop Grant" state on CPUs manufactored by Intel, which is most often described by the ACPI C2 state ("Stop-Grant state"), while C3 is "Deep Sleep State" or "Sleep State", and C4 is "Deeper Sleep State". Dominik ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan 2005-07-07 20:22 ` st3 2005-07-07 20:40 ` Dave Jones 2005-07-07 20:51 ` Joseph Pingenot @ 2005-07-07 21:10 ` Dominik Brodowski 2005-07-07 21:22 ` st3 2 siblings, 1 reply; 22+ messages in thread From: Dominik Brodowski @ 2005-07-07 21:10 UTC (permalink / raw) To: st3; +Cc: Dave Jones, cpufreq, linux-kernel On Thu, Jul 07, 2005 at 10:22:25PM +0200, st3@riseup.net wrote: > > This hasn't been seen to save any power whatsoever that I've seen. > > It drops down power rating by 1500-1800mW on my Toshiba Satellite A50 > while idling at 400MHz. Do you use ACPI-based idling? If so, in which state is the CPU in (cat /proc/acpi/processor/*/power ? I suspect that you do not use ACPI (else you wouldn't need the table-based approach) or that the ACPI-based idling is broken on your notebook; as then the Linux idle handler only makes use of "hlt" (IIRC), that is ACPI C1, while throttling "forces" ACPI C2 (again IIRC). Dominik ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan 2005-07-07 21:10 ` Dominik Brodowski @ 2005-07-07 21:22 ` st3 2005-07-07 21:29 ` Dominik Brodowski 0 siblings, 1 reply; 22+ messages in thread From: st3 @ 2005-07-07 21:22 UTC (permalink / raw) To: Dominik Brodowski; +Cc: Dave Jones, cpufreq, linux-kernel On Thu, 7 Jul 2005 23:10:33 +0200 Dominik Brodowski <linux@dominikbrodowski.net> wrote: > Do you use ACPI-based idling? If so, in which state is the CPU in (cat > /proc/acpi/processor/*/power ? I suspect that you do not use ACPI (else > you wouldn't need the table-based approach) or that the ACPI-based idling is > broken on your notebook; as then the Linux idle handler only makes use of > "hlt" (IIRC), that is ACPI C1, while throttling "forces" ACPI C2 (again > IIRC). For idling, I didn't mean 'real idling', but instead just 'doing nothing' in ACPI C1 state, that's simply a CPU usage < 1%. Sorry for being so lame =) -- ciao st3 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan 2005-07-07 21:22 ` st3 @ 2005-07-07 21:29 ` Dominik Brodowski 0 siblings, 0 replies; 22+ messages in thread From: Dominik Brodowski @ 2005-07-07 21:29 UTC (permalink / raw) To: st3; +Cc: Dave Jones, cpufreq, linux-kernel On Thu, Jul 07, 2005 at 11:22:38PM +0200, st3@riseup.net wrote: > On Thu, 7 Jul 2005 23:10:33 +0200 > Dominik Brodowski <linux@dominikbrodowski.net> wrote: > > > Do you use ACPI-based idling? If so, in which state is the CPU in (cat > > /proc/acpi/processor/*/power ? I suspect that you do not use ACPI (else > > you wouldn't need the table-based approach) or that the ACPI-based idling is > > broken on your notebook; as then the Linux idle handler only makes use of > > "hlt" (IIRC), that is ACPI C1, while throttling "forces" ACPI C2 (again > > IIRC). > > For idling, I didn't mean 'real idling', but instead just 'doing nothing' > in ACPI C1 state, that's simply a CPU usage < 1%. > > Sorry for being so lame =) That's exactly the "idling" I meant. So if it is only ACPI C1, then throttling makes some sense. It makes more sense, though, to get ACPI C2, C3 and possibly C4 to work :) Dominik ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan 2005-07-06 19:58 ` Bill Davidsen 2005-07-06 21:11 ` Dave Jones @ 2005-07-07 21:59 ` st3 2005-07-08 5:10 ` Dominik Brodowski 2005-07-08 10:59 ` Nikolay Pelov 1 sibling, 2 replies; 22+ messages in thread From: st3 @ 2005-07-07 21:59 UTC (permalink / raw) To: Bill Davidsen, linux-kernel; +Cc: cpufreq On Wed, 06 Jul 2005 15:58:53 -0400 Bill Davidsen <davidsen@tmr.com> wrote: > st3@riseup.net wrote: [snip] > > Moreover, I checked on Pentium M 725 and Pentium M 715 that the lowest > > frequency at which the CPU can be set safely is not the 600MHz given in > > datasheets, but 400MHz instead, with VID#A, VID#B, VID#C and VID#D (see > > datasheet for more details) set to 0.908V. > > > > I can provide a patch, let me know. > > Slower is better [snip] Here's a quick trick for getting CPU to lower frequencies than the ones read from ACPI tables, while still keeping them available. Just add these lines in centrino_cpu_init_acpi(), in speedstep-centrino.c, just after (and outside) the first 'for' cycle like this: for (i=0; i<p.state_count; i++) { ... centrino_model[cpu]->op_points[p.state_count - 1].index = 0x040D; centrino_model[cpu]->op_points[p.state_count - 1].frequency = 400000; p.states[p.state_count - 1].core_frequency = 400; This will enable 400MHz at 908mV, which I found to be useful on Dothan CPUs. If you want to get values for other frequencies/voltages, just use something like: #include <stdio.h> int main() { unsigned int index, frequency, voltage index = (((frequency)/100) << 8) | ((voltage - 700) / 16); printf ("%u\n", index); } frequency is expressed in MHz, voltage in mV, index is the value for centrino_model[cpu]->op_points[y].index <- remember to change this y if you want to add multiple frequencies besides the ACPI ones; for example, if you want 500MHz at 940mV, you could add: centrino_model[cpu]->op_points[p.state_count - 2].index = 0x1295; centrino_model[cpu]->op_points[p.state_count - 2].index = 500000; p.states[p.state_count - 2].core_frequency = 500; Sorry if I have been off-topic. -- ciao st3 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan 2005-07-07 21:59 ` st3 @ 2005-07-08 5:10 ` Dominik Brodowski 2005-07-08 8:58 ` st3 2005-07-08 10:59 ` Nikolay Pelov 1 sibling, 1 reply; 22+ messages in thread From: Dominik Brodowski @ 2005-07-08 5:10 UTC (permalink / raw) To: st3; +Cc: Bill Davidsen, linux-kernel, cpufreq On Thu, Jul 07, 2005 at 11:59:28PM +0200, st3@riseup.net wrote: > read from ACPI tables, while still keeping them available. You're only keeping some of them available, as you overwrite one such setting. Alternatively you can increase p.state_count by one early enough. > index = (((frequency)/100) << 8) | ((voltage - 700) / 16); > printf ("%u\n", index); printf ("0x%x\n", index); is better > want 500MHz at 940mV, you could add: > > centrino_model[cpu]->op_points[p.state_count - 2].index = 0x1295; > centrino_model[cpu]->op_points[p.state_count - 2].index = 500000; .frequency > p.states[p.state_count - 2].core_frequency = 500; Dominik ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan 2005-07-08 5:10 ` Dominik Brodowski @ 2005-07-08 8:58 ` st3 0 siblings, 0 replies; 22+ messages in thread From: st3 @ 2005-07-08 8:58 UTC (permalink / raw) To: Dominik Brodowski; +Cc: Bill Davidsen, linux-kernel, cpufreq On Fri, 8 Jul 2005 07:10:50 +0200 Dominik Brodowski <linux@dominikbrodowski.net> wrote: > On Thu, Jul 07, 2005 at 11:59:28PM +0200, st3@riseup.net wrote: > > read from ACPI tables, while still keeping them available. > > You're only keeping some of them available, as you overwrite one such > setting. Alternatively you can increase p.state_count by one early enough. Yes, but I was just overwriting the latest ones, that are never used =). Anyway, your solution is theoretically better. -- ciao st3 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan 2005-07-07 21:59 ` st3 2005-07-08 5:10 ` Dominik Brodowski @ 2005-07-08 10:59 ` Nikolay Pelov 1 sibling, 0 replies; 22+ messages in thread From: Nikolay Pelov @ 2005-07-08 10:59 UTC (permalink / raw) To: st3; +Cc: Bill Davidsen, linux-kernel, cpufreq On Thu, 7 Jul 2005 st3@riseup.net wrote: > > int main() { > unsigned int index, frequency, voltage > > index = (((frequency)/100) << 8) | ((voltage - 700) / 16); > printf ("%u\n", index); > } > > frequency is expressed in MHz, voltage in mV, index is the value for > centrino_model[cpu]->op_points[y].index Few days ago I discussed on the cpufreq mailing list that the above formula is not the correct way to compute the index. Instead of frequency, one should use a multiplier, i.e.: index = (multiplier << 8) | ((voltage - 700) / 16); and the multiplier is computed as multiplier = frequency/fsb_speed. On older systems fsb_speed = 100 MHz and that's why the original formula was working. But for the Sonoma (Centrino 2) Pentium M processors fsb_speed = 133 MHz. To give an example, take a CPU speed of 800MHz and a front side bus of 133MHz. Using the original formula we will use the value frequency/100 = 800/100 = 8 which is wrong. The correct value is: multiplier = frequency/fsb_speed = 800/133 = 6. Nikolay ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2005-07-08 11:00 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-07-06 9:22 speedstep-centrino on dothan st3 2005-07-06 14:06 ` Dominik Brodowski 2005-07-06 19:45 ` st3 2005-07-06 16:30 ` Pedro Ramalhais 2005-07-06 19:58 ` Bill Davidsen 2005-07-06 21:11 ` Dave Jones 2005-07-06 21:55 ` st3 2005-07-07 20:00 ` enhanced intel speedstep feature was " st3 2005-07-07 20:06 ` Dave Jones 2005-07-07 20:22 ` st3 2005-07-07 20:40 ` Dave Jones 2005-07-07 20:51 ` Joseph Pingenot 2005-07-07 21:08 ` Dominik Brodowski 2005-07-07 21:34 ` Joseph Pingenot 2005-07-07 21:51 ` Dominik Brodowski 2005-07-07 21:10 ` Dominik Brodowski 2005-07-07 21:22 ` st3 2005-07-07 21:29 ` Dominik Brodowski 2005-07-07 21:59 ` st3 2005-07-08 5:10 ` Dominik Brodowski 2005-07-08 8:58 ` st3 2005-07-08 10:59 ` Nikolay Pelov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox