cpufreq and P-IIIM

Hi,

I've just tried the latest 2.4 snapshot of cpufreq. Unfortunately, it doesn't seem to work on my hardware. It says:

cpufreq: Intel(R) SpeedStep(TM) support $Revision: 1.7.2.6 $
cpufreq: Intel(R) SpeedStep(TM) for this chipset not (yet) available.

/proc/cpuinfo says:

  processor       : 0
  vendor_id       : GenuineIntel
  cpu family      : 6
  model           : 11
  model name      : Intel(R) Pentium(R) III Mobile CPU       750MHz
  stepping        : 1
  cpu MHz         : 746.352
  cache size      : 512 KB
  fdiv_bug        : no
  hlt_bug         : no
  f00f_bug        : no
  coma_bug        : no
  fpu             : yes
  fpu_exception   : yes
  cpuid level     : 2
  wp              : yes
  flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse
  bogomips        : 1490.94

lspci says:
00:00.0 Class 0600: 8086:7194 (rev 01)
00:00.1 Class 0401: 8086:7195
00:00.2 Class 0703: 8086:7196
00:07.0 Class 0601: 8086:7198 (rev 01)
00:07.1 Class 0101: 8086:7199
00:07.2 Class 0c03: 8086:719a
00:07.3 Class 0680: 8086:719b
00:09.0 Class 0300: 1002:4c52 (rev 64)
00:0a.0 Class 0607: 104c:ac1b (rev 03)
00:0a.1 Class 0607: 104c:ac1b (rev 03)
00:0b.0 Class 0200: 10ec:8139 (rev 10)

which translates to:
00:00.0 Host bridge: Intel Corp. 82440MX Host Bridge (rev 01)
00:00.1 Multimedia audio controller: Intel Corp. 82440MX AC'97 Audio Controller 00:00.2 Modem: Intel Corp. 82440MX AC'97 Modem Controller
00:07.0 ISA bridge: Intel Corp. 82440MX ISA Bridge (rev 01)
00:07.1 IDE interface: Intel Corp. 82440MX EIDE Controller
00:07.2 USB Controller: Intel Corp. 82440MX USB Universal Host Controller 00:07.3 Bridge: Intel Corp. 82440MX Power Management Controller
00:09.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M (rev 64) 00:0a.0 CardBus bridge: Texas Instruments PCI1450 (rev 03)
00:0a.1 CardBus bridge: Texas Instruments PCI1450 (rev 03)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

Now, I have been successfully using Marc Lehmann's 'speedstep' utility, which after minor changes (mostly uncommenting security checks) works perfectly for me. When checking state (speedstep -g), it prints:
EDI == 02020304 != 02020005|02020004,

but I can check speedstep state, and switch it up or down using this utility. I've attached the (lobotomized by me) speedstep.c that works for me just fine.

Is there a chance that cpufreq could start supporting my machine?

--J.

That version is way too old anyway.

Take a look at www.poupinou.org/cpufreq/

Cheers,

Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Ducrot> That version is way too old anyway.

Huh? That was the latest 2.4 snapshot that I was able to pull from ftp.linux.org.uk: cpufreq-LINUX_2_4-20030816.tar.bz2.

If these are not the 'official' archives and the snapshots are outdated, I'd humbly suggest pulling them off the net, because it confuses people. I was pointed there to get my cpufreq for 2.4, after being referred to www.codemonkey.org.uk which has never worked for me in the last 3 weeks of trying.

[...]
Ducrot> Take a look at www.poupinou.org/cpufreq/

Thanks for the pointer.

--J.

As far as I'm concerned (as being the guy running the CVS and FTP archive) they remain official until the cpufreq maintainers explicitly tell me otherwise.

Maintainers need to either check their changes into the CVS tree or tell me that they no longer wish to use CVS, or tell me that they want a 2.4-ac branch, or whatever.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

AFAICS,
a) the 2.6. branch development is done in Dave's BK tree.
b) 2.4-new [== backport of 2.6. to 2.4.] was never done in CVS,
c) 2.4-ac tags exist, but because of b) are not kept up to date,
d) depending on the outcome of the ARM and cpufreq-2.4. issue, 2.4-stable [which is CVS LINUX_2_4] is going to be deprecated soon.

Also, it is my impression that an external CVS tree is used far less if a feature is merged into a mainline kernel. If it's not in the kernel, keeping track of a project without something like CVS is impossible. So I'm really glad about having had cpufreq-CVS and FTP-archives available. But, for the future, I don't see such a strong reason for keeping it.

Just my ¤0.02
Dominik

As you're aware (we discussed this at the time when cpufreq was merged into 2.5) that's my POV as well.

That just leaves davej and ducrot to say exactly what they want killed. I'll consider going as far as taring up the CVS tree as it currently stands and putting that on the ftp site for history, if that's what people want.

But people have to tell me... 8)

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

I don't think that my opinion is so important...
I would much like to let stuff like it is. If ARM people agreed, we can import the new code in LINUX_2_4 since it is the one that may be merged in Marcello tree anyway.

I would be happy also to get some opinions from PPC people.

Cheers,

Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

I definitely want the core in 2.4 asap ;)

Ben.

Ah, I forgot about this information. Hence my misinterpretation of Duncrot's submits.

Agree. Can you put the 2.4 backport in CVS? Then Duncrot's changes can be merged in a structured manner.

