Skip to contentSkip to conversation

AMD Elan SC520 cpufreq driver

PATCH In review Sean Young 4 participants 8 messages Mar 29, 2005 – Apr 9, 2005

Subsystems (2)
lore
Share & tools
lore

Sean Young

author
#0 lore raw

PATCH 1/1 AMD Elan SC520 cpufreq driver

Here is a cpufreq driver for the AMD Elan SC520, diff against 2.6.12-rc1.

Sean

home/sean/tiger/linux-2.6.9/Documentation/cpu-freq/user-guide.txt renamed from Documentation/cpu-freq/user-guide.txt +1 -0
diff -uprN linux-2.6.9/Documentation/cpu-freq/user-guide.txt /home/sean/tiger/linux-2.6.9/Documentation/cpu-freq/user-guide.txt
@@ -53,6 +53,7 @@ ARM-SA1110
 The following processors for the x86 architecture are supported by cpufreq:
 
 AMD Elan - SC400, SC410
+AMD Elan - SC520
 AMD mobile K6-2+
 AMD mobile K6-3+
 AMD mobile Duron
home/sean/tiger/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Kconfig renamed from arch/i386/kernel/cpu/cpufreq/Kconfig +13 -1
diff -uprN linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Kconfig /home/sean/tiger/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Kconfig
@@ -23,7 +23,7 @@ config X86_ACPI_CPUFREQ
 	  If in doubt, say N.
 
 config ELAN_CPUFREQ
-	tristate "AMD Elan"
+	tristate "AMD Elan SC400 and SC410"
 	select CPU_FREQ_TABLE
 	depends on X86_ELAN
 	---help---
@@ -38,6 +38,18 @@ config ELAN_CPUFREQ
 
 	  If in doubt, say N.
 
+config SC520_CPUFREQ
+	tristate "AMD Elan SC520"
+	select CPU_FREQ_TABLE 
+	depends on X86_ELAN
+	---help---
+	  This adds the CPUFreq driver for AMD Elan SC520 processor.
+
+	  For details, take a look at <file:Documentation/cpu-freq/>.
+
+	  If in doubt, say N.
+
+
 config X86_POWERNOW_K6
 	tristate "AMD Mobile K6-2/K6-3 PowerNow!"
 	select CPU_FREQ_TABLE
home/sean/tiger/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Makefile renamed from arch/i386/kernel/cpu/cpufreq/Makefile +1 -0
diff -uprN linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Makefile /home/sean/tiger/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_X86_POWERNOW_K7)		+= powern
 obj-$(CONFIG_X86_POWERNOW_K8)		+= powernow-k8.o
 obj-$(CONFIG_X86_LONGHAUL)		+= longhaul.o
 obj-$(CONFIG_ELAN_CPUFREQ)		+= elanfreq.o
+obj-$(CONFIG_SC520_CPUFREQ)		+= sc520_freq.o
 obj-$(CONFIG_X86_LONGRUN)		+= longrun.o  
 obj-$(CONFIG_X86_GX_SUSPMOD)		+= gx-suspmod.o
 obj-$(CONFIG_X86_SPEEDSTEP_ICH)		+= speedstep-ich.o
home/sean/tiger/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c renamed from arch/i386/kernel/cpu/cpufreq/sc520_freq.c +186 -0

186 lines not on this page · raw message

#1 lore raw

Sean Young a écrit :

Quoted 2 lines

Here is a cpufreq driver for the AMD Elan SC520, diff against 2.6.12-rc1.

[snipped]

Quoted 1 line

+ * 2005-03-30: - initial revision

        ^^^^^^^^^^

Well, not that I'm really concerned, but just by curiosity, I've seen this patch in the cpu-freq snapshot since 2005-03-23, how does it happen that you submit it only now, and with a release date of tomorrow? Timewrapping?

Eric

author
#2 lore raw
Quoted 10 lines · Eric Piel
Quoted 2 lines · Sean Young

Here is a cpufreq driver for the AMD Elan SC520, diff against 2.6.12-rc1.

[snipped]

Quoted 1 line

+ * 2005-03-30: - initial revision

        ^^^^^^^^^^

Well, not that I'm really concerned, but just by curiosity, I've seen this patch in the cpu-freq snapshot since 2005-03-23, how does it happen that you submit it only now, and with a release date of tomorrow? Timewrapping?

Oops.

I sent it to Dave Jones a week ago, but didn't realize it made it into the cpu-freq snapshots. On top of that I thought it was already the 30st when it wasn't yet.

Sorry about the noise.

