[PATCH] AMD Elan SC520 cpufreq driver

[PATCH] AMD Elan SC520 cpufreq driver

[Sean Young]

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

Signed-off-by: Sean Young <sean@mess.org>


Sean


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
--- linux-2.6.9/Documentation/cpu-freq/user-guide.txt	2005-03-29 23:20:38.380542376 +0200
+++ /home/sean/tiger/linux-2.6.9/Documentation/cpu-freq/user-guide.txt	2005-03-20 14:58:55.740062792 +0100
@@ -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
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
--- linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Kconfig	2005-03-29 23:22:01.349929112 +0200
+++ /home/sean/tiger/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Kconfig	2005-03-29 23:30:30.027598352 +0200
@@ -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
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
--- linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Makefile	2005-03-29 23:20:38.871467744 +0200
+++ /home/sean/tiger/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Makefile	2005-03-19 19:27:16.847151960 +0100
@@ -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
diff -uprN linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c /home/sean/tiger/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c
--- linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c	1970-01-01 01:00:00.000000000 +0100
+++ /home/sean/tiger/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c	2005-03-29 20:59:06.861449496 +0200
@@ -0,0 +1,186 @@
+/*
+ * 	sc520_freq.c: cpufreq driver for the AMD Elan SC520
+ *
+ * 	Copyright (C) 2005 Sean Young <sean@mess.org>
+ *
+ *	This program is free software; you can redistribute it and/or
+ *	modify it under the terms of the GNU General Public License
+ *	as published by the Free Software Foundation; either version
+ *	2 of the License, or (at your option) any later version. 
+ *
+ *	Based on elanfreq.c
+ *
+ *	2005-03-30: - initial revision 
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+
+#include <linux/slab.h>
+#include <linux/delay.h>
+#include <linux/cpufreq.h>
+
+#include <asm/msr.h>
+#include <asm/timex.h>
+#include <asm/io.h>
+
+#define MMCR_BASE       0xfffef000      /* The default base address */
+#define OFFS_CPUCTL   	0x2   /* CPU Control Register */
+
+static __u8 __iomem *cpuctl;
+
+static struct cpufreq_frequency_table sc520_freq_table[] = {
+	{0x01,	100000},
+	{0x02,	133000},
+	{0,	CPUFREQ_TABLE_END},
+};
+
+static unsigned int sc520_freq_get_cpu_frequency(unsigned int cpu)
+{
+	u8 clockspeed_reg = *cpuctl;
+
+	switch (clockspeed_reg & 0x03) {
+	default:
+		printk(KERN_ERR "sc520_freq: error: cpuctl register has unexpected value %02x\n", clockspeed_reg);
+	case 0x01:
+		return 100000;
+	case 0x02:
+		return 133000;
+	}
+}
+
+static void sc520_freq_set_cpu_state (unsigned int state) 
+{
+
+	struct cpufreq_freqs    freqs;
+	u8 clockspeed_reg;
+
+	freqs.old = sc520_freq_get_cpu_frequency(0);
+	freqs.new = sc520_freq_table[state].frequency;
+	freqs.cpu = 0; /* AMD Elan is UP */
+	
+	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+
+	printk(KERN_INFO "sc520_freq: attempting to set frequency to %i kHz\n",
+			sc520_freq_table[state].frequency);
+
+	local_irq_disable();
+
+	clockspeed_reg = *cpuctl & ~0x03;
+	*cpuctl = sc520_freq_table[state].index | clockspeed_reg;
+
+	local_irq_enable();
+
+	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+};
+
+static int sc520_freq_verify (struct cpufreq_policy *policy)
+{
+	return cpufreq_frequency_table_verify(policy, &sc520_freq_table[0]);
+}
+
+static int sc520_freq_target (struct cpufreq_policy *policy, 
+			    unsigned int target_freq, 
+			    unsigned int relation)
+{
+	unsigned int newstate = 0;
+
+	if (cpufreq_frequency_table_target(policy, sc520_freq_table, target_freq, relation, &newstate))
+		return -EINVAL;
+
+	sc520_freq_set_cpu_state(newstate);
+
+	return 0;
+}
+
+
+/*
+ *	Module init and exit code
+ */
+
+static int sc520_freq_cpu_init(struct cpufreq_policy *policy)
+{
+	struct cpuinfo_x86 *c = cpu_data;
+	int result;
+
+	/* capability check */
+	if (c->x86_vendor != X86_VENDOR_AMD ||
+	    c->x86 != 4 || c->x86_model != 9)
+		return -ENODEV;
+
+	/* cpuinfo and default policy values */
+	policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
+	policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
+	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);
+
+	return 0;
+}
+
+
+static int sc520_freq_cpu_exit(struct cpufreq_policy *policy)
+{
+	cpufreq_frequency_table_put_attr(policy->cpu);
+	return 0;
+}
+
+
+static struct freq_attr* sc520_freq_attr[] = {
+	&cpufreq_freq_attr_scaling_available_freqs,
+	NULL,
+};
+
+
+static struct cpufreq_driver sc520_freq_driver = {
+	.get	 	= sc520_freq_get_cpu_frequency,
+	.verify 	= sc520_freq_verify,
+	.target 	= sc520_freq_target,
+	.init		= sc520_freq_cpu_init,
+	.exit		= sc520_freq_cpu_exit,
+	.name		= "sc520_freq",
+	.owner		= THIS_MODULE,
+	.attr		= sc520_freq_attr,
+};
+
+
+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;
+	}
+	cpuctl = ioremap((unsigned long)(MMCR_BASE + OFFS_CPUCTL), 1);
+	if(!cpuctl) {
+		printk(KERN_ERR "sc520_freq: error: failed to remap memory\n");
+		return -ENOMEM;
+	}
+
+	
+	return cpufreq_register_driver(&sc520_freq_driver);
+}
+
+
+static void __exit sc520_freq_exit(void) 
+{
+	cpufreq_unregister_driver(&sc520_freq_driver);
+	iounmap(cpuctl);
+}
+
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Sean Young <sean@mess.org>");
+MODULE_DESCRIPTION("cpufreq driver for AMD's Elan sc520 CPU");
+
+module_init(sc520_freq_init);
+module_exit(sc520_freq_exit);
+

