LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH -next-20080709] fixup stop_machine use cpu mask vs ftrace
From: Rusty Russell @ 2008-07-11  6:43 UTC (permalink / raw)
  To: Milton Miller; +Cc: linuxppc-dev, linux-next, Ingo Molnar, linux-kernel
In-Reply-To: <for-27-patch0-1@bga.com>

On Friday 11 July 2008 07:07:57 Milton Miller wrote:
> Hi Rusty, Ingo.
>
> Rusty's patch [PATCH 3/3] stop_machine: use cpu mask rather than magic
> numbers didn't find kernel/trace/ftrace.c in -next, causing an immediate
> almost NULL pointer dereference in ftrace_dynamic_init.

Yes, I'm switching the patches around, so it does the transition correctly. 
Introduces a new stop_machine() fn with the new interface and deprecates the 
old stop_machine_run().  We can remove stop_machine_run() after everyone is 
switched.

Thanks,
Rusty.

^ permalink raw reply

* Re: [PATCH] [V2] powerpc: Xilinx: PS2: driver updates based on review
From: Peter Korsgaard @ 2008-07-11  6:35 UTC (permalink / raw)
  To: John Linn; +Cc: Sadanand, dmitry.torokhov, linuxppc-dev, linux-input
In-Reply-To: <20080710193451.ED2B51D18066@mail97-dub.bigfish.com>

>>>>> "John" == John Linn <john.linn@xilinx.com> writes:

 John> Review comments were incorporated to improve the driver.
 John> 1. Some data was eliminated that was not needed.
 John> 2. Renaming of variables for clarity.
 John> 3. Removed unneeded type casting.
 John> 4. Changed to use dev_err rather than other I/O.
 John> 5. Merged together some functions.
 John> 6. Added kerneldoc format to functions.

 John> Signed-off-by: Sadanand <sadanan@xilinx.com>
 John> Signed-off-by: John Linn <john.linn@xilinx.com>

Acked-by: Peter Korsgaard <jacmet@sunsite.dk>

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* [PATCH] powerpc: Add VSX load/store alignment exception handler
From: Michael Neuling @ 2008-07-11  6:31 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, paulus
In-Reply-To: <18384.1215757752@neuling.org>

VSX loads and stores will take an alignment exception when the address
is not on a 4 byte boundary.  

This add support for these alignment exceptions and will emulate the
requested load or store.  

Signed-off-by: Michael Neuling <mikey@neuling.org>
---
benh: for your 2.6.27 tree

 arch/powerpc/kernel/align.c |   58 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 57 insertions(+), 1 deletion(-)