Sean

#3 lore raw
In reply to Sean Young

Hi,

Quoted 1 line

+#include <linux/slab.h>

What do you need slab.h for?

home/sean/tiger/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c line 66

Quoted 2 lines
home/sean/tiger/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c renamed from arch/i386/kernel/cpu/cpufreq/sc520_freq.c +2 -0
+	printk(KERN_INFO "sc520_freq: attempting to set frequency to %i kHz\n",
+			sc520_freq_table[state].frequency);

Please change this to a dprintk and use the cpufreq_debug infrastructure for that -- users who want to use dynamic frequency scaling don't want to have their dmesg flooded with printk's :)

home/sean/tiger/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c line 114

Quoted 1 line
home/sean/tiger/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c renamed from arch/i386/kernel/cpu/cpufreq/sc520_freq.c +1 -0
+	policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;

Do you know how long a transition takes and for how long no other transition may be done?

Quoted 1 line

+ cpufreq_frequency_table_get_attr(sc520_freq_table, policy->cpu);

broken indenting

home/sean/tiger/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c line 159

Quoted 4 lines
home/sean/tiger/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c renamed from arch/i386/kernel/cpu/cpufreq/sc520_freq.c +4 -0
+	/* Test if we have the right hardware */
+	if (c->x86_vendor != X86_VENDOR_AMD ||
+		c->x86 != 4 || c->x86_model != 9) {
+		printk(KERN_INFO "sc520_freq: error: no Elan SC520 processor found!\n");

please do only a dprintk here as well, and I think a tab is missing, too.

Nice work :)

Thanks,
Dominik

author
#4 lore raw
Quoted 3 lines · Dominik Brodowski
Quoted 1 line

+#include <linux/slab.h>

What do you need slab.h for?

-snip-

Thanks for the input. Here is a patch against the latest snapshot (cpufreq-2005-04-03.diff) which fixes the issues.

Sean

tmp/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Kconfig renamed from arch/i386/kernel/cpu/cpufreq/Kconfig +1 -1
diff -urpN linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Kconfig /tmp/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Kconfig
@@ -23,7 +23,7 @@ config X86_ACPI_CPUFREQ
 	  If in doubt, say N.
 
 config ELAN_CPUFREQ
-	tristate "AMD Elan SC500 and SC410"
+	tristate "AMD Elan SC400 and SC410"
 	select CPU_FREQ_TABLE
 	depends on X86_ELAN
 	---help---
tmp/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c renamed from arch/i386/kernel/cpu/cpufreq/sc520_freq.c +18 -11
diff -urpN linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c /tmp/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c
@@ -17,7 +17,6 @@
 #include <linux/module.h>
 #include <linux/init.h>
 
-#include <linux/slab.h>
 #include <linux/delay.h>
 #include <linux/cpufreq.h>
 
@@ -25,11 +24,13 @@
 #include <asm/timex.h>
 #include <asm/io.h>
 
-#define MMCR_BASE       0xfffef000      /* The default base address */
+#define MMCR_BASE	0xfffef000	/* The default base address */
 #define OFFS_CPUCTL	0x2   /* CPU Control Register */
 
 static __u8 __iomem *cpuctl;
 
