LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/3] Raise the upper limit of NR_CPUS.
From: Tony Breeds @ 2008-04-22  3:30 UTC (permalink / raw)
  To: Paul Mackerras, linuxppc-dev

As the pacas are statically initialised increasing NR_CPUS beyond 128,
means that any additional pacas will be empty  ... which is bad.

This patch adds the required functionality to fill in any excess pacas
at runtime.

Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
 arch/powerpc/kernel/paca.c             |   57 ++++++++++++++++++++------------
 arch/powerpc/kernel/setup_64.c         |    3 ++
 arch/powerpc/platforms/Kconfig.cputype |    4 +-
 include/asm-powerpc/paca.h             |   20 +++++++++++
 4 files changed, 61 insertions(+), 23 deletions(-)

diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index ac163bd..7cd55f2 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -18,6 +18,15 @@
 #include <asm/paca.h>
 #include <asm/mmu.h>
 
+/*
+ * In order to handle "strange" values of NR_CPUS, Make sure we use
+ * max(NR_CPUS, NR_STATIC_PACAS) for array sizes below
+ */
+#if NR_CPUS > NR_STATIC_PACAS
+#define MAX_CPUS	NR_CPUS
+#else
+#define MAX_CPUS	NR_STATIC_PACAS
+#endif
 
 /* This symbol is provided by the linker - let it fill in the paca
  * field correctly */
