ppc64: Add cpufreq support for SMU based G5

iMac G5 and latest single CPU desktop G5 (SMU based machines) have a 970FX DD3 CPU that supports frequency & vooltage switching. This patch adds support for simple dual frequency switch. It is required for the upcoming thermal control patch for these machines.

Index: linux-work/arch/ppc64/kernel/misc.S
===================================================================
@@ -616,7 +616,7 @@
 	isync
 	blr
 
-	/*
+/*
  * Do an IO access in real mode
  */
 _GLOBAL(real_writeb)

@@ -649,6 +649,76 @@
 #endif /* defined(CONFIG_PPC_PMAC) || defined(CONFIG_PPC_MAPLE) */
 
 /*
+ * SCOM access functions for 970 (FX only for now)
+ *
+ * unsigned long scom970_read(unsigned int address);
+ * void scom970_write(unsigned int address, unsigned long value);
+ *
+ * The address passed in is the 24 bits register address. This code
+ * is 970 specific and will not check the status bits, so you should
+ * know what you are doing.
+ */
+_GLOBAL(scom970_read)
+	/* interrupts off */
+	mfmsr	r4
+	ori	r0,r4,MSR_EE
+	xori	r0,r0,MSR_EE
+	mtmsrd	r0,1
+
+	/* rotate 24 bits SCOM address 8 bits left and mask out it's low 8 bits
+	 * (including parity). On current CPUs they must be 0'd,
+	 * and finally or in RW bit
+	 */
+	rlwinm	r3,r3,8,0,15
+	ori	r3,r3,0x8000
+
+	/* do the actual scom read */
+	sync
+	mtspr	SPRN_SCOMC,r3
+	isync
+	mfspr	r3,SPRN_SCOMD
+	isync
+	mfspr	r0,SPRN_SCOMC
+	isync
+
+	/* XXX:	fixup result on some buggy 970's (ouch ! we lost a bit, bah
+	 * that's the best we can do). Not implemented yet as we don't use
+	 * the scom on any of the bogus CPUs yet, but may have to be done
+	 * ultimately
+	 */
+
+	/* restore interrupts */
+	mtmsrd	r4,1
+	blr
+
+
+_GLOBAL(scom970_write)
+	/* interrupts off */
+	mfmsr	r5
+	ori	r0,r5,MSR_EE
+	xori	r0,r0,MSR_EE
+	mtmsrd	r0,1
+
+	/* rotate 24 bits SCOM address 8 bits left and mask out it's low 8 bits
+	 * (including parity). On current CPUs they must be 0'd.
+	 */
+
+	rlwinm	r3,r3,8,0,15
+
+	sync
+	mtspr	SPRN_SCOMD,r4      /* write data */
+	isync
+	mtspr	SPRN_SCOMC,r3      /* write command */
+	isync
+	mfspr	3,SPRN_SCOMC
+	isync
+
+	/* restore interrupts */
+	mtmsrd	r5,1
+	blr
+
+
+/*
  * Create a kernel thread
  *   kernel_thread(fn, arg, flags)
  */

Index: linux-work/include/asm-ppc64/processor.h
===================================================================
@@ -177,6 +177,9 @@
 #define SPRN_CTRLT	0x098
 #define   CTRL_RUNLATCH	0x1
 
+#define SPRN_SCOMC	0x114
+#define SPRN_SCOMD	0x115
+
 /* Performance monitor SPRs */
 #define SPRN_SIAR	780
 #define SPRN_SDAR	781

@@ -536,6 +539,9 @@
 	}
 }
 
+extern unsigned long scom970_read(unsigned int address);
+extern void scom970_write(unsigned int address, unsigned long value);
+
 #endif /* __KERNEL__ */
 
 #endif /* __ASSEMBLY__ */

Index: linux-work/arch/ppc64/Kconfig
===================================================================
@@ -159,6 +159,17 @@
 	  support.  As of this writing the exact hardware interface is
 	  strongly in flux, so no good recommendation can be made.
 