Index: linux-2.6-ozlabs/arch/powerpc/kernel/align.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/align.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/align.c
@@ -48,6 +48,7 @@ struct aligninfo {
 #define HARD	0x80	/* string, stwcx. */
 #define E4	0x40	/* SPE endianness is word */
 #define E8	0x80	/* SPE endianness is double word */
+#define SPLT	0x80	/* VSX SPLAT load */
 
 /* DSISR bits reported for a DCBZ instruction: */
 #define DCBZ	0x5f	/* 8xx/82xx dcbz faults when cache not enabled */
@@ -637,6 +638,36 @@ static int emulate_spe(struct pt_regs *r
 }
 #endif /* CONFIG_SPE */
 
+#ifdef CONFIG_VSX
+/*
+ * Emulate VSX instructions...
+ */
+static int emulate_vsx(unsigned char __user *addr, unsigned int reg,
+		       unsigned int areg, struct pt_regs *regs,
+		       unsigned int flags, unsigned int length)
+{
+	char *ptr = (char *) &current->thread.TS_FPR(reg);
+	int ret;
+
+	flush_vsx_to_thread(current);
+
+	if (flags & ST)
+		ret = __copy_to_user(addr, ptr, length);
+        else {
+		if (flags & SPLT){
+			ret = __copy_from_user(ptr, addr, length);
+			ptr += length;
+		}
+		ret |= __copy_from_user(ptr, addr, length);
+	}
+	if (flags & U)
+		regs->gpr[areg] = regs->dar;
+	if (ret)
+		return -EFAULT;
+	return 1;
+}
+#endif
+
 /*
  * Called on alignment exception. Attempts to fixup
  *
@@ -647,7 +678,7 @@ static int emulate_spe(struct pt_regs *r
 
 int fix_alignment(struct pt_regs *regs)
 {
-	unsigned int instr, nb, flags;
+	unsigned int instr, nb, flags, instruction = 0;
 	unsigned int reg, areg;
 	unsigned int dsisr;
 	unsigned char __user *addr;
@@ -689,6 +720,7 @@ int fix_alignment(struct pt_regs *regs)
 		if (cpu_has_feature(CPU_FTR_REAL_LE) && (regs->msr & MSR_LE))
 			instr = cpu_to_le32(instr);
 		dsisr = make_dsisr(instr);
+		instruction = instr;
 	}
 
 	/* extract the operation and registers from the dsisr */
@@ -728,6 +760,30 @@ int fix_alignment(struct pt_regs *regs)
 	/* DAR has the operand effective address */
 	addr = (unsigned char __user *)regs->dar;
 
+#ifdef CONFIG_VSX
+	if ((instruction & 0xfc00003e) == 0x7c000018) {
+		/* Additional register addressing bit (64 VSX vs 32 FPR/GPR */
+		reg |= (instruction & 0x1) << 5;
+		/* Simple inline decoder instead of a table */
+		if (instruction & 0x200)
+			nb = 16;
+		else if (instruction & 0x080)
+			nb = 8;
+		else
+			nb = 4;
+		flags = 0;
+		if (instruction & 0x100)
+			flags |= ST;
+		if (instruction & 0x040)
+			flags |= U;
+		/* splat load needs a special decoder */
+		if ((instruction & 0x400) == 0){
+			flags |= SPLT;
+			nb = 8;
+		}
+		return emulate_vsx(addr, reg, areg, regs, flags, nb);
+	}
+#endif
 	/* A size of 0 indicates an instruction we don't support, with
 	 * the exception of DCBZ which is handled as a special case here
 	 */

^ permalink raw reply

* [PATCH] powerpc: fix giveup_vsx to save registers correctly
From: Michael Neuling @ 2008-07-11  6:29 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, paulus

giveup_vsx didn't save the FPU and VMX regsiters.  Change it to be
like giveup_fpr/altivec which save these registers.

Also update call sites where FPU and VMX are already saved to use the
original giveup_vsx (renamed to __giveup_vsx).

Signed-off-by: Michael Neuling <mikey@neuling.org>
---
benh: for your 2.6.27 tree.

 arch/powerpc/kernel/misc_64.S   |    8 ++++----
 arch/powerpc/kernel/process.c   |   10 +++++++++-
 arch/powerpc/kernel/signal_32.c |    2 +-
 arch/powerpc/kernel/signal_64.c |    2 +-
 include/asm-powerpc/system.h    |    1 +
 5 files changed, 16 insertions(+), 7 deletions(-)

Index: linux-2.6-ozlabs/arch/powerpc/kernel/misc_64.S
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/misc_64.S
+++ linux-2.6-ozlabs/arch/powerpc/kernel/misc_64.S
@@ -508,12 +508,12 @@ _GLOBAL(giveup_altivec)
 
 #ifdef CONFIG_VSX
 /*
- * giveup_vsx(tsk)
- * Disable VSX for the task given as the argument,
- * and save the vector registers in its thread_struct.
+ * __giveup_vsx(tsk)
+ * Disable VSX for the task given as the argument.
+ * Does NOT save vsx registers.
  * Enables the VSX for use in the kernel on return.
  */
-_GLOBAL(giveup_vsx)
+_GLOBAL(__giveup_vsx)
 	mfmsr	r5
 	oris	r5,r5,MSR_VSX@h
 	mtmsrd	r5			/* enable use of VSX now */
Index: linux-2.6-ozlabs/arch/powerpc/kernel/process.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/process.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/process.c
@@ -159,6 +159,13 @@ void enable_kernel_vsx(void)
 EXPORT_SYMBOL(enable_kernel_vsx);
 #endif
 
+void giveup_vsx(struct task_struct *tsk)
+{
+	giveup_fpu(tsk);
+	giveup_altivec(tsk);
+	__giveup_vsx(tsk);
+}
+
 void flush_vsx_to_thread(struct task_struct *tsk)
 {
 	if (tsk->thread.regs) {
@@ -290,7 +297,8 @@ struct task_struct *__switch_to(struct t
 #endif /* CONFIG_ALTIVEC */
 #ifdef CONFIG_VSX
 	if (prev->thread.regs && (prev->thread.regs->msr & MSR_VSX))
-		giveup_vsx(prev);
+		/* VMX and FPU registers are already save here */
+		__giveup_vsx(prev);
 #endif /* CONFIG_VSX */
 #ifdef CONFIG_SPE
 	/*
Index: linux-2.6-ozlabs/arch/powerpc/kernel/signal_32.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/signal_32.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/signal_32.c
@@ -452,7 +452,7 @@ static int save_user_regs(struct pt_regs
 	 * contains valid data
 	 */
 	if (current->thread.used_vsr) {
-		flush_vsx_to_thread(current);
+		__giveup_vsx(current);
 		if (copy_vsx_to_user(&frame->mc_vsregs, current))
 			return 1;
 		msr |= MSR_VSX;
Index: linux-2.6-ozlabs/arch/powerpc/kernel/signal_64.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/signal_64.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/signal_64.c
@@ -122,7 +122,7 @@ static long setup_sigcontext(struct sigc
 	 * VMX data.
 	 */
 	if (current->thread.used_vsr) {
-		flush_vsx_to_thread(current);
+		__giveup_vsx(current);
 		v_regs += ELF_NVRREG;
 		err |= copy_vsx_to_user(v_regs, current);
 		/* set MSR_VSX in the MSR value in the frame to
Index: linux-2.6-ozlabs/include/asm-powerpc/system.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/system.h
+++ linux-2.6-ozlabs/include/asm-powerpc/system.h
@@ -139,6 +139,7 @@ extern void enable_kernel_altivec(void);
 extern void giveup_altivec(struct task_struct *);
 extern void load_up_altivec(struct task_struct *);
 extern int emulate_altivec(struct pt_regs *);
+extern void __giveup_vsx(struct task_struct *);
 extern void giveup_vsx(struct task_struct *);
 extern void enable_kernel_spe(void);
 extern void giveup_spe(struct task_struct *);

^ permalink raw reply

* Re: [PATCH v2] ibm_newemac: Add MII mode support to the EMAC RGMII bridge.
From: Jeff Garzik @ 2008-07-11  5:19 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, sr, Grant Erickson
In-Reply-To: <1215573802.8970.302.camel@pasglop>

Benjamin Herrenschmidt wrote:
> On Tue, 2008-07-08 at 08:03 -0700, Grant Erickson wrote:
>> This patch adds support to the RGMII handler in the EMAC driver for
>> the MII PHY mode such that device tree entries of the form `phy-mode = "mii";'
>> are recognized and handled appropriately.
>>
>> While logically, in software, "gmii" and "mii" modes are the same,
>> they are wired differently, so it makes sense to allow DTS authors to
>> specify each explicitly.
>>
>> Signed-off-by: Grant Erickson <gerickson@nuovations.com>
> 
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

ACK


> Jeff, I'd like to apply that (and other EMAC patches for 2.6.27, do you
> have anything else pending ?) via my tree provided you give me your ack.
> The reason is that the multicast fix one is going that way as it touches
> other arch files, and subsequent ones are now likely to conflict.
> 
> Let me know if that's ok with you in which case I'll stick your ack in
> there.

Ok w/ me!

^ permalink raw reply

* mpc744x, Marvell mv6446x kernel guidance please
From: Stephen Horton @ 2008-07-11  3:46 UTC (permalink / raw)
  To: linuxppc-embedded

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

Hello folks,

In a current work project, I have inherited a compactPCI board that has
an mpc7447/7448 powerpc processor as well as a Marvell system
controller, model mv64462 (stripped down mv64460). The board has a
somewhat working Gentoo Linux port running on it from long ago and a
company far far away (kernel version 2.6.9 built using arch/ppc). To
prepare for an upcoming deployment, I would like to bring the OS
up-to-date on this board with a newer kernel (targeting Gentoo 2008),
but I am unsure of the approach to take. I am a software developer, but
normally do not work on kernel porting / board integration. I have
researched the arch/ppc to arch/powerpc migration, but I'm a bit
intimidated by the 'new' device tree symantics and other changes to the
stream. Here are some questions:

1.	Is it possible with the 2.6.24 (Gentoo 2008) kernel to still use
arch/ppc for this platform architecture?  I've tried to get this to
compile, but am having trouble with files from arch/powerpc getting
pulled in; then I read some comments (from I believe this forum) that
indicated that arch/ppc is not longer supposed to compile
2.	Does anyone have example code for this platform architecture?
Any freebees I could use for creating my device tree?
3.	Any advice of any kind?

Regards,

Stephen


[-- Attachment #2: Type: text/html, Size: 3731 bytes --]

^ permalink raw reply

* Re: [PATCH] mpc7448: add alias list to DTS, clean out old chosen node
From: Roy Zang @ 2008-07-11  2:17 UTC (permalink / raw)
  To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <1215721295-17555-1-git-send-email-paul.gortmaker@windriver.com>

On Fri, 2008-07-11 at 04:21 +0800, Paul Gortmaker wrote:
> The mpc7448hpc2 board doesn't have an alias block like 
> most of the other modern eval boards have.  We need this 
> block in order to have u-boot be able to make use of the 
> CONFIG_OF_STDOUT_VIA_ALIAS (vs. having a hard coded node) 
> in the future.
> 
> Also remove the old, redundant chosen node.  Of all the modern 
> Freescale eval boards (incl. 83xx, 85xx, 86xx) this is the only 
> one which still has it.  Its presence also breaks with some older 
> versions of u-boot, like 1.3.1 -- which try and insert a 
> second chosen node.
> 
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> 
> --- 
Acked-by: Roy Zang <tie-fei.zang@freescale.com>
Roy

^ permalink raw reply

* Re: [RFC][WIP][PATCH] powerpc: Refactor device bindings
From: David Gibson @ 2008-07-11  0:57 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1893001D-8BB5-4549-A8B4-48A7E558CB47@kernel.crashing.org>

On Thu, Jul 10, 2008 at 08:22:53AM -0500, Kumar Gala wrote:
>
> On Jul 9, 2008, at 8:52 PM, David Gibson wrote:
>
>> On Tue, Jul 08, 2008 at 08:20:56AM -0500, Kumar Gala wrote:
>>> Moved Freescale SoC related bindings out of booting-without-of.txt  
>>> and into
>>> their own files.
>>>
>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>
>> Acked-by: David Gibson <david@gibson.dropbear.id.au>
>>
>> Of course, what I'd *really* like to do is to get a website / wiki set
>> up somewhere to be the definitive home of all bindings, but I don't
>> think it's going to happen any time real soon.
>
> agreed, I know there has been some talk of power.org trying to do this, 
> but not sure what happened there.

Yeah, neither do I.  I should chase that up again, but I don't have
the energy at the moment.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

^ permalink raw reply

* Freescale UCC_GETH Half Duplex Patch
From: Russell McGuire @ 2008-07-11  0:23 UTC (permalink / raw)
  To: 'Kim Phillips'; +Cc: linuxppc-embedded

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

Kim, ALL

Here is a fix up for the UCC_GETH driver supporting half duplex mode for
some specific modes.

I have tested this quiet extensively and the link now comes up and works,
however not sure if there are other issues that need to be looked at, since
10BaseT connectivity provides VERY ERRATIC throughput, but at least it works
now with RGMII and GMII modes.

There was a lot more in my patch, but I removed a lot of the code for
submission. Let me know if for any reason this patch file is improperly
formatted.

Russell McGuire
Senior Systems Engineer
rmcguire@videopresence.com
503.888.0968


[-- Attachment #2: ucc_geth.patch --]
[-- Type: application/octet-stream, Size: 865 bytes --]

diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 9a38dfe..5900847 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1533,10 +1698,17 @@ static void adjust_link(struct net_device *dev)
 		 * If not, we operate in half-duplex mode. */
 		if (phydev->duplex != ugeth->oldduplex) {
 			new_state = 1;
-			if (!(phydev->duplex))
-				tempval &= ~(MACCFG2_FDX);
-			else
-				tempval |= MACCFG2_FDX;
+			/* Can only use half duplex for these two modes!! */
+			if ((ugeth->phy_interface == PHY_INTERFACE_MODE_MII) ||
+			  (ugeth->phy_interface == PHY_INTERFACE_MODE_RMII)) {	
+				if (!(phydev->duplex))
+					tempval &= ~(MACCFG2_FDX);
+				else
+					tempval |= MACCFG2_FDX;
+			} else {
+				/* Always set for other modes */
+				tempval |= MACCFG2_FDX; 
+			}
 			ugeth->oldduplex = phydev->duplex;
 		}

^ permalink raw reply related

* Making __copy_tofrom_user more readable for powerpc (arch/powerpc/lib/copy_32.S)
From: prodyut hazarika @ 2008-07-10 23:44 UTC (permalink / raw)
  To: linuxppc-dev

Hi all,
I am trying to optimize the __copy_tofrom_user function for PPC4xx,
and I would want to know why the exception handling code has been made
so complicated. All the fixup code should do is to store the number of
bytes that failed in copy in r3 and return back.

The current code tries to copy one byte at a time after read fault. I
don't understand why that is necessary. It then clears out the
destination. All these logic has made the code very unfriendly to
read.

I have a version which just keeps a count of bytes copied till any
fault happened. Then for any exception, I just substract this value
from the total number of bytes to be copied, and store in r3 and
return back. This is the common fixup code for all paths. It makes the
fixup code much more readable like other architectures (eg. x86).

My questions are:
1) Why do we need to distinguish between load and store failure? If
either load or store fails, the copy did not go thru. But the code
sets r9 to 0 for load failure, and r9 to 1 for write failure. Why do
we need to care for that?

2) For read failure, why do we clear out the destination (lines 509 to
529 in arch/powerpc/lib/copy_32.S)? Other architecture don't do that.

I would appreciate any comments.

Thanks,
Prodyut

^ permalink raw reply

* Re: [PATCH] spufs: correct kcalloc usage
From: Jeremy Kerr @ 2008-07-10 23:04 UTC (permalink / raw)
  To: Milton Miller
  Cc: linuxppc-dev, Andrew Morton, cbe-oss-dev, Arnd Bergmann,
	linux-kernel
In-Reply-To: <for-27-patch8-4@bga.com>

Milton,

> kcalloc is supposed to be called with the count as its first argument
> and the element size as the second.

Thanks, applied.

Cheers,


Jeremy

^ permalink raw reply

* Re: [PATCH 1/4] kdump : add support for ibm, dynamic-reconfiguration-memory for kexec/kdump
From: Nathan Fontenot @ 2008-07-10 22:27 UTC (permalink / raw)
  To: Chandru; +Cc: linuxppc-dev, kexec
In-Reply-To: <200807080014.24910.chandru@in.ibm.com>

Hello Chandru,

>  static int __init early_init_dt_scan_drconf_memory(unsigned long node)
>  {
> -	cell_t *dm, *ls;
> +	cell_t *dm, *ls, *endp, *usm;
>  	unsigned long l, n, flags;
>  	u64 base, size, lmb_size;
> +	char buf[32], t[8];
>  
>  	ls = (cell_t *)of_get_flat_dt_prop(node, "ibm,lmb-size", &l);
>  	if (ls == NULL || l < dt_root_size_cells * sizeof(cell_t))
> @@ -917,7 +918,33 @@ static int __init early_init_dt_scan_drc
>  			if ((base + size) > 0x80000000ul)
>  				size = 0x80000000ul - base;
>  		}
> -		lmb_add(base, size);
> +		strcpy(buf, "linux,usable-memory");
> +		sprintf(t, "%d", (int)n);
> +		strcat(buf, t);
> +		usm = (cell_t *)of_get_flat_dt_prop(node,
> +						 (const char *)buf, &l);
> +		if (usm != NULL) {
> +			endp = usm + (l / sizeof(cell_t));
> +			while ((endp - usm) >= (dt_root_addr_cells +
> +						 dt_root_size_cells)) {
> +				base = dt_mem_next_cell(dt_root_addr_cells,
> +								 &usm);
> +				size = dt_mem_next_cell(dt_root_size_cells,
> +								 &usm);
> +				if (size == 0)
> +					continue;
> +				if (iommu_is_off) {
> +					if ((base + size) > 0x80000000ul)
> +						size = 0x80000000ul - base;
> +				}
> +				lmb_add(base, size);
> +			}
> +
> +			/* Continue with next lmb entry */
> +			continue;
> +		} else {
> +			lmb_add(base, size);
> +		}
>  	}

I am still digging through the kexec tools but I don't think you want
the processing of the linux,usable-memory property inside of the
for (; n!= 0; --n) loop.  This should be moved up so that it looks for
the linux,usable-memory property and parses it, then if it is not found
look for the ibm,dynamic-reconfiguration-memory property and parse it.

There is no need to look for the linux-usable-memory property every time
a piece of the ibm,dynamic-reconfiguration-memory property is parsed.

-Nathan

^ permalink raw reply

* Re: [PATCH] mpc7448: add alias list to DTS, clean out old chosen node
From: Paul Gortmaker @ 2008-07-10 22:17 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <487682E4.7060701@freescale.com>

Scott Wood wrote:
> Paul Gortmaker wrote:
>> Well, for the mpc7448hpc2, I can say for sure that there are
>> chosen-duplicating versions of u-boot 1.3.1 in use -- since
>> there wasn't a prebuilt, validated image newer than 1.1.3(?)
>> available anywhere back some 6 months ago, I'd built 1.3.1
>> and made it available with our 2.6.21 kernel.
>
> OK, if that version's in widespread use it probably makes sense to 
> remove the chosen node.

Sounds good - thanks.

>
>> If all the other boards run cuboot without console output,
>
> They don't *all* run without output -- see the 8xx, 82xx, and 4xx boards.

Yep, saw those when grepping around.  My "all" was implicitly still
referring to the newer 83xx/85xx/(86xx) reference boards, and
whether it made sense to be adding chosen nodes to those so the
cuImage had console output too -- if folks thought that was a better
route, then I could see leaving the 7448 as-is, adding the nodes
to the other boards, and just dealing with educating folks on the
chosen-duplicating version issue as it comes up.

Paul.


>
> -Scott
>

^ permalink raw reply

* Re: [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Milton Miller @ 2008-07-10 21:51 UTC (permalink / raw)
  To: Hans de Goede; +Cc: linuxppc-dev, Samuel Ortiz, linux-kernel, lm-sensors
In-Reply-To: <48768018.2070704@hhs.nl>


On Jul 10, 2008, at 4:33 PM, Hans de Goede wrote:

> Milton Miller wrote:
>> After the following patch to mark the isa region busy and applying a 
>> few
>> patches[1], I was able to kexec boot into an all-yes-config kernel 
>> from linux-next, with the following KCONFIG_ALLCONFIG file:
...
>> While the first two might not be required, and the third is just
>> selecting the right platform, it would be nice to get the drivers
>> to play as well as the rest of the kernel.
>> The drivers all are for super-io chips, either irda/FIR drivers or 
>> hwmon,
>> and poke at isa ports without checking request_region.
>
> Erm,
>
> The superio sensor drivers only poke the superio chip registers 
> without request region during the probe phase, iow they try to detect 
> the chip, using a widely document and standardized (part of isa pnp 
> AFAIK) procedure on standardized ports.
>
> Let me try to explain a bit about superio chips, they have 2 superio 
> control registers (an index and data register) with which things like 
> a manufacturer and device id can be read, besides these id registers 
> they also have a set of registers with config for different logical 
> devices. Once the id is matched, the driver knows which logical device 
> config to read, reads a (different) isa base address + range from the 
> logical device config, and then does a request_region on the region 
> actually used by the logical device.
>
> The superio control registers are thus a sort of pci configuration 
> space if you want, doing a request_region on these is not such a good 
> idea, as multiple drivers (for different logical devices within the 
> superio device) may use these, so trying to gain exclusive access will 
> lead to troubles.
>
> I hope with this info about the problem space, that you maybe have a 
> suggestion on howto fix this?
>

My point is that they are probing without even knowing that a such a IO 
range exists.

These are the only drivers left in the tree that still do this.  (At 
least that are not
blocked on a powerpc allyesconfig for 64-bit, !CONFIG_VIRT_TO_BUS).

One could make a superio driver, and create sub-devices for the IR, 
I2C, floppy, parallel, etc
nodes.

I would even accept a check_region (horrors!), it would impove the 
situation.

But most other drivers do this by request_region, probe, then release 
the region afterwards.

Besides, one could argue the superio region should be requested while 
probing, to prevent other cpus from poking at the super io chip at the 
same time.   Think of it as missing locking.

milton

^ permalink raw reply

* Re: [PATCH] mpc7448: add alias list to DTS, clean out old chosen node
From: Scott Wood @ 2008-07-10 21:45 UTC (permalink / raw)
  To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <4876823A.8010005@windriver.com>

Paul Gortmaker wrote:
> Well, for the mpc7448hpc2, I can say for sure that there are
> chosen-duplicating versions of u-boot 1.3.1 in use -- since
> there wasn't a prebuilt, validated image newer than 1.1.3(?)
> available anywhere back some 6 months ago, I'd built 1.3.1
> and made it available with our 2.6.21 kernel.

OK, if that version's in widespread use it probably makes sense to 
remove the chosen node.

> If all the other boards run cuboot without console output,

They don't *all* run without output -- see the 8xx, 82xx, and 4xx boards.

-Scott

^ permalink raw reply

* [PATCH -next-20080709] fixup stop_machine use cpu mask vs ftrace
From: Milton Miller @ 2008-07-10 21:07 UTC (permalink / raw)
  To: Ingo Molnar, Rusty Russell; +Cc: linuxppc-dev, linux-next, linux-kernel
In-Reply-To: <200807081801.38026.rusty@rustcorp.com.au>



Hi Rusty, Ingo.

Rusty's patch [PATCH 3/3] stop_machine: use cpu mask rather than magic numbers
didn't find kernel/trace/ftrace.c in -next, causing an immediate almost NULL
pointer dereference in ftrace_dynamic_init.


Signed-off-by: Milton Miller <miltonm@bga.com>

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 0f271c4..c29acb5 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -587,7 +587,7 @@ static int __ftrace_modify_code(void *data)
 
 static void ftrace_run_update_code(int command)
 {
-	stop_machine_run(__ftrace_modify_code, &command, NR_CPUS);
+	stop_machine_run(__ftrace_modify_code, &command, NULL);
 }
 
 void ftrace_disable_daemon(void)
@@ -787,7 +787,7 @@ static int ftrace_update_code(void)
 	    !ftrace_enabled || !ftraced_trigger)
 		return 0;
 
-	stop_machine_run(__ftrace_update_code, NULL, NR_CPUS);
+	stop_machine_run(__ftrace_update_code, NULL, NULL);
 
 	return 1;
 }
@@ -1564,7 +1564,7 @@ static int __init ftrace_dynamic_init(void)
 
 	addr = (unsigned long)ftrace_record_ip;
 
-	stop_machine_run(ftrace_dyn_arch_init, &addr, NR_CPUS);
+	stop_machine_run(ftrace_dyn_arch_init, &addr, NULL);
 
 	/* ftrace_dyn_arch_init places the return code in addr */
 	if (addr) {

^ permalink raw reply related

* Re: [PATCH] mpc7448: add alias list to DTS, clean out old chosen node
From: Paul Gortmaker @ 2008-07-10 21:42 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <48767AD1.9050708@freescale.com>

Scott Wood wrote:
> Jon Loeliger wrote:
>> Scott Wood wrote:
>>> Paul Gortmaker wrote:
>>>> OK, so does that mean that the cuboot wrapper is explicitly
>>>> not supported for all the 83xx, 85xx, and 86xx boards?
>>>
>>> No (except 86xx, which doesn't have cuboot, because it never existed 
>>> in arch/ppc and thus there's no compatibility to maintain), it just 
>>> means that chosen was never added to those dts files, and thus 
>>> cuboot has no console output.
>>
>> Also note that nothing stops the causal kernel booter
>
> As opposed to the spontaneous kernel booter? :-)
>
>> from _starting_ with an arch/powerpc/boot/dts/ file,
>> adding a node to it, and using _that_.
>
> The "casual" user shouldn't need to make any changes, especially for 
> the kernel's own dts files to work with the kernel's own wrapper.
>
> The decision on whether to put the chosen node in the device tree 
> should be based on which version of u-boot it's more important to 
> maintain compatibility with (for some platforms, no chosen-duplicating 
> version of u-boot supported device trees on the platform), and what 
> the consequences of each form of incompatibility are (e.g. no console 
> output during the bootwrapper, versus no boot arguments or initrd in 
> the kernel).

Well, for the mpc7448hpc2, I can say for sure that there are
chosen-duplicating versions of u-boot 1.3.1 in use -- since
there wasn't a prebuilt, validated image newer than 1.1.3(?)
available anywhere back some 6 months ago, I'd built 1.3.1
and made it available with our 2.6.21 kernel.

If all the other boards run cuboot without console output,
then is it not consistent to have this one the same as well?
Or should we be adding chosen to the other boards instead?

Paul.

>
> -Scott

^ permalink raw reply

* Re: [lm-sensors] [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Hans de Goede @ 2008-07-10 21:33 UTC (permalink / raw)
  To: Milton Miller; +Cc: linuxppc-dev, Samuel Ortiz, linux-kernel, lm-sensors
In-Reply-To: <for-27-patch1-0@bga.com>

Milton Miller wrote:
> After the following patch to mark the isa region busy and applying a few
> patches[1], I was able to kexec boot into an all-yes-config kernel from 
> linux-next, with the following KCONFIG_ALLCONFIG file:
> 
> # CONFIG_KALLSYMS_EXTRA_PASS is not set
> # CONFIG_CRASH_DUMP is not set
> CONFIG_PPC_EARLY_DEBUG_RTAS_CONSOLE=y
> # CONFIG_NSC_FIR is not set
> # CONFIG_SMC_IRCC_FIR is not set
> # CONFIG_ALI_FIR is not set
> # CONFIG_TCG_NSC is not set
> # CONFIG_TCG_ATMEL is not set
> # CONFIG_SENSORS_F71805F is not set
> # CONFIG_SENSORS_F71882FG is not set
> # CONFIG_SENSORS_F75375S is not set
> # CONFIG_SENSORS_IT87 is not set
> # CONFIG_SENSORS_PC87360 is not set
> # CONFIG_SENSORS_PC87427 is not set
> # CONFIG_SENSORS_DME1737 is not set
> # CONFIG_SENSORS_SMSC47M1 is not set
> # CONFIG_SENSORS_SMSC47B397 is not set
> # CONFIG_SENSORS_VT1211 is not set
> # CONFIG_SENSORS_W83627HF is not set
> # CONFIG_SENSORS_W83627EHF is not set
> 
> While the first two might not be required, and the third is just
> selecting the right platform, it would be nice to get the drivers
> to play as well as the rest of the kernel.
> 
> The drivers all are for super-io chips, either irda/FIR drivers or hwmon,
> and poke at isa ports without checking request_region.
> 

Erm,

The superio sensor drivers only poke the superio chip registers without request 
region during the probe phase, iow they try to detect the chip, using a widely 
document and standardized (part of isa pnp AFAIK) procedure on standardized ports.

Let me try to explain a bit about superio chips, they have 2 superio control 
registers (an index and data register) with which things like a manufacturer 
and device id can be read, besides these id registers they also have a set of 
registers with config for different logical devices. Once the id is matched, 
the driver knows which logical device config to read, reads a (different) isa 
base address + range from the logical device config, and then does a 
request_region on the region actually used by the logical device.

The superio control registers are thus a sort of pci configuration space if you 
want, doing a request_region on these is not such a good idea, as multiple 
drivers (for different logical devices within the superio device) may use 
these, so trying to gain exclusive access will lead to troubles.

I hope with this info about the problem space, that you maybe have a suggestion 
on howto fix this?

Regards,

Hans
> 

^ permalink raw reply

* [PATCH] spufs: correct kcalloc usage
From: Milton Miller @ 2008-07-10 21:29 UTC (permalink / raw)
  To: Jeremy Kerr, cbe-oss-dev
  Cc: linuxppc-dev, Andrew Morton, linux-kernel, Arnd Bergmann
In-Reply-To: <for-27-patch1-0@bga.com>

kcalloc is supposed to be called with the count as its first argument and
the element size as the second.

Signed-off-by: Milton Miller <miltonm@bga.com>
---
Both arguments are size_t so does not affect correctness.  This callsite is
during module_init and therefore not performance critical.  Another patch
will optimize the case when the count is variable but the size is fixed.


diff --git a/arch/powerpc/platforms/cell/spufs/sputrace.c b/arch/powerpc/platforms/cell/spufs/sputrace.c
index 8c0e957..92d20e9 100644
--- a/arch/powerpc/platforms/cell/spufs/sputrace.c
+++ b/arch/powerpc/platforms/cell/spufs/sputrace.c
@@ -196,8 +196,7 @@ static int __init sputrace_init(void)
 	struct proc_dir_entry *entry;
 	int i, error = -ENOMEM;
 
-	sputrace_log = kcalloc(sizeof(struct sputrace),
-				bufsize, GFP_KERNEL);
+	sputrace_log = kcalloc(bufsize, sizeof(struct sputrace), GFP_KERNEL);
 	if (!sputrace_log)
 		goto out;
 

^ permalink raw reply related

* powerpc: add static and ifdef prom_strtoul and prom_memparse
From: Milton Miller @ 2008-07-10 21:23 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <for-27-patch1-0@bga.com>

These functions should have been static, and inspection shows they
are no longer used.   (We used to parse mem= but we now defer that
to early_param).

Signed-off-by: Milton Miller <miltonm@bga.com>
---
Should we just remove them instead?

diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 1ea8c8d..bf1f922 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -489,6 +489,7 @@ static int __init prom_setprop(phandle node, const char *nodename,
 	return call_prom("interpret", 1, 1, (u32)(unsigned long) cmd);
 }
 
+#if 0
 /* We can't use the standard versions because of RELOC headaches. */
 #define isxdigit(c)	(('0' <= (c) && (c) <= '9') \
 			 || ('a' <= (c) && (c) <= 'f') \
@@ -498,7 +499,7 @@ static int __init prom_setprop(phandle node, const char *nodename,
 #define islower(c)	('a' <= (c) && (c) <= 'z')
 #define toupper(c)	(islower(c) ? ((c) - 'a' + 'A') : (c))
 
-unsigned long prom_strtoul(const char *cp, const char **endp)
+static unsigned long prom_strtoul(const char *cp, const char **endp)
 {
 	unsigned long result = 0, base = 10, value;
 
@@ -523,7 +524,7 @@ unsigned long prom_strtoul(const char *cp, const char **endp)
 	return result;
 }
 
-unsigned long prom_memparse(const char *ptr, const char **retptr)
+static unsigned long prom_memparse(const char *ptr, const char **retptr)
 {
 	unsigned long ret = prom_strtoul(ptr, retptr);
 	int shift = 0;
@@ -549,6 +550,7 @@ unsigned long prom_memparse(const char *ptr, const char **retptr)
 
 	return ret;
 }
+#endif
 
 /*
  * Early parsing of the command line passed to the kernel, used for

^ permalink raw reply related

* powerpc: find and destroy possible stale kernel added properties
From: Milton Miller @ 2008-07-10 21:22 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <for-27-patch1-0@bga.com>

Because we copy the image using the kernels virtual memory system, we
require kexec user space to avoid overwriting the static kernel image, tce
tables, and the hash table.  Kexec userspace gets this information by
reading propertys the kernel adds, but does not filter these propertys when
starting the next kernel.

When the second kernel trys to add its propertys, the export via
/proc/device-tree is hidden by the pre-existing but stale value from the
flat tree.  Kexec userspace reads the old property, allocates the new kernel
at the old kernel's end, and gets rejected by the check

Search and remove these stale properties before adding the new values.

Signed-off-by: Milton Miller <miltonm@bga.com>
---
While there is an override flag to tell kexec a minimum memory to use, that
is a crude workaround and this should be applied to stable.


diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index a168514..4bd8b4f 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -312,11 +312,24 @@ static struct property kernel_end_prop = {
 static void __init export_htab_values(void)
 {
 	struct device_node *node;
+	struct property *prop;
 
 	node = of_find_node_by_path("/chosen");
 	if (!node)
 		return;
 
+	/* remove any stale propertys so ours can be found */
+	prop = of_find_property(node, kernel_end_prop.name, NULL);
+	if (prop)
+		prom_remove_property(node, prop);
+	prop = of_find_property(node, htab_base_prop.name, NULL);
+	if (prop)
+		prom_remove_property(node, prop);
+	prop = of_find_property(node, htab_size_prop.name, NULL);
+	if (prop)
+		prom_remove_property(node, prop);
+
+	/* information needed by userspace when using default_machine_kexec */
 	kernel_end = __pa(_end);
 	prom_add_property(node, &kernel_end_prop);
 

^ permalink raw reply related

* powerpc: pseries, cell: use cpu_thread_in_core in smp_init for of_spin_map
From: Milton Miller @ 2008-07-10 21:20 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <for-27-patch1-0@bga.com>

Replace a left over % 2 to be a check for the primary thread and
update the comments.

Note: We assume the secondary threads are not spinning, but they are
actually spinning if we start via kexec.  This means that we call rtas to
spin up the secondary threads. If we get a bad return code from we skip
bringing the cpu online, leaving the thread spinning on the paca.  We don't
handle this case in kexec, and will leave the thread wild during another
kexec.

Signed-off-by: Milton Miller <miltonm@bga.com>
---
I added a debug print and manually verified the correct cpumask was
generated on pSeries.  I ran across the identical code in cell by
the grep of System.map.



diff --git a/arch/powerpc/platforms/cell/smp.c b/arch/powerpc/platforms/cell/smp.c
index efb3964..c0d86e1 100644
--- a/arch/powerpc/platforms/cell/smp.c
+++ b/arch/powerpc/platforms/cell/smp.c
@@ -54,8 +54,8 @@
 #endif
 
 /*
- * The primary thread of each non-boot processor is recorded here before
- * smp init.
+ * The Primary thread of each non-boot processor was started from the OF client
+ * interface by prom_hold_cpus and is spinning on secondary_hold_spinloop.
  */
 static cpumask_t of_spin_map;
 
@@ -208,11 +208,7 @@ void __init smp_init_cell(void)
 	/* Mark threads which are still spinning in hold loops. */
 	if (cpu_has_feature(CPU_FTR_SMT)) {
 		for_each_present_cpu(i) {
-			if (i % 2 == 0)
-				/*
-				 * Even-numbered logical cpus correspond to
-				 * primary threads.
-				 */
+			if (cpu_thread_in_core(i) == 0)
 				cpu_set(i, of_spin_map);
 		}
 	} else {
diff --git a/arch/powerpc/platforms/pseries/smp.c b/arch/powerpc/platforms/pseries/smp.c
index 9d8f8c8..c9337c7 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -52,8 +52,8 @@
 
 
 /*
- * The primary thread of each non-boot processor is recorded here before
- * smp init.
+ * The Primary thread of each non-boot processor was started from the OF client
+ * interface by prom_hold_cpus and is spinning on secondary_hold_spinloop.
  */
 static cpumask_t of_spin_map;
 
@@ -191,8 +191,7 @@ static void __devinit smp_pSeries_kick_cpu(int nr)
 static int smp_pSeries_cpu_bootable(unsigned int nr)
 {
 	/* Special case - we inhibit secondary thread startup
-	 * during boot if the user requests it.  Odd-numbered
-	 * cpus are assumed to be secondary threads.
+	 * during boot if the user requests it.
 	 */
 	if (system_state < SYSTEM_RUNNING &&
 	    cpu_has_feature(CPU_FTR_SMT) &&
@@ -229,11 +228,7 @@ static void __init smp_init_pseries(void)
 	/* Mark threads which are still spinning in hold loops. */
 	if (cpu_has_feature(CPU_FTR_SMT)) {
 		for_each_present_cpu(i) { 
-			if (i % 2 == 0)
-				/*
-				 * Even-numbered logical cpus correspond to
-				 * primary threads.
-				 */
+			if (cpu_thread_in_core(i) == 0)
 				cpu_set(i, of_spin_map);
 		}
 	} else {

^ permalink raw reply related

* powerpc: numa.c: always trim to lmb_end_of_DRAM
From: Milton Miller @ 2008-07-10 21:19 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <for-27-patch1-0@bga.com>

numa_enforce_memory_limit trys to be smart and only trim the memory it
finds to lmb_end_of_DRAM when a memory limit is set.   However, the
early boot code may also limit memory when iommu=off is specified.  When
this happens, the page allocator is told of pages not in the linear mapping
and gets a fatal DSI.

Signed-off-by: Milton Miller <miltonm@bga.com>
--
Previously this patch tried to check if iommu=off was specified, but it was
requested that the check just be removed.

http://patchwork.ozlabs.org/linuxppc/patch?id=11774

diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index cf4bffb..590406c 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -472,12 +472,10 @@ static unsigned long __init numa_enforce_memory_limit(unsigned long start,
 	/*
 	 * We use lmb_end_of_DRAM() in here instead of memory_limit because
 	 * we've already adjusted it for the limit and it takes care of
-	 * having memory holes below the limit.
+	 * having memory holes below the limit.  Also, in the case of
+	 * iommu_is_off, memory_limit is not set but is implicitly enforced.
 	 */
 
-	if (! memory_limit)
-		return size;
-
 	if (start + size <= lmb_end_of_DRAM())
 		return size;
 

^ permalink raw reply related

* [2/3] powerpc: head_64.S: put irq vectors in .text.head
From: Milton Miller @ 2008-07-10 21:16 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <for-27-patch1-0@bga.com>

We rely on careful placement of the start of the kernel, and use org from
the start of our image to line up the exception handlers.

When building a large kernel, the linker will insert stubs to call from one
toc to the next, breaking our careful placement.  In addition, kexec does
not (currently) look at the entry address specified in the header but assumes
that the begining of the load segment is the entry point.

Move the first 0x8000 bytes to .text.head so it will be linked first.

Signed-off-by: Milton Miller <miltonm@bga.com>
---
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index ecced1e..4ad435a 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -21,6 +21,7 @@
  *  2 of the License, or (at your option) any later version.
  */
 
+#include <linux/init.h>
 #include <linux/threads.h>
 #include <asm/reg.h>
 #include <asm/page.h>
@@ -70,10 +71,11 @@
  *   2. The kernel is entered at system_reset_iSeries
  */
 
-	.text
+	__HEAD /* should be, but is ... */
+	.section ".text.head"
 	.globl  _stext
 _stext:
-_GLOBAL(__start)
+_HEAD_GLOBAL(__start)
 	/* NOP this out unconditionally */
 BEGIN_FTR_SECTION
 	b	.__start_initialization_multiplatform
@@ -110,7 +112,7 @@ __secondary_hold_acknowledge:
  * is relocated to physical address 0x60 before prom_init is run.
  * All of it must fit below the first exception vector at 0x100.
  */
-_GLOBAL(__secondary_hold)
+_HEAD_GLOBAL(__secondary_hold)
 	mfmsr	r24
 	ori	r24,r24,MSR_RI
 	mtmsrd	r24			/* RI on */
@@ -142,7 +144,7 @@ _GLOBAL(__secondary_hold)
 	.section ".toc","aw"
 exception_marker:
 	.tc	ID_72656773_68657265[TC],0x7265677368657265
-	.text
+	.previous
 
 /*
  * This is the start of the interrupt handlers for pSeries
@@ -614,7 +616,7 @@ unrecov_user_slb:
  * r3 is saved in paca->slb_r3
  * We assume we aren't going to take any exceptions during this procedure.
  */
-_GLOBAL(slb_miss_realmode)
+_HEAD_GLOBAL(slb_miss_realmode)
 	mflr	r10
 
 	stw	r9,PACA_EXSLB+EX_CCR(r13)	/* save CR in exc. frame */
@@ -776,7 +778,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
  * switch (ie, no lazy save of the vector registers).
  * On entry: r13 == 'current' && last_task_used_altivec != 'current'
  */
-_STATIC(load_up_altivec)
+_HEAD_STATIC(load_up_altivec)
 	mfmsr	r5			/* grab the current MSR */
 	oris	r5,r5,MSR_VEC@h
 	mtmsrd	r5			/* enable use of VMX now */
@@ -865,7 +867,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
  * been saved already.
  * On entry: r13 == 'current' && last_task_used_vsx != 'current'
  */
-_STATIC(load_up_vsx)
+_HEAD_STATIC(load_up_vsx)
 /* Load FP and VSX registers if they haven't been done yet */
 	andi.	r5,r12,MSR_FP
 	beql+	load_up_fpu		/* skip if already loaded */
@@ -905,7 +907,7 @@ _STATIC(load_up_vsx)
  * Hash table stuff
  */
 	.align	7
-_STATIC(do_hash_page)
+_HEAD_STATIC(do_hash_page)
 	std	r3,_DAR(r1)
 	std	r4,_DSISR(r1)
 
@@ -1035,7 +1037,7 @@ do_ste_alloc:
  * We assume (DAR >> 60) == 0xc.
  */
 	.align	7
-_GLOBAL(do_stab_bolted)
+_HEAD_GLOBAL(do_stab_bolted)
 	stw	r9,PACA_EXSLB+EX_CCR(r13)	/* save CR in exc. frame */
 	std	r11,PACA_EXSLB+EX_SRR0(r13)	/* save SRR0 in exc. frame */
 
@@ -1416,7 +1418,7 @@ copy_to_here:
  * On PowerMac, secondary processors starts from the reset vector, which
  * is temporarily turned into a call to one of the functions below.
  */
-	.section ".text";
+	#.section ".text";
 	.align 2 ;
 
 	.globl	__secondary_start_pmac_0

^ permalink raw reply related

* Re: powerpc/cell/cpufreq: add spu aware cpufreq governor
From: Dominik Brodowski @ 2008-07-10 21:16 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Stephen Rothwell, Dave Jones, cpufreq, linuxppc-dev, Jeremy Kerr,
	cbe-oss-dev
In-Reply-To: <200807102305.08752.arnd@arndb.de>

On Thu, Jul 10, 2008 at 11:05:08PM +0200, Arnd Bergmann wrote:
> On Thursday 10 July 2008, Dominik Brodowski wrote:
> > Actually, "cpufreq-set -g spu_governor" should be enough. (BTW, do we really
> > want this name?)
> 
> Do you have a better suggestion for the name? I don't think there was a
> particularly strong reason to choose it over something else.

The issue I was pondering is whether to include "governor" in the name, for
we do not do this for the other governors. So here are my suggestions :)

	spu
	spuload
	spudemand

Best,
	Dominik

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox