Skip to contentSkip to conversation

Add Dothan frequency tables for speedstep

PATCH In review Randy Dunlap 4 participants 5 messages Jul 3, 2006 – Jul 4, 2006

lore
Share & tools
lore

Randy Dunlap

author
#0 lore raw

PATCH 1/1 Add Dothan frequency tables for speedstep

Patch to Add Dothan frequency tables for speedstep.

Does this conflict with other Dothan handling?

patch location:
http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=1db7baafb2d8f9d1356802bb112826bd866221b4

---
 arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c |   89 ++++++++++++++++++++++
 1 file changed, 89 insertions(+)
arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c +89 -0
@@ -196,6 +196,82 @@ static struct cpufreq_frequency_table ba
 	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)	\

@@ -206,6 +282,13 @@ static struct cpufreq_frequency_table ba
 }
 #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[] =

@@ -219,6 +302,11 @@ static struct cpu_model models[] =
 	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 },

@@ -231,6 +319,7 @@ static struct cpu_model models[] =
 };
 #undef _BANIAS
 #undef BANIAS
+#undef DOTHAN
 
 static int centrino_cpu_init_table(struct cpufreq_policy *policy)
 {
#1 lore raw
Quoted 5 lines · Randy Dunlap

Patch to Add Dothan frequency tables for speedstep.

Does this conflict with other Dothan handling?

patch location:

as discussed on the power management summit: this is the wrong approach.

The BIOS gives you these tables. The reference bios has all of them, but if a testing failure (for example due to voltage regulator limits or cooling limits) a specific machine can't do a certain state, the bios of that machine drops that state. It's a BAD IDEA to then add that state back via the back door!

It's not as if the bios people remove random states... that's work. They only change such things if they really really have to...

#2 lore raw
In reply to Randy Dunlap
Quoted 2 lines · Randy Dunlap

Patch to Add Dothan frequency tables for speedstep.

Already NAK'd at least a half dozen times.

Yes it works great if your system is wired up to use VID#C, but what if it isn't ? It's got a 1 in 4 chance of working, and what it'll do in the other 3 cases is anyones guess.

As there's no way to tell which VID is in use, the only option on these systems is to use either the acpi mode of this driver, or acpi-cpufreq instead.

Dave

Signature · 1 line
http://www.codemonkey.org.uk
#3 lore raw
Quoted 7 lines · Dave Jones

Yes it works great if your system is wired up to use VID#C, but what if it isn't ? It's got a 1 in 4 chance of working, and what it'll do in the other 3 cases is anyones guess.

As there's no way to tell which VID is in use, the only option on these systems is to use either the acpi mode of this driver, or acpi-cpufreq instead.

Is this the same reason why this patch wasn't accepted in mainline?
http://fabrice.bellamy.club.fr/bdz.undervolt.2005.10.22.a.patch

Signature · 1 line
Lukáš Hejtmánek
#4 lore raw
Quoted 11 lines · Lukas Hejtmanek
Quoted 7 lines · Dave Jones

Yes it works great if your system is wired up to use VID#C, but what if it isn't ? It's got a 1 in 4 chance of working, and what it'll do in the other 3 cases is anyones guess.

As there's no way to tell which VID is in use, the only option on these systems is to use either the acpi mode of this driver, or acpi-cpufreq instead.

Is this the same reason why this patch wasn't accepted in mainline?
http://fabrice.bellamy.club.fr/bdz.undervolt.2005.10.22.a.patch

No. That's was rejected due to the
"don't give people semi-automatic weapons to shoot their feet off with" principle.

The problem with patches like this, and the "let cpufreq overclock" patches, and the "let me input my own voltage/freq pairs via sysfs" patches is some lucky soul (yours truly) gets to deal with the fallout when peoples
computers crash after trying patches like this. My inbox has more than enough
problems for me to dig into, without introducing more problems that are frankly, undebuggable.

Dave

Signature · 1 line
http://www.codemonkey.org.uk