@@ -33,7 +42,7 @@ extern unsigned long __toc_start;
  * will suffice to ensure that it doesn't cross a page boundary.
  */
 struct lppaca lppaca[] = {
-	[0 ... (NR_CPUS-1)] = {
+	[0 ... (MAX_CPUS-1)] = {
 		.desc = 0xd397d781,	/* "LpPa" */
 		.size = sizeof(struct lppaca),
 		.dyn_proc_status = 2,
@@ -50,7 +59,7 @@ struct lppaca lppaca[] = {
  * initially, hence will all be invaild until we actually write them.
  */
 struct slb_shadow slb_shadow[] __cacheline_aligned = {
-	[0 ... (NR_CPUS-1)] = {
+	[0 ... (MAX_CPUS-1)] = {
 		.persistent = SLB_NUM_BOLTED,
 		.buffer_length = sizeof(struct slb_shadow),
 	},
@@ -76,7 +85,7 @@ struct slb_shadow slb_shadow[] __cacheline_aligned = {
 	.__current = &init_task,					    \
 }
 
-struct paca_struct paca[] = {
+struct paca_struct paca[MAX_CPUS] = {
 	PACA_INIT(0),
 #if NR_CPUS > 1
 	PACA_INIT(  1), PACA_INIT(  2), PACA_INIT(  3),
@@ -98,27 +107,33 @@ struct paca_struct paca[] = {
 	PACA_INIT( 52), PACA_INIT( 53), PACA_INIT( 54), PACA_INIT( 55),
 	PACA_INIT( 56), PACA_INIT( 57), PACA_INIT( 58), PACA_INIT( 59),
 	PACA_INIT( 60), PACA_INIT( 61), PACA_INIT( 62), PACA_INIT( 63),
-#if NR_CPUS > 64
-	PACA_INIT( 64), PACA_INIT( 65), PACA_INIT( 66), PACA_INIT( 67),
-	PACA_INIT( 68), PACA_INIT( 69), PACA_INIT( 70), PACA_INIT( 71),
-	PACA_INIT( 72), PACA_INIT( 73), PACA_INIT( 74), PACA_INIT( 75),
-	PACA_INIT( 76), PACA_INIT( 77), PACA_INIT( 78), PACA_INIT( 79),
-	PACA_INIT( 80), PACA_INIT( 81), PACA_INIT( 82), PACA_INIT( 83),
-	PACA_INIT( 84), PACA_INIT( 85), PACA_INIT( 86), PACA_INIT( 87),
-	PACA_INIT( 88), PACA_INIT( 89), PACA_INIT( 90), PACA_INIT( 91),
-	PACA_INIT( 92), PACA_INIT( 93), PACA_INIT( 94), PACA_INIT( 95),
-	PACA_INIT( 96), PACA_INIT( 97), PACA_INIT( 98), PACA_INIT( 99),
-	PACA_INIT(100), PACA_INIT(101), PACA_INIT(102), PACA_INIT(103),
-	PACA_INIT(104), PACA_INIT(105), PACA_INIT(106), PACA_INIT(107),
-	PACA_INIT(108), PACA_INIT(109), PACA_INIT(110), PACA_INIT(111),
-	PACA_INIT(112), PACA_INIT(113), PACA_INIT(114), PACA_INIT(115),
-	PACA_INIT(116), PACA_INIT(117), PACA_INIT(118), PACA_INIT(119),
-	PACA_INIT(120), PACA_INIT(121), PACA_INIT(122), PACA_INIT(123),
-	PACA_INIT(124), PACA_INIT(125), PACA_INIT(126), PACA_INIT(127),
-#endif
 #endif
 #endif
 #endif
 #endif
 };
 EXPORT_SYMBOL(paca);
+
+/*
+ * The first few (NR_STATIC_PACAS) paca entires are initiialised
+ * statically. populate the rest.
+ */
+void __init initialise_pacas(void)
+{
+	int cpu;
+	unsigned long kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL;
+
+	/* Can't use for_each_*_cpu, as they aren't functional yet */
+	for (cpu = NR_STATIC_PACAS; cpu < NR_CPUS; cpu++) {
+		struct paca_struct *new_paca = &paca[cpu];
+
+		new_paca->lppaca_ptr = &lppaca[cpu];
+		new_paca->lock_token = 0x8000;
+		new_paca->paca_index = cpu;
+		new_paca->kernel_toc = kernel_toc;
+		new_paca->hw_cpu_id = 0xffff;
+		new_paca->slb_shadow_ptr = &slb_shadow[cpu];
+		new_paca->__current = &init_task;
+
+	}
+}
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 31ada9f..5e382ac 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -170,6 +170,9 @@ void __init setup_paca(int cpu)
 
 void __init early_setup(unsigned long dt_ptr)
 {
+	/* Fill in any unititialised pacas */
+	initialise_pacas();
+
 	/* Identify CPU type */
 	identify_cpu(0, mfspr(SPRN_PVR));
 
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 5fc7fac..f7efaa9 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -220,8 +220,8 @@ config SMP
 	  If you don't know what to do here, say N.
 
 config NR_CPUS
-	int "Maximum number of CPUs (2-128)"
-	range 2 128
+	int "Maximum number of CPUs (2-1024)"
+	range 2 1024
 	depends on SMP
 	default "32" if PPC64
 	default "4"
diff --git a/include/asm-powerpc/paca.h b/include/asm-powerpc/paca.h
index eb61b9c..871f693 100644
--- a/include/asm-powerpc/paca.h
+++ b/include/asm-powerpc/paca.h
@@ -16,10 +16,29 @@
 #define _ASM_POWERPC_PACA_H
 #ifdef __KERNEL__
 
+#include <linux/threads.h>
+
 #include	<asm/types.h>
 #include	<asm/lppaca.h>
 #include	<asm/mmu.h>
 
+/*
+ * iSeries needs the paca to be statically allocated and initialised.
+ * We will allocated this many, based on NR_CPUS.
+ */
+#if   NR_CPUS >= 32
+#define NR_STATIC_PACAS	64
+#elif NR_CPUS > 8
+#define NR_STATIC_PACAS	32
+#elif NR_CPUS > 4
+#define NR_STATIC_PACAS	8
+#elif NR_CPUS > 1
+#define NR_STATIC_PACAS	4
+#else
+#define NR_STATIC_PACAS	1
+#endif
+
+
 register struct paca_struct *local_paca asm("r13");
 
 #if defined(CONFIG_DEBUG_PREEMPT) && defined(CONFIG_SMP)
@@ -108,6 +127,7 @@ struct paca_struct {
 };
 
 extern struct paca_struct paca[];
+extern void initialise_pacas(void);
 
 #endif /* __KERNEL__ */
 #endif /* _ASM_POWERPC_PACA_H */
-- 
1.5.5

^ permalink raw reply related

* [PATCH 3/3] Move the paca array into the BSS.
From: Tony Breeds @ 2008-04-22  3:30 UTC (permalink / raw)
  To: Paul Mackerras, linuxppc-dev
In-Reply-To: <767e424a294239aba86aa7da086f6395f7066d14.1208834828.git.tony@bakeyournoodle.com>

With NR_CPUS=1024
text    data     bss     dec     hex filename
 137 1704032       0 1704169  1a00e9 arch/powerpc/kernel/paca.o :Before
 121 1179744  524288 1704153  1a00d9 arch/powerpc/kernel/paca.o :After

Now that we're not staatically allocating the paca, we don't need the
NR_STATIC_PACAS #define anymore.

Also remove unneeded #includes.

Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
 arch/powerpc/kernel/paca.c |   64 +++-----------------------------------------
 include/asm-powerpc/paca.h |   17 -----------
 2 files changed, 4 insertions(+), 77 deletions(-)

diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 7cd55f2..c4c02c6 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -7,26 +7,11 @@
  *      2 of the License, or (at your option) any later version.
  */
 
-#include <linux/types.h>
 #include <linux/threads.h>
 #include <linux/module.h>
 
-#include <asm/processor.h>
-#include <asm/ptrace.h>
-#include <asm/page.h>
 #include <asm/lppaca.h>
 #include <asm/paca.h>
-#include <asm/mmu.h>
-
-/*
- * In order to handle "strange" values of NR_CPUS, Make sure we use
- * max(NR_CPUS, NR_STATIC_PACAS) for array sizes below
- */
-#if NR_CPUS > NR_STATIC_PACAS
-#define MAX_CPUS	NR_CPUS
-#else
-#define MAX_CPUS	NR_STATIC_PACAS
-#endif
 
 /* This symbol is provided by the linker - let it fill in the paca
  * field correctly */
@@ -42,7 +27,7 @@ extern unsigned long __toc_start;
  * will suffice to ensure that it doesn't cross a page boundary.
  */
 struct lppaca lppaca[] = {
-	[0 ... (MAX_CPUS-1)] = {
+	[0 ... (NR_CPUS-1)] = {
 		.desc = 0xd397d781,	/* "LpPa" */
 		.size = sizeof(struct lppaca),
 		.dyn_proc_status = 2,
@@ -59,7 +44,7 @@ struct lppaca lppaca[] = {
  * initially, hence will all be invaild until we actually write them.
  */
 struct slb_shadow slb_shadow[] __cacheline_aligned = {
-	[0 ... (MAX_CPUS-1)] = {
+	[0 ... (NR_CPUS-1)] = {
 		.persistent = SLB_NUM_BOLTED,
 		.buffer_length = sizeof(struct slb_shadow),
 	},
@@ -74,57 +59,16 @@ struct slb_shadow slb_shadow[] __cacheline_aligned = {
  * processors.  The processor VPD array needs one entry per physical
  * processor (not thread).
  */
-#define PACA_INIT(number)						    \
-{									    \
-	.lppaca_ptr = &lppaca[number],					    \
-	.lock_token = 0x8000,						    \
-	.paca_index = (number),		/* Paca Index */		    \
-	.kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL,		    \
-	.hw_cpu_id = 0xffff,						    \
-	.slb_shadow_ptr = &slb_shadow[number],				    \
-	.__current = &init_task,					    \
-}
-
-struct paca_struct paca[MAX_CPUS] = {
-	PACA_INIT(0),
-#if NR_CPUS > 1
-	PACA_INIT(  1), PACA_INIT(  2), PACA_INIT(  3),
-#if NR_CPUS > 4
-	PACA_INIT(  4), PACA_INIT(  5), PACA_INIT(  6), PACA_INIT(  7),
-#if NR_CPUS > 8
-	PACA_INIT(  8), PACA_INIT(  9), PACA_INIT( 10), PACA_INIT( 11),
-	PACA_INIT( 12), PACA_INIT( 13), PACA_INIT( 14), PACA_INIT( 15),
-	PACA_INIT( 16), PACA_INIT( 17), PACA_INIT( 18), PACA_INIT( 19),
-	PACA_INIT( 20), PACA_INIT( 21), PACA_INIT( 22), PACA_INIT( 23),
-	PACA_INIT( 24), PACA_INIT( 25), PACA_INIT( 26), PACA_INIT( 27),
-	PACA_INIT( 28), PACA_INIT( 29), PACA_INIT( 30), PACA_INIT( 31),
-#if NR_CPUS > 32
-	PACA_INIT( 32), PACA_INIT( 33), PACA_INIT( 34), PACA_INIT( 35),
-	PACA_INIT( 36), PACA_INIT( 37), PACA_INIT( 38), PACA_INIT( 39),
-	PACA_INIT( 40), PACA_INIT( 41), PACA_INIT( 42), PACA_INIT( 43),
-	PACA_INIT( 44), PACA_INIT( 45), PACA_INIT( 46), PACA_INIT( 47),
-	PACA_INIT( 48), PACA_INIT( 49), PACA_INIT( 50), PACA_INIT( 51),
-	PACA_INIT( 52), PACA_INIT( 53), PACA_INIT( 54), PACA_INIT( 55),
-	PACA_INIT( 56), PACA_INIT( 57), PACA_INIT( 58), PACA_INIT( 59),
-	PACA_INIT( 60), PACA_INIT( 61), PACA_INIT( 62), PACA_INIT( 63),
-#endif
-#endif
-#endif
-#endif
-};
+struct paca_struct paca[NR_CPUS];
 EXPORT_SYMBOL(paca);
 
-/*
- * The first few (NR_STATIC_PACAS) paca entires are initiialised
- * statically. populate the rest.
- */
 void __init initialise_pacas(void)
 {
 	int cpu;
 	unsigned long kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL;
 
 	/* Can't use for_each_*_cpu, as they aren't functional yet */
-	for (cpu = NR_STATIC_PACAS; cpu < NR_CPUS; cpu++) {
+	for (cpu = 0; cpu < NR_CPUS; cpu++) {
 		struct paca_struct *new_paca = &paca[cpu];
 
 		new_paca->lppaca_ptr = &lppaca[cpu];
diff --git a/include/asm-powerpc/paca.h b/include/asm-powerpc/paca.h
index 871f693..0bfc180 100644
--- a/include/asm-powerpc/paca.h
+++ b/include/asm-powerpc/paca.h
@@ -22,23 +22,6 @@
 #include	<asm/lppaca.h>
 #include	<asm/mmu.h>
 
-/*
- * iSeries needs the paca to be statically allocated and initialised.
- * We will allocated this many, based on NR_CPUS.
- */
-#if   NR_CPUS >= 32
-#define NR_STATIC_PACAS	64
-#elif NR_CPUS > 8
-#define NR_STATIC_PACAS	32
-#elif NR_CPUS > 4
-#define NR_STATIC_PACAS	8
-#elif NR_CPUS > 1
-#define NR_STATIC_PACAS	4
-#else
-#define NR_STATIC_PACAS	1
-#endif
-
-
 register struct paca_struct *local_paca asm("r13");
 
 #if defined(CONFIG_DEBUG_PREEMPT) && defined(CONFIG_SMP)
-- 
1.5.5

^ permalink raw reply related

* [PATCH 2/3] Make iSeries spin on __secondary_hold_spinloop, like pSeries.
From: Tony Breeds @ 2008-04-22  3:30 UTC (permalink / raw)
  To: Paul Mackerras, linuxppc-dev; +Cc: Stephen Rothwell
In-Reply-To: <767e424a294239aba86aa7da086f6395f7066d14.1208834828.git.tony@bakeyournoodle.com>

Currently all iSeries secondary CPU's spin directly on the cpu_start in thier
paca.  Make them spin on the global __secondary_hold_spinloop, until after the
pacas have been initialised.

Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
 arch/powerpc/platforms/iseries/exception.S |   27 ++++++++++++++++++++++++++-
 1 files changed, 26 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/iseries/exception.S b/arch/powerpc/platforms/iseries/exception.S
index c775cd4..8ff330d 100644
--- a/arch/powerpc/platforms/iseries/exception.S
+++ b/arch/powerpc/platforms/iseries/exception.S
@@ -59,8 +59,33 @@ system_reset_iSeries:
 	andc	r4,r4,r5
 	mtspr	SPRN_CTRLT,r4
 
+/* Spin on __secondary_hold_spinloop until it is updated by the boot cpu. */
+/* In the UP case we'll yeild() later, and we will not access the paca anyway */
+#ifdef CONFIG_SMP
 1:
 	HMT_LOW
+	LOAD_REG_IMMEDIATE(r23, __secondary_hold_spinloop)
+	ld	r23,0(r23)
+	sync
+	LOAD_REG_IMMEDIATE(r3,current_set)
+	sldi	r28,r24,3		/* get current_set[cpu#] */
+	ldx	r3,r3,r28
+	addi	r1,r3,THREAD_SIZE
+	subi	r1,r1,STACK_FRAME_OVERHEAD
+
+	cmpwi	0,r23,0			/* Keep poking the Hypervisor until */
+	bne	2f			/* we're released */
+	/* Let the Hypervisor know we are alive */
+	/* 8002 is a call to HvCallCfg::getLps, a harmless Hypervisor function */
+	lis	r3,0x8002
+	rldicr	r3,r3,32,15		/* r0 = (r3 << 32) & 0xffff000000000000 */
+	li	r0,-1			/* r0=-1 indicates a Hypervisor call */
+	sc				/* Invoke the hypervisor via a system call */
+	b	1b
+#endif
+
+2:
+	HMT_LOW
 #ifdef CONFIG_SMP
 	lbz	r23,PACAPROCSTART(r13)	/* Test if this processor
 					 * should start */
@@ -91,7 +116,7 @@ iSeries_secondary_smp_loop:
 	li	r0,-1			/* r0=-1 indicates a Hypervisor call */
 	sc				/* Invoke the hypervisor via a system call */
 	mfspr	r13,SPRN_SPRG3		/* Put r13 back ???? */
-	b	1b			/* If SMP not configured, secondaries
+	b	2b			/* If SMP not configured, secondaries
 					 * loop forever */
 
 /***  ISeries-LPAR interrupt handlers ***/
-- 
1.5.5

^ permalink raw reply related

* mpc8379e rdb nand flash support
From: ??? @ 2008-04-22  3:07 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <mailman.3.1208829603.21538.linuxppc-embedded@ozlabs.org>

RGVhciBhbGw6DQogICAgIE5vdyBJIHVzZWQgdGhlIG1wYzgzNzllcmRiIGJvYXJkIGFuZCBjaGFu
Z2VkIHRoZSBuYW5kIGZsYXNoIGZyb20gMzJNIHRvIDFHIC4NCiAgICAgYnV0IHdoZW4gSSB1c2Vk
IHUtYm9vdCBjb21tYW5kIGZvciBuYW5kIHdyaXRlICxzb21lIHByb2JsZW0gaGFwcGVuZWQgbGlr
ZToNClUtQm9vdCAxLjMuMC1yYzINCi8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vDQogICAgIEVob21ldGVjaCAjaGVscCBuYW5kDQpuYW5kIGluZm8gICAgICAgICAgICAgICAg
ICAtIHNob3cgYXZhaWxhYmxlIE5BTkQgZGV2aWNlcw0KbmFuZCBkZXZpY2UgW2Rldl0gICAgIC0g
c2hvdyBvciBzZXQgY3VycmVudCBkZXZpY2UNCm5hbmQgcmVhZFsuamZmczJdICAgICAtIGFkZHIg
b2ZmfHBhcnRpdGlvbiBzaXplDQpuYW5kIHdyaXRlWy5qZmZzMl0gICAgLSBhZGRyIG9mZnxwYXJ0
aXRpb24gc2l6ZSAtIHJlYWQvd3JpdGUgYHNpemUnIGJ5dGVzIHN0YXJ0aW5nDQogICAgYXQgb2Zm
c2V0IGBvZmYnIHRvL2Zyb20gbWVtb3J5IGFkZHJlc3MgYGFkZHInDQpuYW5kIGVyYXNlIFtjbGVh
bl0gW29mZiBzaXplXSAtIGVyYXNlIGBzaXplJyBieXRlcyBmcm9tDQogICAgb2Zmc2V0IGBvZmYn
IChlbnRpcmUgZGV2aWNlIGlmIG5vdCBzcGVjaWZpZWQpDQpuYW5kIGJhZCAtIHNob3cgYmFkIGJs
b2Nrcw0KbmFuZCBkdW1wWy5vb2JdIG9mZiAtIGR1bXAgcGFnZQ0KbmFuZCBzY3J1YiAtIHJlYWxs
eSBjbGVhbiBOQU5EIGVyYXNpbmcgYmFkIGJsb2NrcyAoVU5TQUZFKQ0KbmFuZCBtYXJrYmFkIG9m
ZiAtIG1hcmsgYmFkIGJsb2NrIGF0IG9mZnNldCAoVU5TQUZFKQ0KbmFuZCBiaXRlcnIgb2ZmIC0g
bWFrZSBhIGJpdCBlcnJvciBhdCBvZmZzZXQgKFVOU0FGRSkNCm5hbmQgbG9jayBbdGlnaHRdIFtz
dGF0dXNdIC0gYnJpbmcgbmFuZCB0byBsb2NrIHN0YXRlIG9yIGRpc3BsYXkgbG9ja2VkIHBhZ2Vz
DQpuYW5kIHVubG9jayBbb2Zmc2V0XSBbc2l6ZV0gLSB1bmxvY2sgc2VjdGlvbg0KDQpFaG9tZXRl
Y2ggI25hbmQgZXJhc2UNCg0KTkFORCBlcmFzZTogZGV2aWNlIDAgd2hvbGUgY2hpcA0KRXJhc2lu
ZyBhdCAweDNmZmMwMDAwIC0tIDEwMCUgY29tcGxldGUuDQpPSw0KRWhvbWV0ZWNoICNuYW5kIGJh
ZA0KDQpEZXZpY2UgMCBiYWQgYmxvY2tzOg0KRWhvbWV0ZWNoICN0ZnRwIDEwMDAwMDAgcm9vdC1w
MmstYjRrLmpmZnMyDQpUU0VDMDogTm8gbGluay4NClNwZWVkOiAxMDAwLCBmdWxsIGR1cGxleA0K
VXNpbmcgVFNFQzEgZGV2aWNlDQpURlRQIGZyb20gc2VydmVyIDE5Mi4xNjguMC4yMDA7IG91ciBJ
UCBhZGRyZXNzIGlzIDE5Mi4xNjguMC4yMjANCkZpbGVuYW1lICdyb290LXAyay1iNGsuamZmczIn
Lg0KTG9hZCBhZGRyZXNzOiAweDEwMDAwMDANCkxvYWRpbmc6IFQgVCAjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KICAgICAg
ICAgIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMNCiAgICAgICAgICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQogICAgICAgICAjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KICAgICAg
ICAgIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMNCiAgICAgICAgICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIw0KZG9uZQ0KQnl0ZXMgdHJhbnNmZXJyZWQgPSA1MzgzNjUyICg1MjI1ZTQgaGV4KQ0K
RWhvbWV0ZWNoICNuYW5kIHdyaXRlLmpmZnMyIDEwMDAwMDAgMCA1MjI1ZTQNCg0KTkFORCB3cml0
ZTogZGV2aWNlIDAgb2Zmc2V0IDB4MCwgc2l6ZSAweDUyMjVlNA0KDQpXcml0aW5nIGRhdGEgYXQg
MHgxYTAwMCAtLSAgIDIlIGNvbXBsZXRlLndyaXRpbmcgTkFORCBwYWdlIGF0IG9mZnNldCAweDIw
MDAwIGZhaWxlZA0KRGF0YSBkaWQgbm90IGZpdCBpbnRvIGRldmljZSwgZHVlIHRvIGJhZCBibG9j
a3MNCiA1MzgzNjUyIGJ5dGVzIHdyaXR0ZW46IEVSUk9SDQpFaG9tZXRlY2ggI25hbmQgZGV2aWNl
DQoNCkRldmljZSAwOiBOQU5EIDFHaUIgMywzViA4LWJpdA0KRWhvbWV0ZWNoICMNCg0KLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8NCiAgICBCdXQgdGhlIG5hbmQgZmxhc2gg
aGFzIG5vIGJhZCBibG9ja3Mgd2hlbiBJIHVzZSAibmFuZCBiYWQiY29tbWFuZC4gDQpyb290LXAy
ay1iNGsuamZmczIgaXMgdGhlIGpmZnMyIGZpbGVzeXN0ZW0gbWFkZSBieSBta2ZzLmpmZnMyIC1l
IDB4NDAwMDAgDQogDQogICBUaGFuayB5b3UhQmVzdCB3aXNoZXMuDQogICANCiAgIEJvYiB5dSAN
CiAgIDIwMDgtNC0yMg0KICAgICA=

^ permalink raw reply

* Re: [PATCH 1/3] Raise the upper limit of NR_CPUS.
From: Stephen Rothwell @ 2008-04-22  3:50 UTC (permalink / raw)
  To: Tony Breeds; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <767e424a294239aba86aa7da086f6395f7066d14.1208834828.git.tony@bakeyournoodle.com>

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

Hi Tony,

On Tue, 22 Apr 2008 13:30:06 +1000 (EST) Tony Breeds <tony@bakeyournoodle.com> wrote:
>
> +void __init initialise_pacas(void)
> +{
> +	int cpu;
> +	unsigned long kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL;

This line could do with a comment saying what it is doing ...

> +++ b/include/asm-powerpc/paca.h
>
> +#if   NR_CPUS >= 32
> +#define NR_STATIC_PACAS	64

This allocates 64 pacas etc for NR_CPUS == 32 so surely that test should
be >?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: [PATCH 2/3] Make iSeries spin on __secondary_hold_spinloop, like pSeries.
From: Stephen Rothwell @ 2008-04-22  4:02 UTC (permalink / raw)
  To: Tony Breeds; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <7be4c4c6f56d04b595c92690b297de17140304d2.1208834828.git.tony@bakeyournoodle.com>

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

Hi Tony,

On Tue, 22 Apr 2008 13:30:06 +1000 (EST) Tony Breeds <tony@bakeyournoodle.com> wrote:
>
> Currently all iSeries secondary CPU's spin directly on the cpu_start in thier
> paca.  Make them spin on the global __secondary_hold_spinloop, until after the
> pacas have been initialised.
> 
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>

Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>

(Noting that the __secondary_hold_spinloop variable was already being set
for legacy iSeries even though it was not being used previously.)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: eldk and usb to serial converters
From: Daniel Stonier @ 2008-04-22  4:23 UTC (permalink / raw)
  To: Detlev Zundel, linuxppc-embedded
In-Reply-To: <m2r6cz45ki.fsf@ohwell.denx.de>

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

Just discovered that this morning! Had made the assumption it was
automatically enabled, but only clued onto it when I noticed udevmonitor
wasn't giving only UEVENT output, not UDEV output. Should have been obvious,
but I kept barking up the wrong tree!

So, turning out to be a good chance to learn how the lower levels of a linux
system work and managed to learn exactly how udev works while stumbling on
this one.
Thanks for the reply

2008/4/21 Detlev Zundel <dzu@denx.de>:

> Hi Daniel,
>
> > I'm currently trying to compile a kernel for an AMCC440EP board within
> an eldk
> > environment. We've got a FTDI usb2serial converter we need to connect to
> the
> > board. Now I've compiled a kernel on a gentoo machine for this device
> and had
> > no problems. With this board, the kernel recognizes the device fine:
> >
> > ftdi_sio 1-1:1.0: FTDI USB Serial Device converter detected
> > usb 1-1: FTDI USB Serial Device converter now attached to ttyUSB0
> > drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver
> >
> > but udev doesn't actually make the ttyUSB0 node. If anyone knows what
> may have
> > caused the problem and how to fix it, it'd be much appreciated.
>
> Maybe udev isn't running at all?  The ELDKs including udev disable it
> per default (what version are you using?).  Embedded systeme like to
> have static kernel configurations presenting no surprises at runtime...
>
> Cheers
>  Detlev
>
> --
> Programming X-Windows is like trying to find the square root of pi
> using roman numerals.
>                                          -- The UNIX Haters Handbook
> --
> DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>

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

^ permalink raw reply

* RE: [PATCH 1/3] MSI driver for Freescale 83xx/85xx/86xx cpu
From: Michael Ellerman @ 2008-04-22  4:35 UTC (permalink / raw)
  To: Jin Zhengxiong; +Cc: linuxppc-dev list, Kumar Gala
In-Reply-To: <CC27DED0F8F39E48A7E75FD768688B7A874E57@zch01exm27.fsl.freescale.net>

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

On Mon, 2008-04-21 at 18:01 +0800, Jin Zhengxiong wrote:
> Hi, Michael,
> 
> Thank you very much for you input, please see my inline answer.

No worries.

> > > +static int fsl_msi_reserve_dt_hwirqs(struct fsl_msi *msi)
> > > +{
> > > +	int i, len;
> > > +	const u32 *p;
> > > +
> > > +	p = of_get_property(msi->of_node, "msi-available-ranges", &len);
> > > +	if (!p) {
> > > +		pr_debug("fsl_msi: no msi-available-ranges 
> > property found \
> > > +				on %s\n", msi->of_node->full_name);
> > > +		return -ENODEV;
> > > +	}
> > > +
> > > +	if (len & 0x8 != 0) {
> > > +		printk(KERN_WARNING "fsl_msi: Malformed 
> > msi-available-ranges "
> > > +		       "property on %s\n", msi->of_node->full_name);
> > > +		return -EINVAL;
> > > +	}
> > 
> > Do you really want a bitwise and with 0x8?
> > 
> The range for the msi interrupt can be seperated to several part. 
> This can used to check the if the ranges is correct. 

I don't see how. AFAIK the "msi-available-ranges" property is just a
list of u32 pairs, so the only thing that makes sense is to check that
the length is a multiple of 8, not that it has the 3rd bit set.

> > > +static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
> > > +				  struct msi_msg *msg)
> > > +{
> > > +	unsigned int srs;
> > > +	unsigned int ibs;
> > > +	struct fsl_msi *msi = fsl_msi;
> > > +
> > > +	srs = hwirq / INT_PER_MSIR;
> > > +	ibs = hwirq % INT_PER_MSIR;
> > > +
> > > +	msg->address_lo = msi->msi_addr_lo;
> > > +	msg->address_hi = msi->msi_addr_hi;
> > > +	msg->data = (srs << 5) | (ibs & 0x1F);
> > 
> > Is the 5 and 0x1F independent of the INT_PER_MSIR value? Given the
> > current values isn't this a no-op, or am I missing something?
> > 
> Do you mean there're another way to get the msg->data from the hwirq?  

No I mean I'm confused about the maths here. If we pull out the
variables it boils down to:

data = ((hwirq / 32) << 5) | ((hwirq % 32) & 0x1F)

Which doesn't seem to actually do anything?

> > > +static int fsl_setup_msi_irqs(struct pci_dev *pdev, int 
> > nvec, int type)
> > > +{
> > > +	irq_hw_number_t hwirq;
> > > +	int rc;
> > > +	unsigned int virq;
> > > +	struct msi_desc *entry;
> > > +	struct msi_msg msg;
> > > +	struct fsl_msi *msi = fsl_msi;
> > 
> > A couple of places you put this into a local called "msi" 
> > which is not the
> > greatest name in the world IMHO :)
> > 
> Thank you, I'll try to use another name, Do you have any suggestion?

Oh I dunno, maybe msi_data or msi_state ? 


cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: Help! mpc8247 porting kernel 2.6.25 problem.
From: 张世乐 @ 2008-04-22  5:10 UTC (permalink / raw)
  To: Scott Wood; +Cc: Linuxppc-embedded
In-Reply-To: <20080421173450.GC4134@ld0162-tx32.am.freescale.net>

VGhhbmsgeW91LCBEb2N0b3IgU2NvdHQuIEknbSB2ZXJ5IGdyYXRlZnVsIHRvIHlvdSBmb3IgeW91
IGtpbmRseSBoZWxwLgoKSSdsbCB0cnkgdGhlIHdheSB5b3Ugc3VnZ2VzdGVkIHNvb24uCgpBbmQs
IG15IGNvZGUgZm9yIGxpZ2h0IHRoZSBsZWQgcnVuIGFzIGZvbGxvd3M6Cgp2b2lkIHNldF9sZWRf
YV9yZWQodm9pZCkKewoJLypQRElSQzogMHhmYzAxMGQ0MCovCgkvKlBQQVJDOiAweGZjMDEwZDQ0
Ki8KCS8qUE9EUkM6IDB4ZmMwMTBkNGMqLwoJLypQREFUQzogMHhmYzAxMGQ1MCovCgkqKCh1bnNp
Z25lZCBsb25nICopKDB4ZmIwMTBkNDApKSB8PSAweDAwMDAwMGQ0OwoJKigodW5zaWduZWQgbG9u
ZyAqKSgweGZiMDEwZDQ0KSkgJj0gfjB4MDAwMDAwZDQ7CgkqKCh1bnNpZ25lZCBsb25nICopKDB4
ZmIwMTBkNGMpKSAmPSB+MHgwMDAwMDBkNDsKCSooKHVuc2lnbmVkIGxvbmcgKikoMHhmYjAxMGQ1
MCkpIHw9IDB4MDAwMDAwMDQ7CgkqKCh1bnNpZ25lZCBsb25nICopKDB4ZmIwMTBkNTApKSAmPSB+
MHgwMDAwMDAxMDsKfQouLi4KCkkgcHV0IGlzIGluIHRoZSBmaWxlIGFyY2gvcG93ZXIva2VybmVs
L3NldHVwXzMyLmMsIGlzIHRoaXMgT0s/CkFuZCBJIGNhbGwgaXQgaW4gdGhlIHNldHVwX2NvbW1v
bl9jYWNoZXMgYXMgZm9sbG93cwouLi4KYmwgICAgICAgIHNldF9sZWRfYV9yZWQKbXRzcHIgIFNQ
Uk5fSElEMCwgcjgKYmwgICAgICAgIHNldF9sZWRfYV9ncmVlbgoKSSd2ZSB0cmllZCB0byBjb21w
aWxlIHRoZSBrZXJuZWwgd2l0aCBlbmFibGUgdGhlIGVhcmx5IGRlYnVnIHByaW5rLiBidXQgaXQK
b3V0cHV0IG5vdGhpbmcuIG1heWJlIEkgbWFrZSBzb21lIGZvb2xpc2ggbWlzdGFrZSBpbiBjb25m
aWd1cmF0ZSB0aGUKQ1BNIFVBUlQgZWFybHkgZGVidWcgdHJhbnNtaXQgZGVzY3JpcHRvciBhZGRy
ZXNzLgoKVGhhbmtzIGFnYWluLiBJdCByZWFsbHkgdmVyeSBraW5kIG9mIHlvdSB0byBnaXZlIG1l
IHNvbWUgc3VnZ2VzdGlvbnMuCgoyMDA4LzQvMjIgU2NvdHQgV29vZCA8c2NvdHR3b29kQGZyZWVz
Y2FsZS5jb20+Ogo+IE9uIE1vbiwgQXByIDIxLCAyMDA4IGF0IDExOjA2OjI4QU0gKzA4MDAsINXF
ysDA1iB3cm90ZToKPiAgPiBVbmNvbXByZXNzaW5nIEtlcm5lbCBJbWFnZSAuLi4gT0sKPiAgPiBC
b290aW5nIHVzaW5nIHRoZSBmZHQgYXQgMHg2MDAwMDAKPiAgPgo+ICA+IFtub3RoaW5nIG91dHB1
dCBhbmQgaGFuZ2luZyBoZXJlXQo+ICA+Cj4gID4gSSB1c2UgdGhlIGxlZCBvbiB0aGUgYm9hcmQg
dG8gdHJhY2UgdGhlIGtlcm5lbCBmdW5kIGl0IHN0b3AgaW4gdGhlIGZ1bmN0aW9uCj4gID4KPiAg
PiBzZXR1cF9jb21tb25fY2FjaGVzICBpbiBhcmNoL3Bvd2VycGMva2VybmVsL2NwdV9zZXR1cF82
eHguUwo+ICA+Cj4gID4gQ2FuIHlvdSBnaXZlIG1lIHNvbWUgaWRlYXM/Cj4KPiAgVGhhdCdzIHBy
b2JhYmx5IG5vdCB3aGVyZSBpdCdzIGFjdHVhbGx5IHN0b3BwaW5nLCBidXQgcmF0aGVyIHdoZXJl
IGNhY2hlcwo+ICBhcmUgZW5hYmxlZCB3aXRob3V0IHRoZSBNTVUsIHRodXMgbWFraW5nIGl0IGRp
ZmZpY3VsdCB0byBhY2Nlc3MgZGV2aWNlcy4KPiAgWW91IGNhbiB0cnkgcGxhY2luZyBhIGRjYmYg
YWZ0ZXIgZWFjaCB3cml0ZSB0byB0aGUgTEVEIHJlZ2lzdGVyLCB0aG91Z2gKPiAgdGhpcyBtYXkg
cGVydHVyYiBuZWFyYnkgcmVnaXN0ZXJzLgo+Cj4gIEhhdmUgeW91IHRyaWVkIGVuYWJsaW5nIGVh
cmx5IGRlYnVnIHByaW50az8KPgo+ICAtU2NvdHQKPgo=

^ permalink raw reply

* Re: [PATCH] [POWERPC] AMCC Kilauea (405EX): Disable EMAC loopback mode
From: Stefan Roese @ 2008-04-22  5:15 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev
In-Reply-To: <1208821568.9640.67.camel@pasglop>

On Tuesday 22 April 2008, Benjamin Herrenschmidt wrote:
> On Sat, 2008-02-23 at 08:27 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2008-02-22 at 09:32 +0100, Stefan Roese wrote:
> > > 405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
> > > the internal loopback mode. Clear these bits so that both EMACs
> > > don't use loopback mode as default.
> > >
> > > Signed-off-by: Stefan Roese <sr@denx.de>
> > > ---
> > > I'm not sure if this should be done here in the board platform code,
> > > or in the newemac driver or perhaps in some code common for 405EX.
> > >
> > > Any thoughts on this welcome.
> >
> > This should be done in EMAC since we also need to force internal
> > loopback & clocking when probing the PHY or we might not probe
> > it properly (and fail reset) if there is no link.
>
> Is that patch still needed if I apply Valentine patches ? I'm fixing
> them up so they don't break DCR MMIO anymore.

Great. I will send an additional patch to take care of this 405EX(r) loopback 
issue once your version of Valentines patches is available.

Best regards,
Stefan

^ permalink raw reply

* RE: [PATCH 1/3] MSI driver for Freescale 83xx/85xx/86xx cpu
From: Jin Zhengxiong @ 2008-04-22  5:15 UTC (permalink / raw)
  To: michael; +Cc: linuxppc-dev list, Gala Kumar
In-Reply-To: <1208838916.12660.10.camel@concordia.ozlabs.ibm.com>

=20

> -----Original Message-----
> From: Michael Ellerman [mailto:michael@ellerman.id.au]=20
> Sent: Tuesday, April 22, 2008 12:35 PM
> To: Jin Zhengxiong
> Cc: linuxppc-dev list; Gala Kumar
> Subject: RE: [PATCH 1/3] MSI driver for Freescale 83xx/85xx/86xx cpu
>=20
> On Mon, 2008-04-21 at 18:01 +0800, Jin Zhengxiong wrote:
> > Hi, Michael,
> >=20
> > Thank you very much for you input, please see my inline answer.
>=20
> No worries.
>=20
> > > > +static int fsl_msi_reserve_dt_hwirqs(struct fsl_msi *msi) {
> > > > +	int i, len;
> > > > +	const u32 *p;
> > > > +
> > > > +	p =3D of_get_property(msi->of_node,=20
> "msi-available-ranges", &len);
> > > > +	if (!p) {
> > > > +		pr_debug("fsl_msi: no msi-available-ranges
> > > property found \
> > > > +				on %s\n",=20
> msi->of_node->full_name);
> > > > +		return -ENODEV;
> > > > +	}
> > > > +
> > > > +	if (len & 0x8 !=3D 0) {
> > > > +		printk(KERN_WARNING "fsl_msi: Malformed
> > > msi-available-ranges "
> > > > +		       "property on %s\n",=20
> msi->of_node->full_name);
> > > > +		return -EINVAL;
> > > > +	}
> > >=20
> > > Do you really want a bitwise and with 0x8?
> > >=20
> > The range for the msi interrupt can be seperated to several part.=20
> > This can used to check the if the ranges is correct.=20
>=20
> I don't see how. AFAIK the "msi-available-ranges" property is=20
> just a list of u32 pairs, so the only thing that makes sense=20
> is to check that the length is a multiple of 8, not that it=20
> has the 3rd bit set.
>=20
I found the problem. I'll check the length if it's a multiple of 8.
Thanks

> > > > +static void fsl_compose_msi_msg(struct pci_dev *pdev,=20
> int hwirq,
> > > > +				  struct msi_msg *msg)
> > > > +{
> > > > +	unsigned int srs;
> > > > +	unsigned int ibs;
> > > > +	struct fsl_msi *msi =3D fsl_msi;
> > > > +
> > > > +	srs =3D hwirq / INT_PER_MSIR;
> > > > +	ibs =3D hwirq % INT_PER_MSIR;
> > > > +
> > > > +	msg->address_lo =3D msi->msi_addr_lo;
> > > > +	msg->address_hi =3D msi->msi_addr_hi;
> > > > +	msg->data =3D (srs << 5) | (ibs & 0x1F);
> > >=20
> > > Is the 5 and 0x1F independent of the INT_PER_MSIR value?=20
> Given the=20
> > > current values isn't this a no-op, or am I missing something?
> > >=20
> > Do you mean there're another way to get the msg->data from=20
> the hwirq? =20
>=20
> No I mean I'm confused about the maths here. If we pull out=20
> the variables it boils down to:
>=20
> data =3D ((hwirq / 32) << 5) | ((hwirq % 32) & 0x1F)
>=20
> Which doesn't seem to actually do anything?
>=20
Thanks, The hwirq number can stand for the data to the msiir in this
case.
I'll change this.

^ permalink raw reply

* Re: [PATCH v2] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
From: Stefan Roese @ 2008-04-22  5:17 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev
In-Reply-To: <1208812591.9640.45.camel@pasglop>

On Monday 21 April 2008, Benjamin Herrenschmidt wrote:
> On Mon, 2008-04-21 at 16:54 +0200, Stefan Roese wrote:
> > --------------
> > - As suggested by Benjamin Herrenschmidt, don't determine endpoint mode
> >   by looking at the already configured PCIe port state, but evaluate
> >   the device_type property instead. This makes it possible for boards
> >   without a previously run PCIe configuration (e.g. U-Boot) to configure
> >   a port as endpoint as well.
> >
> > - Don't map the big external config space upon endpoint configuration.
> >
> > - Introduce "vendor-id" and "device-id" properties to be written to
> >   the host bridge.
>
> and class-code too ?

Sure, could be done. But this is not really endpoint/root-complex related. So 
I suggest to add this later with an additional patch.

> Appart from that, I'll have a quick look at the patch later today but at
> first it looks good.

Thanks.

Best regards,
Stefan

^ permalink raw reply

* Re: [PATCH 1/3] Raise the upper limit of NR_CPUS.
From: Tony Breeds @ 2008-04-22  5:55 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080422135005.16b4a65d.sfr@canb.auug.org.au>

On Tue, Apr 22, 2008 at 01:50:05PM +1000, Stephen Rothwell wrote:
> Hi Tony,
> 
> On Tue, 22 Apr 2008 13:30:06 +1000 (EST) Tony Breeds <tony@bakeyournoodle.com> wrote:
> >
> > +void __init initialise_pacas(void)
> > +{
> > +	int cpu;
> > +	unsigned long kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL;
> 
> This line could do with a comment saying what it is doing ...

It does need a comment I agree, but I don't think I can do it justice :)
... I just used what was already there.
 
> > +++ b/include/asm-powerpc/paca.h
> >
> > +#if   NR_CPUS >= 32
> > +#define NR_STATIC_PACAS	64
> 
> This allocates 64 pacas etc for NR_CPUS == 32 so surely that test should
> be >?

Yes it should be.

Yours Tony

  linux.conf.au    http://www.marchsouth.org/
  Jan 19 - 24 2009 The Australian Linux Technical Conference!

^ permalink raw reply

* Re: Patches added to powerpc.git master and powerpc-next branches
From: Benjamin Herrenschmidt @ 2008-04-22  7:56 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <C69E510D-5838-4BE6-AB57-56FCB0592414@kernel.crashing.org>


On Mon, 2008-04-21 at 12:51 -0500, Kumar Gala wrote:

> I'm not clear on why this is needed.  I can see value in having the  
> PGD entry in place but the pte PAs would be changing all the time so
> I  
> don't see what benefit there is in keeping them in one page.

Because they are accessed as an array by the C code ?

Ben.

^ permalink raw reply

* Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib
From: Laurent Pinchart @ 2008-04-22  8:55 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev, netdev
In-Reply-To: <20080421175627.GD4134@ld0162-tx32.am.freescale.net>

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

On Monday 21 April 2008 19:56, Scott Wood wrote:
> On Fri, Apr 18, 2008 at 01:34:29PM +0200, Laurent Pinchart wrote:
> > Scott Wood was concerned in 
> > http://patchwork.ozlabs.org/linuxppc/patch?id=17490 that the gpio lib
> > might be an unnecessary burden for memory-constraint platforms. Should we
> > keep two mdio bitbang drivers, one with direct access to the ports and one
> > using gpio lib ? The later solves the concurrent access issues present in
> > the current fs_enet mdio bitbang driber.
> 
> The memory-constrained platform I had in mind was 8xx, which doesn't use
> bitbanged MDIO.  It might nice to keep the gpiolib bit separate to avoid
> situations such as ep8248e where mdiobb would be the only thing requiring
> a gpiolib binding, though -- but it shouldn't be two separate bitbang
> drivers, just the existing bitbang driver plus some glue code that binds
> it to gpiolib.

I would be fine with that if the glue code wasn't 90% of the whole driver. 
There is really little (not to say nothing) that can be shared between the 
two drivers.

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* [PATCH v2] MSI driver for Freescale 83xx/85xx/86xx cpu
From: Jason Jin @ 2008-04-22  9:37 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: kumar.gala, Jason Jin

This MSI driver can be used on 83xx/85xx/86xx board.
In this driver, virtual interrupt host and chip were
setup. There are 256 MSI interrupts in this host, Every 32
MSI interrupts cascaded to one IPIC/MPIC interrupt.
The chip was treated as edge sensitive and some necessary
functions were setup for this chip.

Before using the MSI interrupt, PCI/PCIE device need to
ask for a MSI interrupt in the 256 MSI interrupts. A 256bit
bitmap show which MSI interrupt was used, reserve bit in
the bitmap can be used to force the device use some designate
MSI interrupt in the 256 MSI interrupts. Sometimes this is useful
for testing the all the MSI interrupts. The msi-available-ranges
property in the dts file was used for this purpose.

Signed-off-by: Jason Jin <Jason.jin@freescale.com>
---
Changes in v2: 
  Coding style changing and bug fixing suggested by Michael Ellerman.

 arch/powerpc/sysdev/Makefile  |    1 +
 arch/powerpc/sysdev/fsl_msi.c |  430 +++++++++++++++++++++++++++++++++++++++++
 arch/powerpc/sysdev/fsl_msi.h |   36 ++++
 arch/powerpc/sysdev/fsl_pci.c |   14 ++
 4 files changed, 481 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/sysdev/fsl_msi.c
 create mode 100644 arch/powerpc/sysdev/fsl_msi.h

diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 6d386d0..e60a238 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -4,6 +4,7 @@ endif
 
 mpic-msi-obj-$(CONFIG_PCI_MSI)	+= mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
 obj-$(CONFIG_MPIC)		+= mpic.o $(mpic-msi-obj-y)
+obj-$(CONFIG_FSL_PCI)		+= fsl_msi.o
 
 obj-$(CONFIG_PPC_MPC106)	+= grackle.o
 obj-$(CONFIG_PPC_DCR_NATIVE)	+= dcr-low.o
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
new file mode 100644
index 0000000..91cf08e
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -0,0 +1,430 @@
+/*
+ * Copyright (C) 2007-2008 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Tony Li <tony.li@freescale.com>
+ *	   Jason Jin <Jason.jin@freescale.com>
+ *
+ * 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; version 2 of the
+ * License.
+ *
+ */
+#include <linux/irq.h>
+#include <linux/bootmem.h>
+#include <linux/bitmap.h>
+#include <linux/msi.h>
+#include <linux/pci.h>
+#include <linux/of_platform.h>
+#include <sysdev/fsl_soc.h>
+#include <asm/prom.h>
+#include <asm/hw_irq.h>
+#include <asm/ppc-pci.h>
+#include "fsl_msi.h"
+
+/* A bit ugly, can we get this from the pci_dev somehow? */
+static struct fsl_msi *fsl_msi;
+
+static inline u32 fsl_msi_read(u32 __iomem *base, unsigned int reg)
+{
+	return in_be32(base + (reg >> 2));
+}
+
+static inline void fsl_msi_write(u32 __iomem *base,
+				unsigned int reg, u32 value)
+{
+	out_be32(base + (reg >> 2), value);
+}
+
+/*
+ * We do not need this actually. The MSIR register has been read once
+ * in the cascade interrupt. So, this MSI interrupt has been acked
+*/
+static void fsl_msi_end_irq(unsigned int virq)
+{
+}
+
+static struct irq_chip fsl_msi_chip = {
+	.mask		= mask_msi_irq,
+	.unmask		= unmask_msi_irq,
+	.ack		= fsl_msi_end_irq,
+	.typename	= " FSL-MSI  ",
+};
+
+static int fsl_msi_host_match(struct irq_host *h, struct device_node *node)
+{
+	/* Exact match, unless node is NULL */
+	return h->of_node == NULL || h->of_node == node;
+}
+
+
+static int fsl_msi_host_map(struct irq_host *h, unsigned int virq,
+				irq_hw_number_t hw)
+{
+	struct fsl_msi *msi_data = h->host_data;
+	struct irq_chip *chip = &fsl_msi_chip;
+
+	get_irq_desc(virq)->status |= IRQ_TYPE_EDGE_FALLING;
+
+	set_irq_chip_and_handler(virq, chip,  handle_edge_irq);
+
+	return 0;
+}
+
+static struct irq_host_ops fsl_msi_host_ops = {
+	.match = fsl_msi_host_match,
+	.map = fsl_msi_host_map,
+};
+
+irq_hw_number_t fsl_msi_alloc_hwirqs(struct fsl_msi *msi, int num)
+{
+	unsigned long flags;
+	int offset, order = get_count_order(num);
+
+	spin_lock_irqsave(&msi->bitmap_lock, flags);
+
+	offset = bitmap_find_free_region(msi->fsl_msi_bitmap,
+					NR_MSI_IRQS, order);
+
+	spin_unlock_irqrestore(&msi->bitmap_lock, flags);
+
+	pr_debug("%s: allocated 0x%x (2^%d) at offset 0x%x\n",
+		__func__, num, order, offset);
+
+	return offset;
+}
+
+void fsl_msi_free_hwirqs(struct fsl_msi *msi, int offset, int num)
+{
+	unsigned long flags;
+	int order = get_count_order(num);
+
+	pr_debug("%s: freeing 0x%x (2^%d) at offset 0x%x\n",
+		__func__, num, order, offset);
+
+	spin_lock_irqsave(&msi->bitmap_lock, flags);
+	bitmap_release_region(msi->fsl_msi_bitmap, offset, order);
+	spin_unlock_irqrestore(&msi->bitmap_lock, flags);
+}
+
+static int fsl_msi_free_dt_hwirqs(struct fsl_msi *msi)
+{
+	int i, len;
+	const u32 *p;
+
+	p = of_get_property(msi->of_node, "msi-available-ranges", &len);
+	if (!p) {
+		pr_debug("fsl_msi: no msi-available-ranges property found \
+				on %s\n", msi->of_node->full_name);
+		return -ENODEV;
+	}
+
+	if ((len % 0x8) != 0) {
+		printk(KERN_WARNING "fsl_msi: Malformed msi-available-ranges "
+		       "property on %s\n", msi->of_node->full_name);
+		return -EINVAL;
+	}
+
+	bitmap_allocate_region(msi->fsl_msi_bitmap, 0,
+			       get_count_order(NR_MSI_IRQS));
+
+	/* Format is: (<u32 start> <u32 count>)+ */
+	len /= sizeof(u32);
+	len /= 2;
+	for (i = 0; i < len; i++, p += 2)
+		fsl_msi_free_hwirqs(msi, *p, *(p + 1));
+
+	return 0;
+}
+
+static int fsl_msi_init_allocator(struct fsl_msi *msi_data)
+{
+	int rc, size;
+
+	size = BITS_TO_LONGS(NR_MSI_IRQS) * sizeof(long);
+
+	msi_data->fsl_msi_bitmap = kzalloc(size, GFP_KERNEL);
+
+	if (msi_data->fsl_msi_bitmap == NULL) {
+		pr_debug("%s: ENOMEM allocating allocator bitmap!\n",
+				__func__);
+		return -ENOMEM;
+	}
+
+	rc = fsl_msi_free_dt_hwirqs(msi_data);
+	if (rc)
+		goto out_free;
+
+	return 0;
+out_free:
+	kfree(msi_data->fsl_msi_bitmap);
+
+	msi_data->fsl_msi_bitmap = NULL;
+	return rc;
+
+}
+
+static int fsl_msi_check_device(struct pci_dev *pdev, int nvec, int type)
+{
+	if (type == PCI_CAP_ID_MSIX)
+		pr_debug("fslmsi: MSI-X untested, trying anyway.\n");
+
+	return 0;
+}
+
+static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
+{
+	struct msi_desc *entry;
+	struct fsl_msi *msi_data = fsl_msi;
+
+	list_for_each_entry(entry, &pdev->msi_list, list) {
+		if (entry->irq == NO_IRQ)
+			continue;
+		set_irq_msi(entry->irq, NULL);
+		fsl_msi_free_hwirqs(msi_data, virq_to_hw(entry->irq), 1);
+		irq_dispose_mapping(entry->irq);
+	}
+
+	return;
+}
+
+static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
+				  struct msi_msg *msg)
+{
+	struct fsl_msi *msi_data = fsl_msi;
+
+	msg->address_lo = msi_data->msi_addr_lo;
+	msg->address_hi = msi_data->msi_addr_hi;
+	msg->data = hwirq;
+
+	pr_debug("%s: allocated srs: %d, ibs: %d\n",
+		__func__, hwirq / INT_PER_MSIR, hwirq % INT_PER_MSIR);
+}
+
+static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
+{
+	irq_hw_number_t hwirq;
+	int rc;
+	unsigned int virq;
+	struct msi_desc *entry;
+	struct msi_msg msg;
+	struct fsl_msi *msi_data = fsl_msi;
+
+	list_for_each_entry(entry, &pdev->msi_list, list) {
+		hwirq = fsl_msi_alloc_hwirqs(msi_data, 1);
+		if (hwirq < 0) {
+			rc = hwirq;
+			pr_debug("%s: fail allocating msi interrupt\n",
+					__func__);
+			goto out_free;
+		}
+
+		virq = irq_create_mapping(msi_data->irqhost, hwirq);
+
+		if (virq == NO_IRQ) {
+			pr_debug("%s: fail mapping hwirq 0x%lx\n",
+					__func__, hwirq);
+			fsl_msi_free_hwirqs(msi_data, hwirq, 1);
+			rc = -ENOSPC;
+			goto out_free;
+		}
+		set_irq_msi(virq, entry);
+
+		fsl_compose_msi_msg(pdev, hwirq, &msg);
+		write_msi_msg(virq, &msg);
+	}
+	return 0;
+
+out_free:
+	return rc;
+}
+
+void fsl_msi_cascade(unsigned int irq, struct irq_desc *desc)
+{
+	unsigned int cascade_irq;
+	struct fsl_msi *msi_data = fsl_msi;
+	int msir_index = -1;
+	u32 msir_value = 0;
+	u32 intr_index;
+	u32 have_shift = 0;
+
+	spin_lock(&desc->lock);
+	if ((msi_data->feature &  FSL_PIC_IP_MASK) == FSL_PIC_IP_IPIC) {
+		if (desc->chip->mask_ack)
+			desc->chip->mask_ack(irq);
+		else {
+			desc->chip->mask(irq);
+			desc->chip->ack(irq);
+		}
+	}
+
+	if (unlikely(desc->status & IRQ_INPROGRESS))
+		goto unlock;
+
+	msir_index = (int)(desc->handler_data);
+
+	if (msir_index >= NR_MSIR)
+		cascade_irq = NO_IRQ;
+
+	desc->status |= IRQ_INPROGRESS;
+	switch (fsl_msi->feature & FSL_PIC_IP_MASK) {
+	case FSL_PIC_IP_MPIC:
+		msir_value = fsl_msi_read(msi_data->msi_regs,
+			msir_index * 0x10);
+		break;
+	case FSL_PIC_IP_IPIC:
+		msir_value = fsl_msi_read(msi_data->msi_regs, msir_index * 0x4);
+		break;
+	}
+
+	while (msir_value) {
+		intr_index = ffs(msir_value) - 1;
+
+		cascade_irq = irq_linear_revmap(msi_data->irqhost,
+			(msir_index * INT_PER_MSIR + intr_index + have_shift));
+
+		if (cascade_irq != NO_IRQ)
+			generic_handle_irq(cascade_irq);
+		have_shift += (intr_index + 1);
+		msir_value = (msir_value >> (intr_index + 1));
+	}
+	desc->status &= ~IRQ_INPROGRESS;
+
+	switch (msi_data->feature & FSL_PIC_IP_MASK) {
+	case FSL_PIC_IP_MPIC:
+		desc->chip->eoi(irq);
+		break;
+	case FSL_PIC_IP_IPIC:
+		if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
+			desc->chip->unmask(irq);
+		break;
+	}
+unlock:
+	spin_unlock(&desc->lock);
+}
+
+static int __devinit fsl_of_msi_probe(struct of_device *dev,
+				const struct of_device_id *match)
+{
+	struct fsl_msi *msi;
+	struct resource res;
+	int err, i, count;
+	int rc;
+	int virt_msir;
+	const u32 *p;
+	struct fsl_msi_feature *tmp_data;
+
+	printk(KERN_DEBUG "Setting up fsl msi support\n");
+
+	msi = kzalloc(sizeof(struct fsl_msi), GFP_KERNEL);
+	if (!msi) {
+		dev_err(&dev->dev, "No memory for MSI structure\n");
+		err = -ENOMEM;
+		goto error_out;
+	}
+
+	msi->of_node = dev->node;
+
+	msi->irqhost = irq_alloc_host(of_node_get(dev->node),
+				IRQ_HOST_MAP_LINEAR,
+				NR_MSI_IRQS, &fsl_msi_host_ops, 0);
+	if (msi->irqhost == NULL) {
+		dev_err(&dev->dev, "No memory for MSI irqhost\n");
+		of_node_put(dev->node);
+		err = -ENOMEM;
+		goto error_out;
+	}
+
+	/* Get the MSI reg base */
+	err = of_address_to_resource(dev->node, 0, &res);
+	if (err) {
+		dev_err(&dev->dev, "%s resource error!\n",
+				dev->node->full_name);
+		goto error_out;
+	}
+
+	msi->msi_regs = ioremap(res.start, res.end - res.start + 1);
+	if (!msi->msi_regs) {
+		dev_err(&dev->dev, "ioremap problem failed\n");
+		goto error_out;
+	}
+
+	tmp_data = (struct fsl_msi_feature *)match->data;
+
+	msi->feature = tmp_data->fsl_pic_ip;
+
+	msi->irqhost->host_data = msi;
+
+	msi->msi_addr_hi = 0x0;
+	msi->msi_addr_lo = res.start + tmp_data->msiir_offset;
+
+	rc = fsl_msi_init_allocator(msi);
+	if (rc) {
+		dev_err(&dev->dev, "Error allocating MSI bitmap\n");
+		goto error_out;
+	}
+
+	p = of_get_property(dev->node, "interrupts", &count);
+	if (!p) {
+		dev_err(&dev->dev, "no interrupts property found on %s\n",
+				dev->node->full_name);
+		err = -ENODEV;
+		goto error_out;
+	}
+	if (count % 8 != 0) {
+		dev_err(&dev->dev, "Malformed interrupts property on %s\n",
+				dev->node->full_name);
+		err = -EINVAL;
+		goto error_out;
+	}
+
+	count /= sizeof(u32);
+	for (i = 0; i < count / 2; i++) {
+		if (i > NR_MSIR)
+			break;
+		virt_msir = irq_of_parse_and_map(dev->node, i);
+		if (virt_msir != NO_IRQ) {
+			set_irq_data(virt_msir, (void *)i);
+			set_irq_chained_handler(virt_msir, fsl_msi_cascade);
+		}
+	}
+
+	fsl_msi = msi;
+
+	WARN_ON(ppc_md.setup_msi_irqs);
+	ppc_md.setup_msi_irqs = fsl_setup_msi_irqs;
+	ppc_md.teardown_msi_irqs = fsl_teardown_msi_irqs;
+	ppc_md.msi_check_device = fsl_msi_check_device;
+	return 0;
+error_out:
+	kfree(msi);
+	return err;
+}
+
+static const struct fsl_msi_feature mpic_msi_feature = {FSL_PIC_IP_MPIC, 0x140};
+static const struct fsl_msi_feature ipic_msi_feature = {FSL_PIC_IP_IPIC, 0x38};
+
+static const struct of_device_id fsl_of_msi_ids[] = {
+	{
+		.compatible = "fsl,MPIC-MSI",
+		.data = (void *)&mpic_msi_feature,
+	},
+	{
+		.compatible = "fsl,IPIC-MSI",
+		.data = (void *)&ipic_msi_feature,
+	},
+	{}
+};
+
+static struct of_platform_driver fsl_of_msi_driver = {
+	.name = "fsl-of-msi",
+	.match_table = fsl_of_msi_ids,
+	.probe = fsl_of_msi_probe,
+};
+
+static __init int fsl_of_msi_init(void)
+{
+	return of_register_platform_driver(&fsl_of_msi_driver);
+}
+
+subsys_initcall(fsl_of_msi_init);
diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
new file mode 100644
index 0000000..628b6c0
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_msi.h
@@ -0,0 +1,36 @@
+#ifndef _POWERPC_SYSDEV_FSL_MSI_H
+#define _POWERPC_SYSDEV_FSL_MSI_H
+
+#define NR_MSIR	8
+#define INT_PER_MSIR	32
+#define NR_MSI_IRQS	(NR_MSIR * INT_PER_MSIR)
+
+#define FSL_PIC_IP_MASK	0x0000000F
+#define FSL_PIC_IP_MPIC	0x00000001
+#define FSL_PIC_IP_IPIC	0x00000002
+
+struct fsl_msi {
+	/* Device node of the MSI interrupt*/
+	struct device_node *of_node;
+
+	struct irq_host *irqhost;
+
+	unsigned long cascade_irq;
+
+	u32 msi_addr_lo;
+	u32 msi_addr_hi;
+	void __iomem *msi_regs;
+	u32 feature;
+
+	unsigned long *fsl_msi_bitmap;
+	spinlock_t bitmap_lock;
+	const char *name;
+};
+
+struct fsl_msi_feature {
+	u32 fsl_pic_ip;
+	u32 msiir_offset;
+};
+
+#endif /* _POWERPC_SYSDEV_FSL_MSI_H */
+
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index bf13c21..fede767 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -106,6 +106,16 @@ void __init setup_pci_cmd(struct pci_controller *hose)
 	}
 }
 
+#ifdef CONFIG_PCI_MSI
+void __init setup_pci_pcsrbar(struct pci_controller *hose)
+{
+	phys_addr_t immr_base;
+
+	immr_base = get_immrbase();
+	early_write_config_dword(hose, 0, 0, PCI_BASE_ADDRESS_0, immr_base);
+}
+#endif
+
 static int fsl_pcie_bus_fixup;
 
 static void __init quirk_fsl_pcie_header(struct pci_dev *dev)
@@ -211,6 +221,10 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
 	/* Setup PEX window registers */
 	setup_pci_atmu(hose, &rsrc);
 
+	/*Setup PEXCSRBAR */
+#ifdef CONFIG_PCI_MSI
+	setup_pci_pcsrbar(hose);
+#endif
 	return 0;
 }
 
-- 
1.5.4

^ permalink raw reply related

* Re: pci issue - wrong detection of pci ressources
From: Christian Ehrhardt @ 2008-04-22 12:46 UTC (permalink / raw)
  To: Sergei Shtylyov; +Cc: linuxppc-dev, Detlev Zundel, Hollis Blanchard
In-Reply-To: <480CBEE0.9000104@ru.mvista.com>

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

Sergei Shtylyov wrote:
> Hello, I wrote:
> 
>>    Ah, that's what happens -- BAR0 in functions 0/1 takes up the whole 
>> 265 MiB of the PCI memory space (128+128), so no place is left for 
>> other memory BARs.
> 
>    What's interesting, the Sequoia/Rainier board user manual says that 
> PCI memory is 0x80000000 thru 0xbfffffff (i.e. 1 GiB), while the Linux 
> code seem to always have assumed only 0x[1]800000000 thru 0x[1]8fffffff...
> 
> WBR, Sergei

Thanks to all your help I saw that the detected spaces on boot are wrong because of the dts file.

PCI host bridge /plb/pci@1ec000000 (primary) ranges:
 MEM 0x0000000180000000..0x000000018fffffff -> 0x0000000080000000    => 256M
  IO 0x00000001e8000000..0x00000001e80fffff -> 0x0000000000000000    => 1M

The Documentation of the 440EPx core lists these spaces:
PCI 1 Memory     1 8000 0000     1 BFFF FFFF     1GB
I/O              1 E800 0000     1 E800 FFFF     64KB
I/O              1 E880 0000     1 EBFF FFFF     56MB

I modified the dts file and now it shows this on boot which is what the user manual lists as mem/io space:

PCI host bridge /plb/pci@1ec000000 (primary) ranges:
 MEM 0x0000000180000000..0x00000001bfffffff -> 0x0000000080000000
  IO 0x00000001e8000000..0x00000001e800ffff -> 0x0000000000000000
  IO 0x00000001e8800000..0x00000001ebffffff -> 0x0000000000000000
 \--> Skipped (too many) !
4xx PCI DMA offset set to 0x00000000

The detected sizes look good compared to the processor documentation.
But I never modified a dts file before and I only found a ranges documentation speaking of three elemnts in the ranges element.
So feel free to correct the dts if I wrote something bad without knowing it (e.g. that skipped message).

The issue that let me start debugging this was the initialization of the radeonfb driver and with that patch it works:
radeonfb_pci_register BEGIN
radeonfb (0000:00:0a.0): Cannot match card to OF node !
aper_base: 80000000 MC_FB_LOC to: 87ff8000, MC_AGP_LOC to: ffff9000
radeonfb (0000:00:0a.0): Found 131072k of DDR 64 bits wide videoram
radeonfb (0000:00:0a.0): mapped 16384k videoram
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retrieved PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=240.00 Mhz, System=200.00 MHz
radeonfb: PLL min 20000 max 40000
1 chips in connector info
 - chip 1 has 2 connectors
  * connector 0 of type 2 (CRT) : 2300
  * connector 1 of type 3 (DVI-I) : 3201
Starting monitor auto detection...
radeonfb: I2C (port 1) ... not found
radeonfb: I2C (port 2) ... found TMDS panel
radeonfb: I2C (port 3) ... found CRT display
i2c-adapter i2c-3: unable to read EDID block.
i2c-adapter i2c-3: unable to read EDID block.
i2c-adapter i2c-3: unable to read EDID block.
radeonfb: I2C (port 4) ... not found
radeon_probe_OF_head
radeonfb: I2C (port 2) ... found TMDS panel
radeon_probe_OF_head
radeonfb: I2C (port 3) ... found CRT display
radeonfb: Monitor 1 type DFP found
radeonfb: EDID probed
radeonfb: Monitor 2 type CRT found
radeonfb: EDID probed
Parsing EDID data for panel info
Setting up default mode based on panel info
radeonfb (0000:00:0a.0): ATI Radeon Y`
radeonfb_pci_register END

And btw. now we really need the change of the radeonfb.h to use the correct resource_size_t type, otherwise it fails with:

radeonfb_pci_register BEGIN
Machine check in kernel mode.
Data Read PLB Error
Oops: Machine check, sig: 7 [#1]
Sequoia
Modules linked in:
NIP: c029cf00 LR: c029cee8 CTR: 00000000
REGS: c038bf50 TRAP: 0214   Not tainted  (2.6.25-rc9)
MSR: 00029000 <EE,ME>  CR: 84000028  XER: 0000005f
TASK = cf81ec00[1] 'swapper' THREAD: cf82e000
GPR00: 01000000 cf82fe00 cf81ec00 d1018000 d101b000 00000000 90023000 0000071b
GPR08: 00000000 00000000 9002371b 00000000 9002ffff 00000000 0ffa6800 0ffbf000
GPR16: 100c0000 00000000 100c0000 c02e0000 cf810458 cf8a0608 cf8a0000 00000001
GPR24: c0350000 cf810400 c037102c cf813de0 c03713f4 c0371800 00000000 cf8a02ec
NIP [c029cf00] 0xc029cf00
LR [c029cee8] 0xc029cee8
Call Trace:
[cf82fe00] [c029cee8] 0xc029cee8 (unreliable)
[cf82fe40] [c012f554] pci_device_probe+0x80/0xa0
[cf82fe60] [c019014c] driver_probe_device+0xb8/0x1cc
[cf82fe80] [c0190438] __driver_attach+0xcc/0xf8
[cf82fea0] [c018ecd4] bus_for_each_dev+0x58/0x94
[cf82fed0] [c018fe7c] driver_attach+0x24/0x34
[cf82fee0] [c018fc6c] bus_add_driver+0xb0/0x248
[cf82ff00] [c0190920] driver_register+0x48/0x130
[cf82ff20] [c012f158] __pci_register_driver+0x48/0x94
[cf82ff40] [c034bca4] radeonfb_init+0xc4/0x21c
[cf82ff70] [c0337840] kernel_init+0x98/0x284
[cf82fff0] [c000cc4c] kernel_thread+0x44/0x60
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

I attached the patch I used to get it working now for further discussion e.g. because I don't really know dts syntax ;-)
I hope both changes find their way into the kernel once you are all agreeing with the new dts content.

I still have issues with my X11, but thats another story.

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

[-- Attachment #2: fix-sequoia-pci-memory-dts --]
[-- Type: text/plain, Size: 2281 bytes --]

Subject: [PATCH][dts][radeonfb]: fix pci mem in dts and radeonfb resource variables

From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

This patch is fixing the sequoia.dts device tree file to the values defined
in the 440Epx data sheet from amcc.
That fixes an issue where my graphic card could not initialize because the pci
resource space was not big enough.
The related mail thread about the backgrounds of this has the subject "pci
issue - wrong detection of pci ressources"
After these values were fixed another modification that came up in the mail
thread was needed to prevent an error. This change fixes the type of the
resource vaiables in the radeon frame buffer driver (We might want to split
that into two patches).

Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
---

[diffstat]
 arch/powerpc/boot/dts/sequoia.dts |    9 +++++++--
 drivers/video/aty/radeonfb.h      |    4 ++--
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/boot/dts/sequoia.dts b/arch/powerpc/boot/dts/sequoia.dts
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -344,9 +344,14 @@
 			/* Outbound ranges, one memory and one IO,
 			 * later cannot be changed. Chip supports a second
 			 * IO range but we don't use it for now
+			 * From the 440EPx user manual:
+			 * PCI 1 Memory     1 8000 0000     1 BFFF FFFF     1GB
+			 * I/O              1 E800 0000     1 E800 FFFF     64KB
+			 * I/O              1 E880 0000     1 EBFF FFFF     56MB
 			 */
-			ranges = <02000000 0 80000000 1 80000000 0 10000000
-				01000000 0 00000000 1 e8000000 0 00100000>;
+			ranges = <02000000 0 80000000 1 80000000 0 40000000
+				01000000 0 00000000 1 e8000000 0 00010000
+				01000000 0 00000000 1 e8800000 0 03800000>;
 
 			/* Inbound 2GB range starting at 0 */
 			dma-ranges = <42000000 0 0 0 0 0 80000000>;
diff --git a/drivers/video/aty/radeonfb.h b/drivers/video/aty/radeonfb.h
--- a/drivers/video/aty/radeonfb.h
+++ b/drivers/video/aty/radeonfb.h
@@ -287,8 +287,8 @@ struct radeonfb_info {
 
 	char			name[DEVICE_NAME_SIZE];
 
-	unsigned long		mmio_base_phys;
-	unsigned long		fb_base_phys;
+	resource_size_t		mmio_base_phys;
+	resource_size_t		fb_base_phys;
 
 	void __iomem		*mmio_base;
 	void __iomem		*fb_base;

^ permalink raw reply

* (no subject)
From: Koss, Mike (Mission Systems) @ 2008-04-22 12:53 UTC (permalink / raw)
  To: David H. Lynch Jr., Grant Likely; +Cc: linuxppc-embedded



^ permalink raw reply

* Re: [PATCH 04/11] Convert from DBG() to pr_debug() in platforms/pseries/setup.c
From: Olof Johansson @ 2008-04-22 13:31 UTC (permalink / raw)
  To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <6112063f5eac0a820949415417d49a5376ad5ffd.1208505275.git.michael@ellerman.id.au>

On Fri, Apr 18, 2008 at 05:54:36PM +1000, Michael Ellerman wrote:
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>

I know it's fun to see yourself in the changeset statistics, but this is
silly. Please bake together all the simple changes to one patch instead
of one per file. They are all trivial.


-Olof

^ permalink raw reply

* Re: [PATCH 1/3] MSI driver for Freescale 83xx/85xx/86xx cpu
From: Segher Boessenkool @ 2008-04-22 13:22 UTC (permalink / raw)
  To: michael; +Cc: linuxppc-dev list, Kumar Gala, Jin Zhengxiong
In-Reply-To: <1208838916.12660.10.camel@concordia.ozlabs.ibm.com>

>>>> +static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
>>>> +				  struct msi_msg *msg)

> No I mean I'm confused about the maths here. If we pull out the
> variables it boils down to:
>
> data = ((hwirq / 32) << 5) | ((hwirq % 32) & 0x1F)
>
> Which doesn't seem to actually do anything?

It's not a no-op, because hwirq is signed.  It probably should be
unsigned, like most things.


Segher

^ permalink raw reply

* Re: [PATCH 1/3] Raise the upper limit of NR_CPUS.
From: Segher Boessenkool @ 2008-04-22 13:27 UTC (permalink / raw)
  To: Tony Breeds; +Cc: Stephen Rothwell, Paul Mackerras, linuxppc-dev
In-Reply-To: <20080422055536.GI20457@bakeyournoodle.com>

>>> +	unsigned long kernel_toc = (unsigned long)(&__toc_start) + 
>>> 0x8000UL;
>>
>> This line could do with a comment saying what it is doing ...
>
> It does need a comment I agree, but I don't think I can do it justice 
> :)
> ... I just used what was already there.

Here, have one:

"The TOC register (GPR2) points 32kB into the TOC, so that 64kB
of the TOC can be addressed using a single machine instruction."

or, perhaps simpler:

"The TOC register (GPR2) points 32kB into the TOC, because the
ABI says so."


Segher

^ permalink raw reply

* Re: pci issue - wrong detection of pci ressources
From: Sergei Shtylyov @ 2008-04-22 13:31 UTC (permalink / raw)
  To: Christian Ehrhardt; +Cc: linuxppc-dev, Detlev Zundel, Hollis Blanchard
In-Reply-To: <480DDE2B.4000808@linux.vnet.ibm.com>

Hello.

Christian Ehrhardt wrote:

>>>    Ah, that's what happens -- BAR0 in functions 0/1 takes up the 
>>> whole 265 MiB of the PCI memory space (128+128), so no place is left 
>>> for other memory BARs.

>>    What's interesting, the Sequoia/Rainier board user manual says that 
>> PCI memory is 0x80000000 thru 0xbfffffff (i.e. 1 GiB), while the Linux 
>> code seem to always have assumed only 0x[1]800000000 thru 
>> 0x[1]8fffffff...

> Thanks to all your help I saw that the detected spaces on boot are wrong 
> because of the dts file.

> PCI host bridge /plb/pci@1ec000000 (primary) ranges:
> MEM 0x0000000180000000..0x000000018fffffff -> 0x0000000080000000    => 256M
>  IO 0x00000001e8000000..0x00000001e80fffff -> 0x0000000000000000    => 1M

    Yeah, I/O space should be 64K according to what arch/ppc/ had (well, I'm 
looking at the out-of-tree source code :-).

> The Documentation of the 440EPx core lists these spaces:
> PCI 1 Memory     1 8000 0000     1 BFFF FFFF     1GB
> I/O              1 E800 0000     1 E800 FFFF     64KB
> I/O              1 E880 0000     1 EBFF FFFF     56MB

    Having 2 I/O spaces looks just wrong. Actually, PCs do well with only 64K 
of I/O space.

> I modified the dts file and now it shows this on boot which is what the 
> user manual lists as mem/io space:

> PCI host bridge /plb/pci@1ec000000 (primary) ranges:
> MEM 0x0000000180000000..0x00000001bfffffff -> 0x0000000080000000
>  IO 0x00000001e8000000..0x00000001e800ffff -> 0x0000000000000000
>  IO 0x00000001e8800000..0x00000001ebffffff -> 0x0000000000000000
> \--> Skipped (too many) !
> 4xx PCI DMA offset set to 0x00000000

> The detected sizes look good compared to the processor documentation.
> But I never modified a dts file before and I only found a ranges 
> documentation speaking of three elemnts in the ranges element.
> So feel free to correct the dts if I wrote something bad without knowing 
> it (e.g. that skipped message).

> The issue that let me start debugging this was the initialization of the 
> radeonfb driver and with that patch it works:
> radeonfb_pci_register BEGIN
> radeonfb (0000:00:0a.0): Cannot match card to OF node !
> aper_base: 80000000 MC_FB_LOC to: 87ff8000, MC_AGP_LOC to: ffff9000
> radeonfb (0000:00:0a.0): Found 131072k of DDR 64 bits wide videoram
> radeonfb (0000:00:0a.0): mapped 16384k videoram
> radeonfb: Found Intel x86 BIOS ROM Image
> radeonfb: Retrieved PLL infos from BIOS
> radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=240.00 Mhz, 
> System=200.00 MHz
> radeonfb: PLL min 20000 max 40000
> 1 chips in connector info
> - chip 1 has 2 connectors
>  * connector 0 of type 2 (CRT) : 2300
>  * connector 1 of type 3 (DVI-I) : 3201
> Starting monitor auto detection...
> radeonfb: I2C (port 1) ... not found
> radeonfb: I2C (port 2) ... found TMDS panel
> radeonfb: I2C (port 3) ... found CRT display
> i2c-adapter i2c-3: unable to read EDID block.
> i2c-adapter i2c-3: unable to read EDID block.
> i2c-adapter i2c-3: unable to read EDID block.
> radeonfb: I2C (port 4) ... not found
> radeon_probe_OF_head
> radeonfb: I2C (port 2) ... found TMDS panel
> radeon_probe_OF_head
> radeonfb: I2C (port 3) ... found CRT display
> radeonfb: Monitor 1 type DFP found
> radeonfb: EDID probed
> radeonfb: Monitor 2 type CRT found
> radeonfb: EDID probed
> Parsing EDID data for panel info
> Setting up default mode based on panel info
> radeonfb (0000:00:0a.0): ATI Radeon Y`

    Hm, what's that Y`?

> radeonfb_pci_register END

> And btw. now we really need the change of the radeonfb.h to use the 
> correct resource_size_t type, otherwise it fails with:

    Of course.


> I attached the patch I used to get it working now for further discussion 
> e.g. because I don't really know dts syntax ;-)
> I hope both changes find their way into the kernel once you are all 
> agreeing with the new dts content.

> I still have issues with my X11, but thats another story.


> ------------------------------------------------------------------------
> 
> Subject: [PATCH][dts][radeonfb]: fix pci mem in dts and radeonfb resource variables

> From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

> This patch is fixing the sequoia.dts device tree file to the values defined
> in the 440Epx data sheet from amcc.
> That fixes an issue where my graphic card could not initialize because the pci
> resource space was not big enough.
> The related mail thread about the backgrounds of this has the subject "pci
> issue - wrong detection of pci ressources"
> After these values were fixed another modification that came up in the mail
> thread was needed to prevent an error. This change fixes the type of the
> resource vaiables in the radeon frame buffer driver (We might want to split
> that into two patches).

> Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

> diff --git a/arch/powerpc/boot/dts/sequoia.dts b/arch/powerpc/boot/dts/sequoia.dts
> --- a/arch/powerpc/boot/dts/sequoia.dts
> +++ b/arch/powerpc/boot/dts/sequoia.dts
> @@ -344,9 +344,14 @@
>  			/* Outbound ranges, one memory and one IO,
>  			 * later cannot be changed. Chip supports a second
>  			 * IO range but we don't use it for now
> +			 * From the 440EPx user manual:
> +			 * PCI 1 Memory     1 8000 0000     1 BFFF FFFF     1GB
> +			 * I/O              1 E800 0000     1 E800 FFFF     64KB
> +			 * I/O              1 E880 0000     1 EBFF FFFF     56MB
>  			 */
> -			ranges = <02000000 0 80000000 1 80000000 0 10000000
> -				01000000 0 00000000 1 e8000000 0 00100000>;
> +			ranges = <02000000 0 80000000 1 80000000 0 40000000
> +				01000000 0 00000000 1 e8000000 0 00010000
> +				01000000 0 00000000 1 e8800000 0 03800000>;

   I don't think 56 MiB of I/O space make sense, so might as well skip the 3rg 
range...

>  
>  			/* Inbound 2GB range starting at 0 */
>  			dma-ranges = <42000000 0 0 0 0 0 80000000>;
> diff --git a/drivers/video/aty/radeonfb.h b/drivers/video/aty/radeonfb.h
> --- a/drivers/video/aty/radeonfb.h
> +++ b/drivers/video/aty/radeonfb.h
> @@ -287,8 +287,8 @@ struct radeonfb_info {
>  
>  	char			name[DEVICE_NAME_SIZE];
>  
> -	unsigned long		mmio_base_phys;
> -	unsigned long		fb_base_phys;
> +	resource_size_t		mmio_base_phys;
> +	resource_size_t		fb_base_phys;
>  
>  	void __iomem		*mmio_base;
>  	void __iomem		*fb_base;

    I think you'd better use Ben's patch that he's just posted:

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

WBR, Sergei

^ permalink raw reply

* Re: [PATCH v2] MSI driver for Freescale 83xx/85xx/86xx cpu
From: Kumar Gala @ 2008-04-22 13:37 UTC (permalink / raw)
  To: Jason Jin; +Cc: linuxppc-dev
In-Reply-To: <1208857064-26863-1-git-send-email-Jason.jin@freescale.com>

> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/ 
> Makefile
> index 6d386d0..e60a238 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -4,6 +4,7 @@ endif
>
> mpic-msi-obj-$(CONFIG_PCI_MSI)	+= mpic_msi.o mpic_u3msi.o  
> mpic_pasemi_msi.o
> obj-$(CONFIG_MPIC)		+= mpic.o $(mpic-msi-obj-y)
> +obj-$(CONFIG_FSL_PCI)		+= fsl_msi.o

can we do something like:
fsl_pci-$(CONFIG_MSI)           += fsl_msi.o
obj-$(CONFIG_FSL_PCI)           += fsl_pci.o $(fsl_pci-y)

> obj-$(CONFIG_PPC_MPC106)	+= grackle.o
> obj-$(CONFIG_PPC_DCR_NATIVE)	+= dcr-low.o



> +static int fsl_msi_init_allocator(struct fsl_msi *msi_data)
> +{
> +	int rc, size;
> +
> +	size = BITS_TO_LONGS(NR_MSI_IRQS) * sizeof(long);

should this be long or u32?

> +
> +	msi_data->fsl_msi_bitmap = kzalloc(size, GFP_KERNEL);
> +
> +	if (msi_data->fsl_msi_bitmap == NULL) {
> +		pr_debug("%s: ENOMEM allocating allocator bitmap!\n",
> +				__func__);
> +		return -ENOMEM;
> +	}
> +
> +	rc = fsl_msi_free_dt_hwirqs(msi_data);
> +	if (rc)
> +		goto out_free;
> +
> +	return 0;
> +out_free:
> +	kfree(msi_data->fsl_msi_bitmap);
> +
> +	msi_data->fsl_msi_bitmap = NULL;
> +	return rc;
> +
> +}
> +
> +static int fsl_msi_check_device(struct pci_dev *pdev, int nvec, int  
> type)
> +{
> +	if (type == PCI_CAP_ID_MSIX)
> +		pr_debug("fslmsi: MSI-X untested, trying anyway.\n");
> +
> +	return 0;
> +}
> +
> +static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
> +{
> +	struct msi_desc *entry;
> +	struct fsl_msi *msi_data = fsl_msi;
> +
> +	list_for_each_entry(entry, &pdev->msi_list, list) {
> +		if (entry->irq == NO_IRQ)
> +			continue;
> +		set_irq_msi(entry->irq, NULL);
> +		fsl_msi_free_hwirqs(msi_data, virq_to_hw(entry->irq), 1);
> +		irq_dispose_mapping(entry->irq);
> +	}
> +
> +	return;
> +}
> +
> +static void fsl_compose_msi_msg(struct pci_dev *pdev, int hwirq,
> +				  struct msi_msg *msg)
> +{
> +	struct fsl_msi *msi_data = fsl_msi;
> +
> +	msg->address_lo = msi_data->msi_addr_lo;
> +	msg->address_hi = msi_data->msi_addr_hi;
> +	msg->data = hwirq;
> +
> +	pr_debug("%s: allocated srs: %d, ibs: %d\n",
> +		__func__, hwirq / INT_PER_MSIR, hwirq % INT_PER_MSIR);
> +}
> +
> +static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int  
> type)
> +{
> +	irq_hw_number_t hwirq;
> +	int rc;
> +	unsigned int virq;
> +	struct msi_desc *entry;
> +	struct msi_msg msg;
> +	struct fsl_msi *msi_data = fsl_msi;
> +
> +	list_for_each_entry(entry, &pdev->msi_list, list) {
> +		hwirq = fsl_msi_alloc_hwirqs(msi_data, 1);
> +		if (hwirq < 0) {
> +			rc = hwirq;
> +			pr_debug("%s: fail allocating msi interrupt\n",
> +					__func__);
> +			goto out_free;
> +		}
> +
> +		virq = irq_create_mapping(msi_data->irqhost, hwirq);
> +
> +		if (virq == NO_IRQ) {
> +			pr_debug("%s: fail mapping hwirq 0x%lx\n",
> +					__func__, hwirq);
> +			fsl_msi_free_hwirqs(msi_data, hwirq, 1);
> +			rc = -ENOSPC;
> +			goto out_free;
> +		}
> +		set_irq_msi(virq, entry);
> +
> +		fsl_compose_msi_msg(pdev, hwirq, &msg);
> +		write_msi_msg(virq, &msg);
> +	}
> +	return 0;
> +
> +out_free:
> +	return rc;
> +}
> +
> +void fsl_msi_cascade(unsigned int irq, struct irq_desc *desc)
> +{
> +	unsigned int cascade_irq;
> +	struct fsl_msi *msi_data = fsl_msi;
> +	int msir_index = -1;
> +	u32 msir_value = 0;
> +	u32 intr_index;
> +	u32 have_shift = 0;
> +
> +	spin_lock(&desc->lock);
> +	if ((msi_data->feature &  FSL_PIC_IP_MASK) == FSL_PIC_IP_IPIC) {
> +		if (desc->chip->mask_ack)
> +			desc->chip->mask_ack(irq);
> +		else {
> +			desc->chip->mask(irq);
> +			desc->chip->ack(irq);
> +		}
> +	}
> +
> +	if (unlikely(desc->status & IRQ_INPROGRESS))
> +		goto unlock;
> +
> +	msir_index = (int)(desc->handler_data);
> +
> +	if (msir_index >= NR_MSIR)
> +		cascade_irq = NO_IRQ;
> +
> +	desc->status |= IRQ_INPROGRESS;
> +	switch (fsl_msi->feature & FSL_PIC_IP_MASK) {
> +	case FSL_PIC_IP_MPIC:
> +		msir_value = fsl_msi_read(msi_data->msi_regs,
> +			msir_index * 0x10);
> +		break;
> +	case FSL_PIC_IP_IPIC:
> +		msir_value = fsl_msi_read(msi_data->msi_regs, msir_index * 0x4);
> +		break;
> +	}
> +
> +	while (msir_value) {
> +		intr_index = ffs(msir_value) - 1;
> +
> +		cascade_irq = irq_linear_revmap(msi_data->irqhost,
> +			(msir_index * INT_PER_MSIR + intr_index + have_shift));
> +
> +		if (cascade_irq != NO_IRQ)
> +			generic_handle_irq(cascade_irq);
> +		have_shift += (intr_index + 1);
> +		msir_value = (msir_value >> (intr_index + 1));
> +	}
> +	desc->status &= ~IRQ_INPROGRESS;
> +
> +	switch (msi_data->feature & FSL_PIC_IP_MASK) {
> +	case FSL_PIC_IP_MPIC:
> +		desc->chip->eoi(irq);
> +		break;
> +	case FSL_PIC_IP_IPIC:
> +		if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
> +			desc->chip->unmask(irq);
> +		break;
> +	}
> +unlock:
> +	spin_unlock(&desc->lock);
> +}
> +
> +static int __devinit fsl_of_msi_probe(struct of_device *dev,
> +				const struct of_device_id *match)
> +{
> +	struct fsl_msi *msi;
> +	struct resource res;
> +	int err, i, count;
> +	int rc;
> +	int virt_msir;
> +	const u32 *p;
> +	struct fsl_msi_feature *tmp_data;
> +
> +	printk(KERN_DEBUG "Setting up fsl msi support\n");
> +
> +	msi = kzalloc(sizeof(struct fsl_msi), GFP_KERNEL);
> +	if (!msi) {
> +		dev_err(&dev->dev, "No memory for MSI structure\n");
> +		err = -ENOMEM;
> +		goto error_out;
> +	}
> +
> +	msi->of_node = dev->node;
> +
> +	msi->irqhost = irq_alloc_host(of_node_get(dev->node),
> +				IRQ_HOST_MAP_LINEAR,
> +				NR_MSI_IRQS, &fsl_msi_host_ops, 0);
> +	if (msi->irqhost == NULL) {
> +		dev_err(&dev->dev, "No memory for MSI irqhost\n");
> +		of_node_put(dev->node);
> +		err = -ENOMEM;
> +		goto error_out;
> +	}
> +
> +	/* Get the MSI reg base */
> +	err = of_address_to_resource(dev->node, 0, &res);
> +	if (err) {
> +		dev_err(&dev->dev, "%s resource error!\n",
> +				dev->node->full_name);
> +		goto error_out;
> +	}
> +
> +	msi->msi_regs = ioremap(res.start, res.end - res.start + 1);
> +	if (!msi->msi_regs) {
> +		dev_err(&dev->dev, "ioremap problem failed\n");
> +		goto error_out;
> +	}
> +
> +	tmp_data = (struct fsl_msi_feature *)match->data;
> +
> +	msi->feature = tmp_data->fsl_pic_ip;
> +
> +	msi->irqhost->host_data = msi;
> +
> +	msi->msi_addr_hi = 0x0;
> +	msi->msi_addr_lo = res.start + tmp_data->msiir_offset;
> +
> +	rc = fsl_msi_init_allocator(msi);
> +	if (rc) {
> +		dev_err(&dev->dev, "Error allocating MSI bitmap\n");
> +		goto error_out;
> +	}
> +
> +	p = of_get_property(dev->node, "interrupts", &count);
> +	if (!p) {
> +		dev_err(&dev->dev, "no interrupts property found on %s\n",
> +				dev->node->full_name);
> +		err = -ENODEV;
> +		goto error_out;
> +	}
> +	if (count % 8 != 0) {
> +		dev_err(&dev->dev, "Malformed interrupts property on %s\n",
> +				dev->node->full_name);
> +		err = -EINVAL;
> +		goto error_out;
> +	}
> +
> +	count /= sizeof(u32);
> +	for (i = 0; i < count / 2; i++) {
> +		if (i > NR_MSIR)
> +			break;
> +		virt_msir = irq_of_parse_and_map(dev->node, i);
> +		if (virt_msir != NO_IRQ) {
> +			set_irq_data(virt_msir, (void *)i);
> +			set_irq_chained_handler(virt_msir, fsl_msi_cascade);
> +		}
> +	}
> +
> +	fsl_msi = msi;
> +
> +	WARN_ON(ppc_md.setup_msi_irqs);
> +	ppc_md.setup_msi_irqs = fsl_setup_msi_irqs;
> +	ppc_md.teardown_msi_irqs = fsl_teardown_msi_irqs;
> +	ppc_md.msi_check_device = fsl_msi_check_device;
> +	return 0;
> +error_out:
> +	kfree(msi);
> +	return err;
> +}
> +
> +static const struct fsl_msi_feature mpic_msi_feature =  
> {FSL_PIC_IP_MPIC, 0x140};
> +static const struct fsl_msi_feature ipic_msi_feature =  
> {FSL_PIC_IP_IPIC, 0x38};

make this
{
	.fsl_pic_ip = FSL_PIC_IP_MPIC
	.offset = 0x140
};

for readability.

> +
> +static const struct of_device_id fsl_of_msi_ids[] = {
> +	{
> +		.compatible = "fsl,MPIC-MSI",
> +		.data = (void *)&mpic_msi_feature,
> +	},
> +	{
> +		.compatible = "fsl,IPIC-MSI",
> +		.data = (void *)&ipic_msi_feature,
> +	},
> +	{}
> +};
> +
> +static struct of_platform_driver fsl_of_msi_driver = {
> +	.name = "fsl-of-msi",
> +	.match_table = fsl_of_msi_ids,
> +	.probe = fsl_of_msi_probe,
> +};
> +
> +static __init int fsl_of_msi_init(void)
> +{
> +	return of_register_platform_driver(&fsl_of_msi_driver);
> +}
> +
> +subsys_initcall(fsl_of_msi_init);
> diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/ 
> fsl_msi.h
> new file mode 100644
> index 0000000..628b6c0
> --- /dev/null
> +++ b/arch/powerpc/sysdev/fsl_msi.h
> @@ -0,0 +1,36 @@
> +#ifndef _POWERPC_SYSDEV_FSL_MSI_H
> +#define _POWERPC_SYSDEV_FSL_MSI_H
> +
> +#define NR_MSIR	8

NR_MSR_REG

> +#define INT_PER_MSIR	32

IRQS_PER_MSI_REG

>
> +#define NR_MSI_IRQS	(NR_MSIR * INT_PER_MSIR)
> +
> +#define FSL_PIC_IP_MASK	0x0000000F
> +#define FSL_PIC_IP_MPIC	0x00000001
> +#define FSL_PIC_IP_IPIC	0x00000002
> +
> +struct fsl_msi {
> +	/* Device node of the MSI interrupt*/
> +	struct device_node *of_node;
> +
> +	struct irq_host *irqhost;
> +
> +	unsigned long cascade_irq;
> +
> +	u32 msi_addr_lo;
> +	u32 msi_addr_hi;
> +	void __iomem *msi_regs;
> +	u32 feature;
> +
> +	unsigned long *fsl_msi_bitmap;
> +	spinlock_t bitmap_lock;
> +	const char *name;
> +};
> +
> +struct fsl_msi_feature {
> +	u32 fsl_pic_ip;
> +	u32 msiir_offset;
> +};

move this struct into .c
>
> +
> +#endif /* _POWERPC_SYSDEV_FSL_MSI_H */
> +
> diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/ 
> fsl_pci.c
> index bf13c21..fede767 100644
> --- a/arch/powerpc/sysdev/fsl_pci.c
> +++ b/arch/powerpc/sysdev/fsl_pci.c
> @@ -106,6 +106,16 @@ void __init setup_pci_cmd(struct pci_controller  
> *hose)
> 	}
> }
>
> +#ifdef CONFIG_PCI_MSI
> +void __init setup_pci_pcsrbar(struct pci_controller *hose)
> +{
> +	phys_addr_t immr_base;
> +
> +	immr_base = get_immrbase();
> +	early_write_config_dword(hose, 0, 0, PCI_BASE_ADDRESS_0, immr_base);
> +}
> +#endif
> +
> static int fsl_pcie_bus_fixup;
>
> static void __init quirk_fsl_pcie_header(struct pci_dev *dev)
> @@ -211,6 +221,10 @@ int __init fsl_add_bridge(struct device_node  
> *dev, int is_primary)
> 	/* Setup PEX window registers */
> 	setup_pci_atmu(hose, &rsrc);
>
> +	/*Setup PEXCSRBAR */
> +#ifdef CONFIG_PCI_MSI
> +	setup_pci_pcsrbar(hose);
> +#endif

I'm not convinced this is safe.  we need to be careful to make sure  
the pcsrbar doesn't overlap with any other device.

> 	return 0;
> }

- k

^ permalink raw reply

* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Laurent Pinchart @ 2008-04-22 14:11 UTC (permalink / raw)
  To: Jean Delvare; +Cc: linuxppc-dev list, Alessandro Zummo, rtc-linux, i2c
In-Reply-To: <480A2117.7020502@scram.de>

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

Hi Jean,

On Saturday 19 April 2008 18:43, Jochen Friedrich wrote:
> Jean Delvare wrote:
> > On Sat, 19 Apr 2008 15:09:55 +0200, Jochen Friedrich wrote:
> >> Hi Jean,
> >>
> >>>>> Is the new-style driver conversion patch in 2.6.25-rc8-mm2 scheduled
> >>>>> for 2.6.26 ?
> >>>>  hope so! :)
> >>> Note that this patch depends on i2c patches which aren't upstream yet.
> >> Is there any chance they will got to 2.6.26?
> > 
> > I'm not sure. I didn't have the time to look at it myself, but I am
> > under the impression that the powerpc folks are tired of having to wait
> > for me and may push it to Linus through their tree? That would be fine
> > with me, as I don't want to be the one delaying something many
> > developers want (but I also can't sign patches I've not even read.)
> 
> The required patches are:
> 
> http://patchwork.ozlabs.org/linuxppc/patch?id=17833
> http://patchwork.ozlabs.org/linuxppc/patch?id=17834
> 
> which are just the forward ported patches you sent to the poweprc mailing
> list some time ago: 
> 
> http://patchwork.ozlabs.org/linuxppc/patch?id=16282
> http://patchwork.ozlabs.org/linuxppc/patch?id=16283

Given that the required patches are just forward-ported versions of patches 
you sent (and thus probably reviewed as well :-)), what's the best way to get 
them in 2.6.26 (if at all possible) ?

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: RFC: MPC5200 PSC AC97 driver
From: Olaf Hering @ 2008-04-22 14:20 UTC (permalink / raw)
  To: Juergen Beisert; +Cc: linuxppc-dev
In-Reply-To: <200804171619.56615.jbe@pengutronix.de>

On Thu, Apr 17, Juergen Beisert wrote:

> if someone is interested: Here the full patch to get sound support for
> MPC5200b and a current 2.6.25 kernel.

It misses a 'MODULE_DEVICE_TABLE(of, mpc52xx_ac97_of_match);' and a nul
termination of struct mpc52xx_ac97_of_match.
This will allow autoload of the drivers, as it is done in most other
kernel drivers.

Olaf

^ 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