+source "drivers/cpufreq/Kconfig"
+
+config CPU_FREQ_PMAC
+	bool "Support for Apple G5"
+	depends on CPU_FREQ && PPC_PMAC64
+	select CPU_FREQ_TABLE
+	help
+	  This adds support for frequency switching on some Apple G5
+          machine. This is currently very experimental and works only
+          on some iMac G5.
+
 config IBMVIO
 	depends on PPC_PSERIES || PPC_ISERIES
 	bool

Index: linux-work/arch/ppc64/kernel/Makefile
===================================================================
@@ -60,6 +60,7 @@
 obj-$(CONFIG_PPC_PMAC)		+= pmac_setup.o pmac_feature.o pmac_pci.o \
 				   pmac_time.o pmac_nvram.o pmac_low_i2c.o \
 				   udbg_scc.o
+obj-$(CONFIG_CPU_FREQ_PMAC)	+= pmac_cpufreq.o
 
 obj-$(CONFIG_PPC_MAPLE)		+= maple_setup.o maple_pci.o maple_time.o \
 				   udbg_16550.o

Index: linux-work/drivers/macintosh/smu.c
===================================================================
@@ -843,6 +843,18 @@
 	return 0;
 }
 
+struct smu_sdbp_header *smu_get_sdb_partition(int id, unsigned int *size)
+{
+	char pname[32];
+
+	if (!smu)
+		return NULL;
+
+	sprintf(pname, "sdb-partition-%02x", id);
+	return (struct smu_sdbp_header *)get_property(smu->of_node,
+						      pname, size);
+}
+EXPORT_SYMBOL(smu_get_sdb_partition);
 
 
 /*

Hello,

I know only very little about cpufreq, probably you could post your patch to the cpufreq mailing list for better review : [email protected] (you may have to subscride before posting, don't remember).

For what have seen, your patch looks pretty good in general. However, is this kind of CPU only in one CPU machines? Your patch doesn't seem support SMP, then it's probably safer to prevent compilation on an SMP kernel in the Makefile? Or you can add SMP support (shouldn't be so hard in theory, but with no hardware to test it might be pointless), you can have a look at other drivers that support it, like in arch/i386/kernel/cpu/cpufreq/p4-clockmod.c .

Just a little more thing, concerning:
+ policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
Could you have a look if you could find the real info about how long it takes to change the speed (put the worse case latency)? Maybe the info can be found in some parts of the ROM you read? I don't know if conservative or ondemand governors are supposed to be able to mix with your code (especially wrt Windfarm) but not putting this info will prevent them from ever working...

Cheers,
Eric

I should probably have CC'd it... oh well, this isn't terribly important at this point but I'll do if I post a new release. It's powermac specific anyway.

So far, only single CPU machines shipped with an SMU.

There are several problems (and that leads to problems in the cpufreq core too btw). The problem with the cpufreq core is that it disables adjusting of loops_per_jiffies when CONFIG_SMP is set. That can lead to pretty disastrous results when running an SMP kernel on a laptop... Fortunately, the driver provided by this patch doesn't need it as ppc64 has constants loops_per_jiffies (it uses the HW timebase which doesn't change frequency).

The other problem is that the 970FX "PowerTune" mecanism will actually broadcast messages to the bus that sync all CPUs to the same speed. That is, all CPUs in the machine will always change frequency simultaneously, thus the whole SMP stuff doesn't make that much sense, and I'm not sure how to "inform" the cpufreq core of that fact (that changing one CPU actually triggered a change of all of them).

But as I wrote earlier, there is currently no PowerMac SMP machine that has an SMU chip and a 970FX to which this driver would apply.

Finally, as for preventing build with CONFIG_SMP, I think distros would kill me as I don't know any of them who intends to ship a G5 kernel with CONFIG_SMP disabled :)

I didn't find. Apple didn't bother putting it in the OF device-tree afaik, and while it might be in one of the undocumented SMU data partitions, I have no way to know. The problem isn't the frequency switch per-se which is extremely fast (and I could know), but the voltage switch that goes with it. I suppose I could measure and put an overestimated value in there, but that isn't critical for now. userland powernowd & friends work fine and I need the reduced frequency mostly for the thermal control driver so it can clamp it down when the CPU overtemps.

Which is what I want for now, until I find out more about how well I can make them to work with those machines :)

Let's call that a "conservative" approach ;)

Ben.