Re: [PATCH] AMD Elan SC520 cpufreq driver

[Eric Piel]

Sean Young a écrit :
> Here is a cpufreq driver for the AMD Elan SC520, diff against
> 2.6.12-rc1.
[snipped]
> + *	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

Re: [PATCH] AMD Elan SC520 cpufreq driver

[Dominik Brodowski]

Hi,

> +#include <linux/slab.h>

What do you need slab.h for?

> +	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 :)

> +	policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;

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

> +        cpufreq_frequency_table_get_attr(sc520_freq_table, policy->cpu);

broken indenting

> +	/* 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

Re: [PATCH] AMD Elan SC520 cpufreq driver

[Sean Young]

On Tue, Mar 29, 2005 at 11:50:29PM +0200, Eric Piel wrote:
> Sean Young a écrit :
> >Here is a cpufreq driver for the AMD Elan SC520, diff against
> >2.6.12-rc1.
> [snipped]
> >+ *	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

Re: [PATCH] AMD Elan SC520 cpufreq driver

[Sean Young]

On Wed, Mar 30, 2005 at 12:04:32AM +0200, Dominik Brodowski wrote:
> > +#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

diff -urpN linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Kconfig /tmp/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Kconfig
--- linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Kconfig	2005-04-03 18:21:00.652590000 +0200
+++ /tmp/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/Kconfig	2005-04-03 17:52:41.949832072 +0200
@@ -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---
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
--- linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c	2005-04-03 18:21:00.709581336 +0200
+++ /tmp/linux-2.6.9/arch/i386/kernel/cpu/cpufreq/sc520_freq.c	2005-04-03 17:52:58.789272088 +0200
@@ -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) {

Re: [PATCH] AMD Elan SC520 cpufreq driver

[Eric Piel]

Sean Young a écrit :
> -	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

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

[Dominik Brodowski]

On Mon, Apr 04, 2005 at 01:53:04AM +0200, Eric Piel wrote:
> Sean Young a écrit :
> >-	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.

Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>

Index: 2.6.12-rc2/include/linux/cpufreq.h
===================================================================
--- 2.6.12-rc2.orig/include/linux/cpufreq.h	2005-03-02 18:23:48.000000000 +0100
+++ 2.6.12-rc2/include/linux/cpufreq.h	2005-04-09 22:19:04.000000000 +0200
@@ -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.
  */

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

[Dave Jones]

On Sat, Apr 09, 2005 at 10:20:55PM +0200, Dominik Brodowski wrote:
 > On Mon, Apr 04, 2005 at 01:53:04AM +0200, Eric Piel wrote:
 > > Sean Young a écrit :
 > > >-	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.
 > 
 > Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>

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