* 2.5.64 - cpu freq not turned on
@ 2003-03-06 15:26 CaT
2003-03-06 23:32 ` Dominik Brodowski
0 siblings, 1 reply; 4+ messages in thread
From: CaT @ 2003-03-06 15:26 UTC (permalink / raw)
To: cpufreq; +Cc: linux-kernel
There was a 2.5.x kernel that allowed me to use cpufreq with it but the
recent ones just give me this message:
cpufreq: Intel(R) SpeedStep(TM) for this chipset not (yet) available.
Now I know it worked before cos I noticed it and played about with the 8
speed steps I had available to me (and I thought I only had 2).
What information is needed about my chipset to make the code detect it
properly?
(not on cpufreq ml btw)
--
"Other countries of course, bear the same risk. But there's no doubt his
hatred is mainly directed at us. After all this is the guy who tried to
kill my dad."
- George W. Bush Jr, 'President' of the United States
September 26, 2002 (from a political fundraiser in Huston, Texas)
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: 2.5.64 - cpu freq not turned on 2003-03-06 15:26 2.5.64 - cpu freq not turned on CaT @ 2003-03-06 23:32 ` Dominik Brodowski 2003-03-07 0:17 ` CaT 0 siblings, 1 reply; 4+ messages in thread From: Dominik Brodowski @ 2003-03-06 23:32 UTC (permalink / raw) To: CaT; +Cc: cpufreq, linux-kernel Hi, On Fri, Mar 07, 2003 at 02:26:16AM +1100, CaT wrote: > There was a 2.5.x kernel that allowed me to use cpufreq with it but the > recent ones just give me this message: > > cpufreq: Intel(R) SpeedStep(TM) for this chipset not (yet) available. > > Now I know it worked before cos I noticed it and played about with the 8 > speed steps I had available to me (and I thought I only had 2). Actually, SpeedStep is (so far, Banias isn't out to the public market yet) only 2 states. What you had running was probably the p4-clockmod driver for Intel Pentium 4 processors. But that does only throttle the CPU, which causes (at best) linear energy saving while real "speedstep" is much better than that. You can see what cpufreq driver is loaded by cat'ting scaling_driver in the cpufreq sysfs directory for that cpu. This directory moved in 2.5.64 - and that's why you probably think there was some regression (in fact, there is, but patches to fix that are on their way...) - the sysfs interface to cpufreq is now in /sys/devices/sys/cpu0/cpufreq/ or /sys/class/cpu/cpufreq/cpu0/cpufreq/ > What information is needed about my chipset to make the code detect it > properly? lspci -- maybe it's a ich4-m southbridge, then the attached patch (also sent to Linus a few moments ago) might help. Dominik diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/speedstep.c linux/arch/i386/kernel/cpu/cpufreq/speedstep.c --- linux-original/arch/i386/kernel/cpu/cpufreq/speedstep.c 2003-03-06 21:56:18.000000000 +0100 +++ linux/arch/i386/kernel/cpu/cpufreq/speedstep.c 2003-03-06 21:57:07.000000000 +0100 @@ -29,6 +29,9 @@ #include <asm/msr.h> +#ifndef PCI_DEVICE_ID_INTEL_82801DB_12 +#define PCI_DEVICE_ID_INTEL_82801DB_12 0x24cc +#endif /* speedstep_chipset: * It is necessary to know which chipset is used. As accesses to @@ -40,7 +43,7 @@ #define SPEEDSTEP_CHIPSET_ICH2M 0x00000002 #define SPEEDSTEP_CHIPSET_ICH3M 0x00000003 - +#define SPEEDSTEP_CHIPSET_ICH4M 0x00000004 /* speedstep_processor */ @@ -106,6 +109,7 @@ switch (speedstep_chipset) { case SPEEDSTEP_CHIPSET_ICH2M: case SPEEDSTEP_CHIPSET_ICH3M: + case SPEEDSTEP_CHIPSET_ICH4M: /* get PMBASE */ pci_read_config_dword(speedstep_chipset_dev, 0x40, &pmbase); if (!(pmbase & 0x01)) @@ -166,6 +170,7 @@ switch (speedstep_chipset) { case SPEEDSTEP_CHIPSET_ICH2M: case SPEEDSTEP_CHIPSET_ICH3M: + case SPEEDSTEP_CHIPSET_ICH4M: /* get PMBASE */ pci_read_config_dword(speedstep_chipset_dev, 0x40, &pmbase); if (!(pmbase & 0x01)) @@ -245,6 +250,7 @@ switch (speedstep_chipset) { case SPEEDSTEP_CHIPSET_ICH2M: case SPEEDSTEP_CHIPSET_ICH3M: + case SPEEDSTEP_CHIPSET_ICH4M: { u16 value = 0; @@ -277,6 +283,14 @@ static unsigned int speedstep_detect_chipset (void) { speedstep_chipset_dev = pci_find_subsys(PCI_VENDOR_ID_INTEL, + PCI_DEVICE_ID_INTEL_82801DB_12, + PCI_ANY_ID, + PCI_ANY_ID, + NULL); + if (speedstep_chipset_dev) + return SPEEDSTEP_CHIPSET_ICH4M; + + speedstep_chipset_dev = pci_find_subsys(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_12, PCI_ANY_ID, PCI_ANY_ID, ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.5.64 - cpu freq not turned on 2003-03-06 23:32 ` Dominik Brodowski @ 2003-03-07 0:17 ` CaT 2003-03-07 11:22 ` Ducrot Bruno 0 siblings, 1 reply; 4+ messages in thread From: CaT @ 2003-03-07 0:17 UTC (permalink / raw) To: Dominik Brodowski; +Cc: cpufreq, linux-kernel On Fri, Mar 07, 2003 at 12:32:28AM +0100, Dominik Brodowski wrote: > > Now I know it worked before cos I noticed it and played about with the 8 > > speed steps I had available to me (and I thought I only had 2). > > Actually, SpeedStep is (so far, Banias isn't out to the public market yet) > only 2 states. What you had running was probably the p4-clockmod driver for > Intel Pentium 4 processors. But that does only throttle the CPU, which Ahhh. I have a P3 though. > causes (at best) linear energy saving while real "speedstep" is much better > than that. You can see what cpufreq driver is loaded by cat'ting > scaling_driver in the cpufreq sysfs directory for that cpu. Not there. > This directory moved in 2.5.64 - and that's why you probably think there was > some regression (in fact, there is, but patches to fix that are on their > way...) - the sysfs interface to cpufreq is now in 2.5.63 doesn't turn speedstep on for me either. > > What information is needed about my chipset to make the code detect it > > properly? > > lspci -- maybe it's a ich4-m southbridge, then the attached patch > (also sent to Linus a few moments ago) might help. Didn't apply the patch cos I don't see that in the lspci output: 00:00.0 Host bridge: Intel Corp. 440BX/ZX - 82443BX/ZX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corp. 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 00:07.0 Bridge: Intel Corp. 82371AB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corp. 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corp. 82371AB PIIX4 ACPI (rev 03) The rest are sound, cardbus etc. -- "Other countries of course, bear the same risk. But there's no doubt his hatred is mainly directed at us. After all this is the guy who tried to kill my dad." - George W. Bush Jr, 'President' of the United States September 26, 2002 (from a political fundraiser in Huston, Texas) ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.5.64 - cpu freq not turned on 2003-03-07 0:17 ` CaT @ 2003-03-07 11:22 ` Ducrot Bruno 0 siblings, 0 replies; 4+ messages in thread From: Ducrot Bruno @ 2003-03-07 11:22 UTC (permalink / raw) To: CaT; +Cc: Dominik Brodowski, cpufreq, linux-kernel On Fri, Mar 07, 2003 at 11:17:24AM +1100, CaT wrote: > Didn't apply the patch cos I don't see that in the lspci output: > > 00:00.0 Host bridge: Intel Corp. 440BX/ZX - 82443BX/ZX Host bridge (rev 03) > 00:01.0 PCI bridge: Intel Corp. 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) > 00:07.0 Bridge: Intel Corp. 82371AB PIIX4 ISA (rev 02) > 00:07.1 IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 01) > 00:07.2 USB Controller: Intel Corp. 82371AB PIIX4 USB (rev 01) > 00:07.3 Bridge: Intel Corp. 82371AB PIIX4 ACPI (rev 03) > PIIX4EM southbridges are still in reverse-engeenering process. Im also wondering why Intel still make this old stuff under NDA? Cheers, -- Ducrot Bruno http://www.poupinou.org Page profaissionelle http://toto.tu-me-saoules.com Haume page ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-03-07 11:11 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-03-06 15:26 2.5.64 - cpu freq not turned on CaT 2003-03-06 23:32 ` Dominik Brodowski 2003-03-07 0:17 ` CaT 2003-03-07 11:22 ` Ducrot Bruno
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).