[PATCH] - Initial dothan speedstep support

[PATCH] - Initial dothan speedstep support

[Michael Clark]

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

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


[-- Attachment #2: cupfreq-speedstep-dothan-1.patch --]
[-- Type: text/x-patch, Size: 3565 bytes --]

--- ./arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c.bk-patched	2004-08-06 11:26:05.000000000 +0800
+++ ./arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c	2004-08-06 12:42:32.000000000 +0800
@@ -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

Re: [PATCH] - Initial dothan speedstep support

[Michael Clark]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

On 08/06/04 13:03, Michael Clark wrote:
> 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

[-- Attachment #2: cpufreq-speedstep-dothan-3-2.6.8-rc3-mm1.patch --]
[-- Type: text/x-patch, Size: 3706 bytes --]

--- linux-2.6.8-rc3-mm1/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c.orig	2004-08-06 18:42:15.000000000 +0800
+++ linux-2.6.8-rc3-mm1/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c	2004-08-06 18:44:28.000000000 +0800
@@ -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)
 {

Re: [PATCH] - Initial dothan speedstep support

[Dave Jones]

On Fri, Aug 06, 2004 at 07:04:41PM +0800, Michael Clark wrote:
 > On 08/06/04 13:03, Michael Clark wrote:
 > >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

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

Re: [PATCH] - Initial dothan speedstep support

[Michael Clark]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

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

[-- Attachment #2: cpufreq-speedstep-dothan-VidA.patch --]
[-- Type: application/octect-stream, Size: 1011 bytes --]

Re: [PATCH] - Initial dothan speedstep support

[Michael Clark]

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

Re: [PATCH] - Initial dothan speedstep support

[Pavel Machek]

Hi!

> 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).

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
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: [PATCH] - Initial dothan speedstep support

[Clark, Michael]

> Hi!
>
>> 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).
>
> 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

Re: [PATCH] - Initial dothan speedstep support

[Michael Clark]

On 08/22/04 15:31, Clark, Michael wrote:
>>Hi!
>>
>>
>>>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).
>>
>>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

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.

> 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