Russell, can you update the documentation on <http://www.arm.linux.org.uk/cvs/> for cpufreq when things have settled?

(this is just a proposal, please comment)

CPU clock frequency and voltage scaling for Linux, for x86 and ARM based processors. This module provides a user-space and standard kernel-space interface to these features, allowing ARM system-on-a-chip devices and x86 platforms to cope with processor clock speed and cpu voltage changes. Because not all combinations of clock speed and cpu voltage changes are allowed, tables with valid combinations are included for certain processors are included with the module.

Since the power consumed by a processor is directly related to the speed and voltage at which it is running, keeping the clock speed and voltage as low as possible allows you to get more run-time out of your battery and lower the dissipation (heat) of your computer. Some people use this to adjust their clock speed many times a second to optimise performance vs battery life.

Most up to date documentation is included in the module directory linux/Documentation/cpufreq

The following branches are available:

LINUX_2_4            - Stable older implementation for 2.4 kernels. (might die soon)
LINUX_2_4_BACKPORT   - Backport of 2.5/2.6 implementation
LINUX_2_5            - for 2.5 and upcoming 2.6 kernels. (main branch???)

(we could reuse LINUX_2_4 for the backport if the ARM guys don't need the old implementation any more).

Regards,

Bas.

[...]
Ducrot> Take a look at www.poupinou.org/cpufreq/

Files below, if anybody is interested.

Also, FWIW, cpufreq in 2.6.0-test3 doesn't support this chipset either.

--J.

AC:

dmi_scan: return:
DMI 2.3 present.
46 structures occupying 1291 bytes.
DMI table at 0x000D8010.
BIOS Vendor: Phoenix Technologies LTD
BIOS Version: 4.06.1
BIOS Release: 12/18/2001
System Vendor: SHARP Corporation
Product Name: TBD
Version: 1.0
Board Vendor: SHARP Corporation
Board Name: TBD
Board Version: 1.0
Trying Intel's int15 GSIC:
BIOS support GSIC call:

	signature: GSIC
	command port = 0x00b2
	command =      0x0082
	event port =   0x000000b3
	flags =        0x07d00100

probing chipsets: Found PIIX4 (embeded in MX440 chipset)
pmbase at 0x1000
Dumping PM IO register for this southbridge:
PMCNTRL (0x1004): 0x1401

(0x1006):         0x0000
GPEN (0x100e):    0x3800
PCNTRL (0x1010):  0x00001203
(0x1016):         0x0000
DEVSTS (0x101c):  0x00000000
GLBLEN (0x1020):  0x8000
(0x1022):         0x02f70000
GLBCTL (0x1028):  0x0301ff05
DEVCTL (0x102c):  0x00200000
GPIs: (0x1030):   0x120242
(0x1033):         0x61
GPOs: (0x1034):   0x400c000a
(0x1038):         0x30 0xa0 0x04 0x10 0x00 0x00 0x00 0x01 

You need to boot on AC and battery and see if GPOs change. Then, see if one bit change in between, you have then to note the number of this bit. This will be the gpo_hilo= number kernel option for enabling the speedstep-piix4 module under Linux.

                                      ..28..24..20..16..12...8...4...0
        GPOs: (0x1034):   0x400c000a  01000000000011000000000000001010

BATTERY:

dmi_scan: return:
DMI 2.3 present.
46 structures occupying 1291 bytes.
DMI table at 0x000D8010.
BIOS Vendor: Phoenix Technologies LTD
BIOS Version: 4.06.1
BIOS Release: 12/18/2001
System Vendor: SHARP Corporation
Product Name: TBD
Version: 1.0
Board Vendor: SHARP Corporation
Board Name: TBD
Board Version: 1.0
Trying Intel's int15 GSIC:
BIOS support GSIC call:

	signature: GSIC
	command port = 0x00b2
	command =      0x0082
	event port =   0x000000b3
	flags =        0x07d00100

probing chipsets: Found PIIX4 (embeded in MX440 chipset)
pmbase at 0x1000
Dumping PM IO register for this southbridge:
PMCNTRL (0x1004): 0x1401

(0x1006):         0x0000
GPEN (0x100e):    0x3800
PCNTRL (0x1010):  0x00001203
(0x1016):         0x0000
DEVSTS (0x101c):  0x00000000
GLBLEN (0x1020):  0x8000
(0x1022):         0x02f70000
GLBCTL (0x1028):  0x0301ff05
DEVCTL (0x102c):  0x00200000
GPIs: (0x1030):   0x120242
(0x1033):         0x61
GPOs: (0x1034):   0x400c002a
(0x1038):         0x30 0xa0 0x04 0x10 0x00 0x08 0x00 0x01 

You need to boot on AC and battery and see if GPOs change. Then, see if one bit change in between, you have then to note the number of this bit. This will be the gpo_hilo= number kernel option for enabling the speedstep-piix4 module under Linux.

                                      ..28..24..20..16..12...8...4...0
        GPOs: (0x1034):   0x400c002a  01000000000011000000000000101010

Could you please try:
modprobe speedstep-piix4 gpo_hilo=5

btw, have you tryed the latest patch? ftp://ftp.poupinou.org/cpufreq/speedstep-piix4-260-test3.diff.bz2

I can not be sure if it work, since I have no hardware to test.

If that still refuse to work, please decomment SPEEDSTEP_DEBUG both in speedstep-piix4.c and speedstep-lib.c

Cheers,

Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.