Skip to contentSkip to conversation

- Initial dothan speedstep support

PATCH In review Michael Clark 3 participants 8 messages Aug 6, 2004 – Aug 23, 2004

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 - Initial dothan speedstep support

Hi All,

Was looking for a patch for Dothan cpufreq support but could only find the stepping identification code here:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7/2.6.7-mm6/broken-out/bk-cpufreq.patch

So here's a patch on top of the above patch that adds all of the dothan frequency/voltages for processors 715, 725, 735, 745, 755

Tested and working as it should so far with a 745. The stepping in the model table for the others may need to be tweaked.

The Dothan processor datasheet 30218903.pdf defines 4 voltages for each frequency (VID#A through VID#D) whereas Banias only suggests a typical voltage and no min or max for each freq so i've used the OP macro to allow definition of all voltages (A through D) but the macro currently just uses VID#C at compile time (the second lowest voltage profile).

The docs define these 4 profiles but don't say anywhere in which cases they should be used. I guess it may be a case of usage of the differing profiles based on the tolerance and accuracy of the power supply in use for the specific application.

~mc

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c renamed from arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c.bk-patched +88 -0
@@ -198,6 +198,82 @@
 	OP(1700, 1484),
 	{ .frequency = CPUFREQ_TABLE_END }
 };
+
+#undef OP
+
+/* Dothan processor datasheet 30218903.pdf defines 4 voltages for each
+   frequency (VID#A through VID#D) - this macro allows us to define all
+   of these but we only use the VID#C voltages at compile time - this may
+   need some work if we want to select the voltage profile at runtime. */
+
+#define OP(mhz, mva, mvb, mvc, mvd)					\
+	{								\
+		.frequency = (mhz) * 1000,				\
+		.index = (((mhz)/100) << 8) | ((mvc - 700) / 16)       	\
+	}
+
+/* Intel Pentium M processor 715 / 1.50GHz (Dothan) */
+static struct cpufreq_frequency_table dothan_1500[] =
+{
+	OP( 600,  988,  988,  988,  988),
+	OP( 800, 1068, 1068, 1068, 1052),
+	OP(1000, 1148, 1148, 1132, 1116),
+	OP(1200, 1228, 1212, 1212, 1180),
+	OP(1500, 1340, 1324, 1308, 1276),
+	{ .frequency = CPUFREQ_TABLE_END }
+};
+
+/* Intel Pentium M processor 725 / 1.60GHz (Dothan) */
+static struct cpufreq_frequency_table dothan_1600[] =
+{
+	OP( 600,  988,  988,  988,  988),
+	OP( 800, 1068, 1068, 1052, 1052),
+	OP(1000, 1132, 1132, 1116, 1116),
+	OP(1200, 1212, 1196, 1180, 1164),
+	OP(1400, 1276, 1260, 1244, 1228),
+	OP(1600, 1340, 1324, 1308, 1276),
+	{ .frequency = CPUFREQ_TABLE_END }
+};
+
+/* Intel Pentium M processor 735 / 1.70GHz (Dothan) */
+static struct cpufreq_frequency_table dothan_1700[] =
+{
+	OP( 600,  988,  988,  988,  988),
+	OP( 800, 1052, 1052, 1052, 1052),
+	OP(1000, 1116, 1116, 1116, 1100),
+	OP(1200, 1180, 1180, 1164, 1148),
+	OP(1400, 1244, 1244, 1228, 1212),
+	OP(1700, 1340, 1324, 1308, 1276),
+	{ .frequency = CPUFREQ_TABLE_END }
+};
+
+/* Intel Pentium M processor 745 / 1.80GHz (Dothan) */
+static struct cpufreq_frequency_table dothan_1800[] =
+{
+	OP( 600,  988,  988,  988,  988),
+	OP( 800, 1052, 1052, 1052, 1036),
+	OP(1000, 1116, 1100, 1100, 1084),
+	OP(1200, 1164, 1164, 1148, 1132),
+	OP(1400, 1228, 1212, 1212, 1180),
+	OP(1600, 1292, 1276, 1260, 1228),
+	OP(1800, 1340, 1324, 1308, 1276),
+	{ .frequency = CPUFREQ_TABLE_END }
+};
+
+/* Intel Pentium M processor 755 / 2.00GHz (Dothan) */
+static struct cpufreq_frequency_table dothan_2000[] =
+{
+	OP( 600,  988,  988,  988,  988),
+	OP( 800, 1052, 1036, 1036, 1036),
+	OP(1000, 1100, 1084, 1084, 1084),
+	OP(1200, 1148, 1132, 1132, 1116),
+	OP(1400, 1196, 1180, 1180, 1164),
+	OP(1600, 1244, 1228, 1228, 1196),
+	OP(1800, 1292, 1276, 1276, 1244),
+	OP(2000, 1340, 1324, 1308, 1276),
+	{ .frequency = CPUFREQ_TABLE_END }
+};
+
 #undef OP
 
 #define _BANIAS(cpuid, max, name)	\
@@ -208,6 +284,13 @@
 }
 #define BANIAS(max)	_BANIAS(&cpu_id_banias, max, #max)
 
+#define DOTHAN(cpuid, max, name)	\
+{	.cpu_id		= cpuid,	\
+	.model_name	= "Intel(R) Pentium(R) M processor " name "GHz", \
+	.max_freq	= (max)*1000,	\
+	.op_points	= dothan_##max,	\
+}
+
 /* CPU models, their operating frequency range, and freq/voltage
    operating points */
 static struct cpu_model models[] = 
@@ -221,6 +304,11 @@
 	BANIAS(1500),
 	BANIAS(1600),
 	BANIAS(1700),
+	DOTHAN(&cpu_id_dothan_b0, 1500, "1.50"), /* check stepping and name */
+	DOTHAN(&cpu_id_dothan_b0, 1600, "1.60"), /* check stepping and name */
+	DOTHAN(&cpu_id_dothan_b0, 1700, "1.70"), /* check stepping and name */
+	DOTHAN(&cpu_id_dothan_b0, 1800, "1.80"),
+	DOTHAN(&cpu_id_dothan_b0, 2000, "2.00"), /* check stepping and name */
 	{ NULL, }
 };
 #undef _BANIAS
#1 lore raw
Quoted 6 lines · Michael Clark

Hi All,

Was looking for a patch for Dothan cpufreq support but could only find the stepping identification code here:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7/2.6.7-mm6/broken-out/bk-cpufreq.patch

I've since found there is a newer speedstep-centrino in 2.6.8-rc3-mm1 although still without dothan support but slight changes for more informative messages about steppings without needed table support.

So i've rediffed table support for dothan b0 steppings to 2.6.8-rc3-mm1 and have verified by googling that b0 stepping exists for at least 1.5 through 1.8 (anyone have a 2.0GHz dothan?)

Also proofread the voltage tables against the docs just to make sure.

~mc

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c renamed from arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c.orig +89 -0
@@ -195,6 +195,82 @@
 	OP(1700, 1484),
 	{ .frequency = CPUFREQ_TABLE_END }
 };