+#define dprintk(msg...) cpufreq_debug_printk(CPUFREQ_DEBUG_DRIVER, "sc520_freq", msg)
+
 static struct cpufreq_frequency_table sc520_freq_table[] = {
 	{0x01,	100000},
 	{0x02,	133000},
@@ -53,7 +54,8 @@ static unsigned int sc520_freq_get_cpu_f
 static void sc520_freq_set_cpu_state (unsigned int state)
 {
 
-	struct cpufreq_freqs    freqs;
+	struct cpufreq_freqs	freqs;
+	u8 clockspeed_reg;
 
 	freqs.old = sc520_freq_get_cpu_frequency(0);
 	freqs.new = sc520_freq_table[state].frequency;
@@ -61,10 +63,15 @@ static void sc520_freq_set_cpu_state (un
 
 	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
 
-	printk(KERN_INFO "sc520_freq: attempting to set frequency to %i kHz\n",
+	dprintk("attempting to set frequency to %i kHz\n",
 			sc520_freq_table[state].frequency);
 
-	*cpuctl = sc520_freq_table[state].index;
+	local_irq_disable();
+
+	clockspeed_reg = *cpuctl & ~0x03;
+	*cpuctl = clockspeed_reg | sc520_freq_table[state].index;
+
+	local_irq_enable();
 
 	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
 };
@@ -105,14 +112,14 @@ static int sc520_freq_cpu_init(struct cp
 
 	/* cpuinfo and default policy values */
 	policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
-	policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
+	policy->cpuinfo.transition_latency = 1000; /* 1ms */
 	policy->cur = sc520_freq_get_cpu_frequency(0);
 
 	result = cpufreq_frequency_table_cpuinfo(policy, sc520_freq_table);
 	if (result)
 		return (result);
 
-        cpufreq_frequency_table_get_attr(sc520_freq_table, policy->cpu);
+	cpufreq_frequency_table_get_attr(sc520_freq_table, policy->cpu);
 
 	return 0;
 }
@@ -148,10 +155,10 @@ static int __init sc520_freq_init(void)
 	struct cpuinfo_x86 *c = cpu_data;
 
 	/* Test if we have the right hardware */
-	if (c->x86_vendor != X86_VENDOR_AMD ||
-		c->x86 != 4 || c->x86_model != 9) {
-		printk(KERN_INFO "sc520_freq: error: no Elan SC520 processor found!\n");
-                return -ENODEV;
+	if(c->x86_vendor != X86_VENDOR_AMD ||
+				c->x86 != 4 || c->x86_model != 9) {
+		dprintk("no Elan SC520 processor found!\n");
+		return -ENODEV;
 	}
 	cpuctl = ioremap((unsigned long)(MMCR_BASE + OFFS_CPUCTL), 1);
 	if(!cpuctl) {
#5 lore raw

tmp/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c static int sc520_freq_cpu_init(struct cp · line 115

Quoted 2 lines · Sean Young
tmp/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c renamed from arch/i386/kernel/cpu/cpufreq/sc520_freq.c +1 -1
-	policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
+	policy->cpuinfo.transition_latency = 1000; /* 1ms */

transition_latency is expressed in nanoseconds, so it should be 1000000.
I guess the confusion comes from cpufreq.h, where there are two comments about it, one saying it's nanosecond, another one (older) saying it's microseconds. Dominik, maybe this typo should be fixed, do you want me to send a patch?

Eric

#6 lore raw

PATCH 1/1 cpufreq: fix latency comment in cpufreq.h [Was: Re: [PATCH] AMD Elan SC520 cpufreq driver]

Quoted 9 lines · Eric Piel

Review

Quoted 2 lines · Sean Young
(quoted diff) +1 -1
-	policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
+	policy->cpuinfo.transition_latency = 1000; /* 1ms */

transition_latency is expressed in nanoseconds, so it should be 1000000. I guess the confusion comes from cpufreq.h, where there are two comments about it, one saying it's nanosecond, another one (older) saying it's microseconds. Dominik, maybe this typo should be fixed, do you want me to send a patch?

Nice catch.

Fix up comment in cpufreq.h stating transition latency should be passed in microseconds -- it was decided long ago to switch to nanoseconds.

include/linux/cpufreq.h +1 -1
Index: 2.6.12-rc2/include/linux/cpufreq.h
===================================================================
@@ -49,7 +49,7 @@
 /* Frequency values here are CPU kHz so that hardware which doesn't run 
  * with some frequencies can complain without having to guess what per 
  * cent / per mille means. 
- * Maximum transition latency is in microseconds - if it's unknown,
+ * Maximum transition latency is in nanoseconds - if it's unknown,
  * CPUFREQ_ETERNAL shall be used.
  */
#7 lore raw

Re: [PATCH] cpufreq: fix latency comment in cpufreq.h [Was: Re: [PATCH] AMD Elan SC520 cpufreq driver]

Quoted 11 lines · Dominik Brodowski
Quoted 9 lines · Eric Piel

Review

Quoted 2 lines · Sean Young
(quoted diff) +1 -1
-	policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
+	policy->cpuinfo.transition_latency = 1000; /* 1ms */

transition_latency is expressed in nanoseconds, so it should be 1000000. I guess the confusion comes from cpufreq.h, where there are two comments about it, one saying it's nanosecond, another one (older) saying it's microseconds. Dominik, maybe this typo should be fixed, do you want me to send a patch?

Quoted 7 lines

Nice catch.

Fix up comment in cpufreq.h stating transition latency should be passed in microseconds -- it was decided long ago to switch to nanoseconds.

With Linus not merging anything right now due to the bitkeeper fiasco, I'm just sitting on a bunch of stuff.
I'm not asking you (and others) not to send stuff, but be prepared to bomb me again once Linus has figured out how things are going to work.

Cheers,

Dave