+
+#undef OP
+
+/* Dothan processor datasheet 30218903.pdf defines 4 voltages for each
+   frequency (VID#A through VID#D) - this macro allows us to define all
+   of these but we only use the VID#C voltages at compile time - this may
+   need some work if we want to select the voltage profile at runtime. */
+
+#define OP(mhz, mva, mvb, mvc, mvd)					\
+	{								\
+		.frequency = (mhz) * 1000,				\
+		.index = (((mhz)/100) << 8) | ((mvc - 700) / 16)       	\
+	}
+
+/* Intel Pentium M processor 715 / 1.50GHz (Dothan) */
+static struct cpufreq_frequency_table dothan_1500[] =
+{
+	OP( 600,  988,  988,  988,  988),
+	OP( 800, 1068, 1068, 1068, 1052),
+	OP(1000, 1148, 1148, 1132, 1116),
+	OP(1200, 1228, 1212, 1212, 1180),
+	OP(1500, 1340, 1324, 1308, 1276),
+	{ .frequency = CPUFREQ_TABLE_END }
+};
+
+/* Intel Pentium M processor 725 / 1.60GHz (Dothan) */
+static struct cpufreq_frequency_table dothan_1600[] =
+{
+	OP( 600,  988,  988,  988,  988),
+	OP( 800, 1068, 1068, 1052, 1052),
+	OP(1000, 1132, 1132, 1116, 1116),
+	OP(1200, 1212, 1196, 1180, 1164),
+	OP(1400, 1276, 1260, 1244, 1228),
+	OP(1600, 1340, 1324, 1308, 1276),
+	{ .frequency = CPUFREQ_TABLE_END }
+};
+
+/* Intel Pentium M processor 735 / 1.70GHz (Dothan) */
+static struct cpufreq_frequency_table dothan_1700[] =
+{
+	OP( 600,  988,  988,  988,  988),
+	OP( 800, 1052, 1052, 1052, 1052),
+	OP(1000, 1116, 1116, 1116, 1100),
+	OP(1200, 1180, 1180, 1164, 1148),
+	OP(1400, 1244, 1244, 1228, 1212),
+	OP(1700, 1340, 1324, 1308, 1276),
+	{ .frequency = CPUFREQ_TABLE_END }
+};
+
+/* Intel Pentium M processor 745 / 1.80GHz (Dothan) */
+static struct cpufreq_frequency_table dothan_1800[] =
+{
+	OP( 600,  988,  988,  988,  988),
+	OP( 800, 1052, 1052, 1052, 1036),
+	OP(1000, 1116, 1100, 1100, 1084),
+	OP(1200, 1164, 1164, 1148, 1132),
+	OP(1400, 1228, 1212, 1212, 1180),
+	OP(1600, 1292, 1276, 1260, 1228),
+	OP(1800, 1340, 1324, 1308, 1276),
+	{ .frequency = CPUFREQ_TABLE_END }
+};
+
+/* Intel Pentium M processor 755 / 2.00GHz (Dothan) */
+static struct cpufreq_frequency_table dothan_2000[] =
+{
+	OP( 600,  988,  988,  988,  988),
+	OP( 800, 1052, 1036, 1036, 1036),
+	OP(1000, 1100, 1084, 1084, 1084),
+	OP(1200, 1148, 1132, 1132, 1116),
+	OP(1400, 1196, 1180, 1180, 1164),
+	OP(1600, 1244, 1228, 1228, 1196),
+	OP(1800, 1292, 1276, 1276, 1244),
+	OP(2000, 1340, 1324, 1308, 1276),
+	{ .frequency = CPUFREQ_TABLE_END }
+};
+
 #undef OP
 
 #define _BANIAS(cpuid, max, name)	\
@@ -205,6 +281,13 @@
 }
 #define BANIAS(max)	_BANIAS(&cpu_ids[CPU_BANIAS], max, #max)
 
+#define DOTHAN(cpuid, max, name)	\
+{	.cpu_id		= cpuid,	\
+	.model_name	= "Intel(R) Pentium(R) M processor " name "GHz", \
+	.max_freq	= (max)*1000,	\
+	.op_points	= dothan_##max,	\
+}
+
 /* CPU models, their operating frequency range, and freq/voltage
    operating points */
 static struct cpu_model models[] =
@@ -218,6 +301,11 @@
 	BANIAS(1500),
 	BANIAS(1600),
 	BANIAS(1700),
+	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1500, "1.50"),
+	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1600, "1.60"),
+	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1700, "1.70"),
+	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1800, "1.80"),
+	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 2000, "2.00"),
 
 	/* NULL model_name is a wildcard */
 	{ &cpu_ids[CPU_DOTHAN_A1], NULL, 0, NULL },
@@ -227,6 +315,7 @@
 };
 #undef _BANIAS
 #undef BANIAS
+#undef DOTHAN
 
 static int centrino_cpu_init_table(struct cpufreq_policy *policy)
 {
#2 lore raw
Quoted 6 lines · Michael Clark
Quoted 5 lines · Michael Clark

Hi All,

Was looking for a patch for Dothan cpufreq support but could only find the stepping identification code here:

Quoted 7 lines
Quoted 1 line

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7/2.6.7-mm6/broken-out/bk-cpufreq.patch

I've since found there is a newer speedstep-centrino in 2.6.8-rc3-mm1 although still without dothan support but slight changes for more informative messages about steppings without needed table support.

So i've rediffed table support for dothan b0 steppings to 2.6.8-rc3-mm1

Merged, thanks.
I've accumulated quite a lot of changes in the cpufreq bk tree (around 30 csets), and Linus didn't respond the last time I asked him to merge, so it may be he feels theres too much change for an RC -> Final transition. I'll send a pull request again when 2.6.9 opens up.

Dave

#3 lore raw

Hi Dave, Jeremy,

I thought i'd give the ACPI code in speedstep-centrino a try as I wanted to see what the BIOS freq/voltage tables the vendor was using due to the apparent choice of voltages (VID#A through VID#C) in the processor specs.

Anyway this is what I found (with the debug code in attached patch):

centrino_cpu_init_acpi: 1800000000 Hz, 1340e-03 volts
centrino_cpu_init_acpi: 1600000000 Hz, 1292e-03 volts
centrino_cpu_init_acpi: 1400000000 Hz, 1228e-03 volts
centrino_cpu_init_acpi: 1200000000 Hz, 1164e-03 volts
centrino_cpu_init_acpi: 1000000000 Hz, 1116e-03 volts
centrino_cpu_init_acpi: 800000000 Hz, 1052e-03 volts
centrino_cpu_init_acpi: 600000000 Hz, 988e-03 volts

It appears the T42 is using the VID#A voltages (the highest) and my patch was using VID#C (the 2nd from lowest) for which the upper voltage has the biggest difference being 0.032 volts lower - not much in it.

As I said earlier in my reading of the specs there seemed to be no guidance on which profile to use aside from the voltage and ripple tolerance tables.

So the attached patch (in addition to ACPI freq table debug message) changes the table version to use the VID#A voltage so as to err on the conservative side of a higher voltage (as the upper voltage max for the chip is 1.6v) to allow for cases where the error on the voltage would drop it too low - not sure if just IBM are using this. Would be interesting to see the ACPI freq/voltage tables for other vendor's Dothan laptops.

Not sure on whether we should do this although it means we match at least what one vendor has done? Any ideas? (debug printk may be useful for those with ACPI and speedstep for debugging incorrect BIOS tables).

Thanks
~mc

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c renamed from arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c.tmp +5 -1
@@ -206,7 +206,7 @@
 #define OP(mhz, mva, mvb, mvc, mvd)					\
 	{								\
 		.frequency = (mhz) * 1000,				\
-		.index = (((mhz)/100) << 8) | ((mvc - 700) / 16)       	\
+		.index = (((mhz)/100) << 8) | ((mva - 700) / 16)       	\
 	}
 
 /* Intel Pentium M processor 715 / 1.50GHz (Dothan) */
@@ -493,6 +493,10 @@
         for (i=0; i<p.state_count; i++) {
 		centrino_model->op_points[i].index = p.states[i].control;
 		centrino_model->op_points[i].frequency = p.states[i].core_frequency * 1000;
+		printk(KERN_DEBUG "centrino_cpu_init_acpi: "
+		       "%d Hz, %de-03 volts\n", 
+		       centrino_model->op_points[i].frequency * 1000,
+		       (centrino_model->op_points[i].index & 0xff) * 16 + 700);
 	}
 	centrino_model->op_points[p.state_count].frequency = CPUFREQ_TABLE_END;
 
#4 lore raw

Apologies for patch as base64 attachment - i can resend if need be. ~mc

#5 lore raw
In reply to Michael Clark

Hi!

Quoted 6 lines

So here's a patch on top of the above patch that adds all of the dothan frequency/voltages for processors 715, 725, 735, 745, 755

Tested and working as it should so far with a 745. The stepping in the model table for the others may need to be tweaked.

Quoted 6 lines

The Dothan processor datasheet 30218903.pdf defines 4 voltages for each frequency (VID#A through VID#D) whereas Banias only suggests a typical voltage and no min or max for each freq so i've used the OP macro to allow definition of all voltages (A through D) but the macro currently just uses VID#C at compile time (the second lowest voltage profile).

I thought that whether to use VID#A, B, C or D depends on your concrete chip? Not all chips are certified to run on VID#C...
Pavel

Signature · 1 line
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         
#6 lore raw
Quoted 15 lines

Hi!

Quoted 6 lines

So here's a patch on top of the above patch that adds all of the dothan frequency/voltages for processors 715, 725, 735, 745, 755

Tested and working as it should so far with a 745. The stepping in the model table for the others may need to be tweaked.

Quoted 6 lines

The Dothan processor datasheet 30218903.pdf defines 4 voltages for each frequency (VID#A through VID#D) whereas Banias only suggests a typical voltage and no min or max for each freq so i've used the OP macro to allow definition of all voltages (A through D) but the macro currently just uses VID#C at compile time (the second lowest voltage profile).

Quoted 2 lines

I thought that whether to use VID#A, B, C or D depends on your concrete chip? Not all chips are certified to run on VID#C...

Yes, I believe this is the case. When I read the processor spec document it did not mention this but since then i found this out. I've since changed the patch to use the VID#A voltages which is more conservative (assuming that all of them will run at the higher voltage okay which according to the upper voltage rating of 1.6 volts might be okay). It would of course be preferrable to work out the the type VID#A,B,C,D via software - not sure if this is possible.

~mc

#7 lore raw
Quoted 20 lines · Michael
Quoted 16 lines

Hi!

Quoted 6 lines

So here's a patch on top of the above patch that adds all of the dothan frequency/voltages for processors 715, 725, 735, 745, 755

Tested and working as it should so far with a 745. The stepping in the model table for the others may need to be tweaked.

Quoted 6 lines

The Dothan processor datasheet 30218903.pdf defines 4 voltages for each frequency (VID#A through VID#D) whereas Banias only suggests a typical voltage and no min or max for each freq so i've used the OP macro to allow definition of all voltages (A through D) but the macro currently just uses VID#C at compile time (the second lowest voltage profile).

Quoted 2 lines

I thought that whether to use VID#A, B, C or D depends on your concrete chip? Not all chips are certified to run on VID#C...

Quoted 5 lines

Yes, I believe this is the case. When I read the processor spec document it did not mention this but since then i found this out. I've since changed the patch to use the VID#A voltages which is more conservative (assuming that all of them will run at the higher voltage okay which according to the upper voltage rating of 1.6 volts might be

On re-looking at the spec and the voltage tolerance tables in particular I realize my approach is not valid. A VID#B can be driven at VID#A voltages but there is no voltage in common for some frequencies between all VID# variants.

Quoted 2 lines

okay). It would of course be preferrable to work out the the type VID#A,B,C,D via software - not sure if this is possible.

Perhaps the VID# variant can be found via MSRs - if not the static tables will not be workable and the ACPI approach will have to be the sole method.

~mc