Please pull from 'powerpc-next' branch
Please pull from 'powerpc-next' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git powerpc-next to receive the following updates: (i've got some more patches to pull off the list, but lets get these into your tree). Documentation/powerpc/booting-without-of.txt |6 arch/powerpc/Kconfig |5 arch/powerpc/Kconfig.debug|2 arch/powerpc/boot/cpm-serial.c| 117 - arch/powerpc/boot/cuboot-pq2.c| 27 arch/powerpc/boot/devtree.c | 20 arch/powerpc/boot/dts/ep8248e.dts |5 arch/powerpc/boot/dts/mpc832x_mds.dts |7 arch/powerpc/boot/dts/mpc832x_rdb.dts |4 arch/powerpc/boot/dts/mpc836x_mds.dts |4 arch/powerpc/boot/dts/mpc8540ads.dts | 173 +- arch/powerpc/boot/dts/mpc8541cds.dts | 161 +- arch/powerpc/boot/dts/mpc8544ds.dts | 299 ++-- arch/powerpc/boot/dts/mpc8548cds.dts | 289 ++-- arch/powerpc/boot/dts/mpc8555cds.dts | 161 +- arch/powerpc/boot/dts/mpc8560ads.dts | 209 +- arch/powerpc/boot/dts/mpc8568mds.dts | 291 +--- arch/powerpc/boot/dts/mpc8572ds.dts | 383 ++--- arch/powerpc/boot/dts/sbc8641d.dts| 352 arch/powerpc/boot/mpc52xx-psc.c |9 arch/powerpc/boot/ns16550.c | 10 arch/powerpc/boot/ops.h |1 arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 1395 +++ arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 1451 arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 1081 +++ arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 1233 + arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 1295 ++ arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 1222 + arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 1021 ++ arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 1079 +++ arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 899 arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 930 + arch/powerpc/configs/83xx/sbc834x_defconfig | 828 +++ arch/powerpc/configs/85xx/ksi8560_defconfig | 899 arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 796 +++ arch/powerpc/configs/85xx/mpc8544_ds_defconfig| 1564 ++ arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 885 arch/powerpc/configs/85xx/mpc8568mds_defconfig| 1117 +++ arch/powerpc/configs/85xx/mpc8572_ds_defconfig| 1549 + arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 935 + arch/powerpc/configs/85xx/sbc8548_defconfig | 812 +++ arch/powerpc/configs/85xx/sbc8560_defconfig | 830 +++ arch/powerpc/configs/85xx/stx_gp3_defconfig | 1253 + arch/powerpc/configs/85xx/tqm8540_defconfig | 1097 +++ arch/powerpc/configs/85xx/tqm8541_defconfig | 1109 +++ arch/powerpc/configs/85xx/tqm8555_defconfig | 1109 +++ arch/powerpc/configs/85xx/tqm8560_defconfig | 1109 +++ arch/powerpc/configs/ksi8560_defconfig| 899 arch/powerpc/configs/mpc8313_rdb_defconfig| 1393 --- arch/powerpc/configs/mpc8315_rdb_defconfig| 1451 arch/powerpc/configs/mpc832x_mds_defconfig| 1081 --- arch/powerpc/configs/mpc832x_rdb_defconfig| 1233 - arch/powerpc/configs/mpc834x_itx_defconfig| 1295 -- arch/powerpc/configs/mpc834x_itxgp_defconfig | 1222 - arch/powerpc/configs/mpc834x_mds_defconfig| 1021 -- arch/powerpc/configs/mpc836x_mds_defconfig| 1079 --- arch/powerpc/configs/mpc837x_mds_defconfig| 899 arch/powerpc/configs/mpc837x_rdb_defconfig| 930 - arch/powerpc/configs/mpc83xx_defconfig| 164 ++ arch/powerpc/configs/mpc8540_ads_defconfig| 796 --- arch/powerpc/configs/mpc8544_ds_defconfig | 1549 - arch/powerpc/configs/mpc8560_ads_defconfig| 885 arch/powerpc/configs/mpc8568mds_defconfig | 1117 --- arch/powerpc/configs/mpc8572_ds_defconfig | 1549 - arch/powerpc/configs/mpc85xx_cds_defconfig| 935 - arch/powerpc/configs/sbc834x_defconfig| 828 --- arch/powerpc/configs/sbc8548_defconfig| 812 --- arch/powerpc/configs/sbc8560_defconfig| 830 --- arch/powerpc/configs/sbc8641d_defconfig
Re: mpc5200: add interrupt type function
On Wed, Apr 16, 2008 at 11:00 PM, Robert Schwebel <[EMAIL PROTECTED]> wrote: > On Tue, Apr 15, 2008 at 05:29:54PM +0200, Robert Schwebel wrote: > > From: Sascha Hauer <[EMAIL PROTECTED]> > > > > Add a set_type function for external (GPIO) interrupts. > > > > Signed-off-by: Juergen Beisert <[EMAIL PROTECTED]> > > Signed-off-by: Sascha Hauer <[EMAIL PROTECTED]> > > As we didn't get negative feedback yet, could this go into the 2.6.26 > merge window? I didn't see this the first time (didn't get cc'd). It looks mostly okay, but in doesn't have any mutual exclusion which it probably should have. What are the users of this? Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc5200: add interrupt type function
On Tue, Apr 15, 2008 at 05:29:54PM +0200, Robert Schwebel wrote: > From: Sascha Hauer <[EMAIL PROTECTED]> > > Add a set_type function for external (GPIO) interrupts. > > Signed-off-by: Juergen Beisert <[EMAIL PROTECTED]> > Signed-off-by: Sascha Hauer <[EMAIL PROTECTED]> As we didn't get negative feedback yet, could this go into the 2.6.26 merge window? Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] [POWERPC] irqtrace support to 64-bit powerpc
This adds the low level irq tracing hooks to the powerpc architecture
needed to enable full lockdep functionality
Partly based on Johannes Berg's initial version, removing the asm
trampoline that isn't needed (thus improving perfs) and all sorts
of bits and pieces, reworking most of the assembly, etc...
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig|9 +++
arch/powerpc/kernel/entry_64.S | 27 +-
arch/powerpc/kernel/head_64.S | 47 +++-
arch/powerpc/kernel/irq.c |3 +-
arch/powerpc/kernel/ppc_ksyms.c |4 ---
arch/powerpc/kernel/setup_64.c |4 +++
include/asm-powerpc/exception.h |6 ++---
include/asm-powerpc/hw_irq.h| 13 +--
include/asm-powerpc/irqflags.h | 37 +--
include/asm-powerpc/rwsem.h | 35 ++---
include/asm-powerpc/spinlock.h |1
11 files changed, 134 insertions(+), 52 deletions(-)
--- linux-work.orig/arch/powerpc/Kconfig2008-04-17 14:23:30.0
+1000
+++ linux-work/arch/powerpc/Kconfig 2008-04-17 14:30:06.0 +1000
@@ -53,6 +53,15 @@ config STACKTRACE_SUPPORT
bool
default y
+config TRACE_IRQFLAGS_SUPPORT
+ bool
+ depends on PPC64
+ default y
+
+config LOCKDEP_SUPPORT
+ bool
+ default y
+
config RWSEM_GENERIC_SPINLOCK
bool
Index: linux-work/arch/powerpc/kernel/irq.c
===
--- linux-work.orig/arch/powerpc/kernel/irq.c 2008-04-17 14:29:57.0
+1000
+++ linux-work/arch/powerpc/kernel/irq.c2008-04-17 14:30:06.0
+1000
@@ -114,7 +114,7 @@ static inline void set_soft_enabled(unsi
: : "r" (enable), "i" (offsetof(struct paca_struct, soft_enabled)));
}
-void local_irq_restore(unsigned long en)
+void raw_local_irq_restore(unsigned long en)
{
/*
* get_paca()->soft_enabled = en;
@@ -174,6 +174,7 @@ void local_irq_restore(unsigned long en)
__hard_irq_enable();
}
+EXPORT_SYMBOL(raw_local_irq_restore);
#endif /* CONFIG_PPC64 */
int show_interrupts(struct seq_file *p, void *v)
Index: linux-work/arch/powerpc/kernel/ppc_ksyms.c
===
--- linux-work.orig/arch/powerpc/kernel/ppc_ksyms.c 2008-04-17
13:10:10.0 +1000
+++ linux-work/arch/powerpc/kernel/ppc_ksyms.c 2008-04-17 14:30:06.0
+1000
@@ -45,10 +45,6 @@
#include
#include
-#ifdef CONFIG_PPC64
-EXPORT_SYMBOL(local_irq_restore);
-#endif
-
#ifdef CONFIG_PPC32
extern void transfer_to_handler(void);
extern void do_IRQ(struct pt_regs *regs);
Index: linux-work/include/asm-powerpc/hw_irq.h
===
--- linux-work.orig/include/asm-powerpc/hw_irq.h2008-04-17
13:10:10.0 +1000
+++ linux-work/include/asm-powerpc/hw_irq.h 2008-04-17 14:30:06.0
+1000
@@ -27,7 +27,7 @@ static inline unsigned long local_get_fl
return flags;
}
-static inline unsigned long local_irq_disable(void)
+static inline unsigned long raw_local_irq_disable(void)
{
unsigned long flags, zero;
@@ -39,14 +39,15 @@ static inline unsigned long local_irq_di
return flags;
}
-extern void local_irq_restore(unsigned long);
+extern void raw_local_irq_restore(unsigned long);
extern void iseries_handle_interrupts(void);
-#define local_irq_enable() local_irq_restore(1)
-#define local_save_flags(flags)((flags) = local_get_flags())
-#define local_irq_save(flags) ((flags) = local_irq_disable())
+#define raw_local_irq_enable() raw_local_irq_restore(1)
+#define raw_local_save_flags(flags)((flags) = local_get_flags())
+#define raw_local_irq_save(flags) ((flags) = raw_local_irq_disable())
-#define irqs_disabled()(local_get_flags() == 0)
+#define raw_irqs_disabled()(local_get_flags() == 0)
+#define raw_irqs_disabled_flags(flags) ((flags) == 0)
#define __hard_irq_enable()__mtmsrd(mfmsr() | MSR_EE, 1)
#define __hard_irq_disable() __mtmsrd(mfmsr() & ~MSR_EE, 1)
Index: linux-work/include/asm-powerpc/irqflags.h
===
--- linux-work.orig/include/asm-powerpc/irqflags.h 2008-04-17
13:10:10.0 +1000
+++ linux-work/include/asm-powerpc/irqflags.h 2008-04-17 14:30:06.0
+1000
@@ -2,30 +2,43 @@
* include/asm-powerpc/irqflags.h
*
* IRQ flags handling
- *
- * This file gets included from lowlevel asm headers too, to provide
- * wrapped versions of the local_irq_*() APIs, based on the
- * raw_local_irq_*() macros from the lowlevel headers.
*/
#ifndef _ASM_IRQFLAGS_H
#define _ASM_IRQFLAGS_H
+#ifndef __ASSEMBLY__
/*
* Get definitions for raw_local_save_flags(x), etc.
*/
#include
+#else
+#ifdef CONFIG_TRACE_IRQFLAGS
/*
- * Do the
[PATCH 2/3] [POWERPC] lockdep stacktrace support
From: Christoph Hellwig <[EMAIL PROTECTED]>
I recently tried to work on lockdep for powerpc. I have preliminary
version of the stacktrace code, but had to give up on trace irqflags
support because I'm not that knowledgeable on lowlevel ppc details.
Maybe someone more faimilar with the code wants to give it another try?
My stacktrace code is below:
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig |4 +++
arch/powerpc/kernel/Makefile |1
arch/powerpc/kernel/stacktrace.c | 47 +++
3 files changed, 52 insertions(+)
--- linux-work.orig/arch/powerpc/Kconfig2008-04-17 13:17:06.0
+1000
+++ linux-work/arch/powerpc/Kconfig 2008-04-17 13:24:30.0 +1000
@@ -49,6 +49,10 @@ config IRQ_PER_CPU
bool
default y
+config STACKTRACE_SUPPORT
+ bool
+ default y
+
config RWSEM_GENERIC_SPINLOCK
bool
Index: linux-work/arch/powerpc/kernel/Makefile
===
--- linux-work.orig/arch/powerpc/kernel/Makefile2008-04-17
13:17:06.0 +1000
+++ linux-work/arch/powerpc/kernel/Makefile 2008-04-17 13:24:31.0
+1000
@@ -67,6 +67,7 @@ obj-$(CONFIG_BOOTX_TEXT) += btext.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o
+obj-$(CONFIG_STACKTRACE) += stacktrace.o
pci64-$(CONFIG_PPC64) += pci_dn.o isa-bridge.o
obj-$(CONFIG_PCI) += pci_$(CONFIG_WORD_SIZE).o $(pci64-y) \
Index: linux-work/arch/powerpc/kernel/stacktrace.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-work/arch/powerpc/kernel/stacktrace.c 2008-04-17 13:24:47.0
+1000
@@ -0,0 +1,47 @@
+/*
+ * Stack trace utility
+ *
+ * Copyright 2008 Christoph Hellwig, IBM Corp.
+ *
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+
+/*
+ * Save stack-backtrace addresses into a stack_trace buffer.
+ */
+void save_stack_trace(struct stack_trace *trace)
+{
+ unsigned long sp;
+
+ asm("mr %0,1" : "=r" (sp));
+
+ for (;;) {
+ unsigned long *stack = (unsigned long *) sp;
+ unsigned long newsp, ip;
+
+ if (!validate_sp(sp, current, STACK_FRAME_OVERHEAD))
+ return;
+
+ newsp = stack[0];
+ ip = stack[STACK_FRAME_LR_SAVE];
+
+ if (!trace->skip)
+ trace->entries[trace->nr_entries++] = ip;
+ else
+ trace->skip--;
+
+ if (trace->nr_entries >= trace->max_entries)
+ return;
+
+ sp = newsp;
+ }
+}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] [POWERPC] Move stackframe definitions to common header
This patch moves various definitions used all over the place
to parse stack frames to ptrace.h so only one definition is
needed.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/entry_64.S |3 ++-
arch/powerpc/kernel/head_32.S |5 +++--
arch/powerpc/kernel/process.c | 28 +++-
arch/powerpc/xmon/xmon.c | 13 +
include/asm-powerpc/ptrace.h |9 +
5 files changed, 26 insertions(+), 32 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/process.c 2008-04-17
13:21:33.0 +1000
+++ linux-work/arch/powerpc/kernel/process.c2008-04-17 13:22:29.0
+1000
@@ -919,20 +919,6 @@ int validate_sp(unsigned long sp, struct
return valid_irq_stack(sp, p, nbytes);
}
-#ifdef CONFIG_PPC64
-#define MIN_STACK_FRAME112 /* same as STACK_FRAME_OVERHEAD, in
fact */
-#define FRAME_LR_SAVE 2
-#define INT_FRAME_SIZE (sizeof(struct pt_regs) + STACK_FRAME_OVERHEAD + 288)
-#define REGS_MARKER0x7265677368657265ul
-#define FRAME_MARKER 12
-#else
-#define MIN_STACK_FRAME16
-#define FRAME_LR_SAVE 1
-#define INT_FRAME_SIZE (sizeof(struct pt_regs) + STACK_FRAME_OVERHEAD)
-#define REGS_MARKER0x72656773ul
-#define FRAME_MARKER 2
-#endif
-
EXPORT_SYMBOL(validate_sp);
unsigned long get_wchan(struct task_struct *p)
@@ -944,15 +930,15 @@ unsigned long get_wchan(struct task_stru
return 0;
sp = p->thread.ksp;
- if (!validate_sp(sp, p, MIN_STACK_FRAME))
+ if (!validate_sp(sp, p, STACK_FRAME_OVERHEAD))
return 0;
do {
sp = *(unsigned long *)sp;
- if (!validate_sp(sp, p, MIN_STACK_FRAME))
+ if (!validate_sp(sp, p, STACK_FRAME_OVERHEAD))
return 0;
if (count > 0) {
- ip = ((unsigned long *)sp)[FRAME_LR_SAVE];
+ ip = ((unsigned long *)sp)[STACK_FRAME_LR_SAVE];
if (!in_sched_functions(ip))
return ip;
}
@@ -981,12 +967,12 @@ void show_stack(struct task_struct *tsk,
lr = 0;
printk("Call Trace:\n");
do {
- if (!validate_sp(sp, tsk, MIN_STACK_FRAME))
+ if (!validate_sp(sp, tsk, STACK_FRAME_OVERHEAD))
return;
stack = (unsigned long *) sp;
newsp = stack[0];
- ip = stack[FRAME_LR_SAVE];
+ ip = stack[STACK_FRAME_LR_SAVE];
if (!firstframe || ip != lr) {
printk("["REG"] ["REG"] ", sp, ip);
print_symbol("%s", ip);
@@ -1000,8 +986,8 @@ void show_stack(struct task_struct *tsk,
* See if this is an exception frame.
* We look for the "regshere" marker in the current frame.
*/
- if (validate_sp(sp, tsk, INT_FRAME_SIZE)
- && stack[FRAME_MARKER] == REGS_MARKER) {
+ if (validate_sp(sp, tsk, STACK_INT_FRAME_SIZE)
+ && stack[STACK_FRAME_MARKER] == STACK_FRAME_REGS_MARKER) {
struct pt_regs *regs = (struct pt_regs *)
(sp + STACK_FRAME_OVERHEAD);
printk("--- Exception: %lx", regs->trap);
Index: linux-work/arch/powerpc/xmon/xmon.c
===
--- linux-work.orig/arch/powerpc/xmon/xmon.c2008-04-17 13:23:21.0
+1000
+++ linux-work/arch/powerpc/xmon/xmon.c 2008-04-17 13:30:13.0 +1000
@@ -1244,15 +1244,12 @@ static void get_function_bounds(unsigned
static int xmon_depth_to_print = 64;
-#ifdef CONFIG_PPC64
-#define LRSAVE_OFFSET 0x10
-#define REG_FRAME_MARKER 0x7265677368657265ul/* "regshere" */
-#define MARKER_OFFSET 0x60
+#define LRSAVE_OFFSET (STACK_FRAME_LR_SAVE * sizeof(unsigned long))
+#define MARKER_OFFSET (STACK_FRAME_MARKER * sizeof(unsigned long))
+
+#ifdef __powerpc64__
#define REGS_OFFSET0x70
#else
-#define LRSAVE_OFFSET 4
-#define REG_FRAME_MARKER 0x72656773
-#define MARKER_OFFSET 8
#define REGS_OFFSET16
#endif
@@ -1318,7 +1315,7 @@ static void xmon_show_stack(unsigned lon
/* Look for "regshere" marker to see if this is
an exception frame. */
if (mread(sp + MARKER_OFFSET, &marker, sizeof(unsigned long))
- && marker == REG_FRAME_MARKER) {
+ && marker == STACK_FRAME_REGS_MARKER) {
if (mread(sp + REGS_OFFSET, ®s, sizeof(regs))
!= sizeof(regs)) {
printf("Couldn't read registers at %lx\n",
Index: linux-work/include/asm-powerpc/ptrace.h
===
--- linux-w
Re: [GIT PULL] Please pull spufs master branch
> A few bugfixes for spufs. ... just in case you're not omnipotent, here's the git URL: git://git.kernel.org/pub/scm/linux/kernel/git/jk/spufs.git master Cheers, Jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[GIT PULL] Please pull spufs master branch
Hi Paul,
A few bugfixes for spufs.
Cheers,
Jeremy
--- 4 commits:
[POWERPC] spufs: add newline to signal{1,2}_type files
Jeremy Kerr <[EMAIL PROTECTED]>
arch/powerpc/platforms/cell/spufs/file.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
[POWERPC] spufs: reacquire LS pointer in spu_process_callback
Jeremy Kerr <[EMAIL PROTECTED]>
arch/powerpc/platforms/cell/spufs/run.c|4
1 file changed, 4 insertions(+)
[POWERPC] spufs: save MFC command channel before purging MFC queue
Jeremy Kerr <[EMAIL PROTECTED]>
arch/powerpc/platforms/cell/spufs/switch.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[POWERPC] spufs: fix incorrect file descriptors in SPU coredump note names
Gerhard Stenzel <[EMAIL PROTECTED]>
arch/powerpc/platforms/cell/spufs/coredump.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v2][POWERPC] qe_lib and ucc_geth: switch to the cpm_muram implementation
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Anton Vorontsov > Sent: Thursday, April 17, 2008 2:22 AM > To: Kumar Gala > Cc: Wood Scott; linuxppc-dev@ozlabs.org; Jeff Garzik; Tabi > Timur; [EMAIL PROTECTED] > Subject: [PATCH v2][POWERPC] qe_lib and ucc_geth: switch to > the cpm_muramimplementation > > This is very trivial patch. We're transitioning to the > cpm_muram_* calls. That's it. Hi Anoton, It is a good thing to unify the CPM dpram operation and QE muram operation. But I'm having concerns about the naming as CPM is an obsolete block. Can we change to use the new name QE instead? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/11] cell: generalize io-workarounds code
So I found a few issues with your patch. Below is a "Fixup" patch that
fixes the QS20 cell blades for me, but I would like you to apply that
directly to your series and post a new version of it so that there
is no breakage of QS20 during bisection.
Note that I believe Celleb may have some problems too. See below.
So the base issue was that on QS20, there was no struct device, thus the
dma mapping would crash.
I fixed that by changing the Cell blades code to create
of_platform_device's for the PCI busses like it does on QS21 or later,
and removed the initial call to the rtas PCI bus creation.
Now, that doesn't fix it all
One thing I noticed in celleb_pci is that you initialize the workarounds
for the bus after it's been created at device_initcall time. This is not
good because at that time, drivers can already have been loaded &
initialized, quirks have been run, etc... so it's actually too late to
initialize the workarounds. They need to be initialized earlier.
I've tried something around the lines of initializing them from within
the PHB setup callback, which happens before the PCI probe. You should
be able to use the same approach for Celleb I suppose. Seems to work for
me so far...
In addition, your patch would have called io_workaround_init() on QS21
which doesn't need them (no Spider), thus slowing down access on
machines that don't need the workarounds.
My new code should hopefully only call this when needed. I made the call
safe to call multiple time to avoid having to test in the caller.
Another thing I noticed is that you removed the workaround to disable
PCI prefetch. Is there a reason for that ? As far as I understand,
prefetch is broken and can cause errors ranging from data corruption to
iommu exceptions if the iommu is enabled. Maybe you want to make it
depend on the revision of Spider in case your SCC has that fixed ?
My patch doesn't change that but we might need to...
So here is the patch. Please integrate my changes in your patch serie
and re-post it (minus the two patches that Paulus already accepted).
Cheers,
Ben.
Index: linux-work/arch/powerpc/kernel/of_platform.c
===
--- linux-work.orig/arch/powerpc/kernel/of_platform.c 2008-04-17
11:31:32.0 +1000
+++ linux-work/arch/powerpc/kernel/of_platform.c2008-04-17
11:31:53.0 +1000
@@ -275,6 +275,8 @@ static int __devinit of_pci_phb_probe(st
/* Scan the bus */
scan_phb(phb);
+ if (phb->bus == NULL)
+ return -ENXIO;
/* Claim resources. This might need some rework as well depending
* wether we are doing probe-only or not, like assigning unassigned
Index: linux-work/arch/powerpc/platforms/cell/spider-pci.c
===
--- linux-work.orig/arch/powerpc/platforms/cell/spider-pci.c2008-04-17
11:31:53.0 +1000
+++ linux-work/arch/powerpc/platforms/cell/spider-pci.c 2008-04-17
11:44:12.0 +1000
@@ -25,17 +25,12 @@
#include
#include
#include
+#include
#include "io-workarounds.h"
#undef SPIDER_PCI_DISABLE_PREFETCH
-#define SPIDER_PCI_REG_BASE0xd000
-#define SPIDER_PCI_REG_SIZE0x1000
-#define SPIDER_PCI_VCI_CNTL_STAT 0x0110
-#define SPIDER_PCI_DUMMY_READ 0x0810
-#define SPIDER_PCI_DUMMY_READ_BASE 0x0814
-
struct spiderpci_iowa_private {
void __iomem *regs;
};
@@ -187,31 +182,3 @@ struct ppc_pci_io spiderpci_ops = {
.memcpy_fromio = spiderpci_memcpy_fromio,
};
-/* We must setup the IOMMU before spider_io_workaround_init() is called. */
-static int __init spider_pci_workaround_init(void)
-{
- struct pci_controller *phb;
-
- /* Find spider bridges. We assume they have been all probed
-* in setup_arch(). If that was to change, we would need to
-* update this code to cope with dynamically added busses
-*/
- list_for_each_entry(phb, &hose_list, list_node) {
- struct device_node *np = phb->dn;
- const char *model = of_get_property(np, "model", NULL);
-
- /* If no model property or name isn't exactly "pci", skip */
- if (model == NULL || strcmp(np->name, "pci"))
- continue;
- /* If model is not "Spider", skip */
- if (strcmp(model, "Spider"))
- continue;
- iowa_register_bus(phb, &spiderpci_ops, &spiderpci_iowa_init,
- (void *)SPIDER_PCI_REG_BASE);
- }
-
- io_workaround_init();
-
- return 0;
-}
-machine_arch_initcall_sync(cell, spider_pci_workaround_init);
Index: linux-work/arch/powerpc/platforms/cell/io-workarounds.c
===
--- linux-work.orig/arch/powerpc/platforms/cell/io-workarounds.c
2008-04-17 11:31:53.0 +1000
+++ linux-work/arch/powerpc/p
a question about serial driver on MPC8313
hello all: In my system, the CPU is MPC8313. When i debug it, i can't find the serial driver for the MPC8313 soc, i can only find the file 8250.c which is in the /drivers/serial directory. I am not sure the source code is the serial driver for the MPC8313. Could any one can help me to solve this problem or some one can give me some advises. thanks best wishs - 雅虎邮箱，您的终生邮箱！___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] natsemi: fix MMIO for PPC 44x platforms
Sergei Shtylyov wrote: The driver stores the PCI resource address into 'unsigned long' variable before calling ioremap() on it. This warrants a kernel oops when the registers are accessed on PPC 44x platforms which (being 32-bit) have PCI memory space mapped beyond 4 GB. The arch/ppc/ kernel has a fixup in ioremap() that creates an illusion of the PCI memory resources are mapped below 4 GB, but arch/powerpc/ code got rid of this trick, having instead CONFIG_RESOURCES_64BIT enabled. Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]> --- Reposting the patch with the typecast, log, and summary corrected. This is the same issue as the one that has been recently addressed by commits 3c34ac36ac1084e571ef9b6fb1d6a5b10ccc1fd0 (e1000: Fix for 32 bits platforms with 64 bits resources) and c976816b6e901341ec3c4653147316c15549a1c4 (siimage: fix kernel oops on PPC 44x). The patch has only been compile tested though... drivers/net/natsemi.c | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) applied ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MV64x60 device bus
Hi, I am working on a board with an MV64460 and this controller has what its data sheet call a device controller (ie a generic asynchronous bus to connect NOR flashes and other similar devices). On this board a NOR flash is connected to it and I would like to get it to be recognized by the Open Firmware MTD map driver. The problem is that this driver expects the flash to be registered as an of_platform device, I could do that in the board file itself but I think it would be more useful to add some generic code for all MV64360 based boards: My idea would be to add to the MV64360 initialization code the registration of an of_platform bus if a node of type 'devicectrl' is found (inside the mv64360 node); this node would contain all the devices attached to the device bus and the of_platform sub-system would take care of creating the proper of_platform devices. Does anyone have comments or a better idea ? Thanks, Remi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
More patches pushed to powerpc.git master and powerpc-next branches (second try)
The following commits are now in the master and powerpc-next branches in the powerpc.git tree. This includes commits pulled from Josh Boyer's and Olof Johansson's trees. There was a short period recently (approx. 12 hours ago) when powerpc.git had a string of commits including two that broke the ibm-newemac driver on some platforms. If you pulled during that period then you'll need to do a git pull -f when you pull this lot. Paul. Adrian Bunk (1): [POWERPC] Add MODULE_LICENSE to powerpc/sysdev/rtc_cmos_setup.c Anton Vorontsov (2): [POWERPC] OF helpers for the GPIO API [POWERPC] Implement support for the GPIO LIB API Benjamin Herrenschmidt (3): [POWERPC] Initialize paca->current earlier [POWERPC] Fixup softirq preempt count [POWERPC] properly declare onstack completion in iseries veth David Woodhouse (1): [POWERPC] Efika: Really, don't pretend to be CHRP Ishizaki Kou (2): [POWERPC] celleb: Coding style cleanup [POWERPC] hvcbeat: Fix buffer manipulation Jerone Young (1): [POWERPC] 4xx: Add idle wait support for 44x platforms Jochen Friedrich (1): [POWERPC] i2c: OF helpers for the i2c API Josh Boyer (2): [POWERPC] 4xx: Reorganize 4xx defconfigs [POWERPC] 4xx: Add ppc40x_defconfig Kumar Gala (13): [POWERPC] Remove Kconfig option BOOT_LOAD [POWERPC] Provide access to arch/powerpc include path on ppc64 [POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr [POWERPC] Introduce lowmem_end_addr to distinguish from total_lowmem [POWERPC] 85xx: Cleanup TLB initialization [POWERPC] Use lowmem_end_addr to limit lmb allocations on ppc32 [POWERPC] Rename __initial_memory_limit to __initial_memory_limit_addr [POWERPC] Clean up some linker and symbol usage [POWERPC] Move phys_addr_t definition into asm/types.h [POWERPC] Update linker script to properly set physical addresses [POWERPC] bootwrapper: Use physical address in PHDR for uImage [POWERPC] Cleanup pgtable-ppc32.h [POWERPC] Remove unused machine call outs Manish Ahuja (1): [POWERPC] pseries/phyp dump: Reserve a variable amount of space at boot Michael Ellerman (2): [POWERPC] Move prototype for find_udbg_vterm() into a header file [POWERPC] Always add preferred consoles in platforms/pseries/lpar.c Nate Case (1): pasemi_mac: Netpoll support Olof Johansson (2): pasemi_mac: Jumbo frame bugfixes [POWERPC] pasemi: Minor iommu cleanup Valentine Barshak (1): [POWERPC] kexec: MPIC ack interrupts at mpic_teardown_this_cpu() ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
On Thu, Apr 17, 2008 at 01:00:42AM +0400, Anton Vorontsov wrote: > On Wed, Apr 16, 2008 at 01:44:42PM -0500, Scott Wood wrote: > > A maximal timeout of ~65 ms is a little low... For use as a wakeup from > > sleep mode, I'd like to be able to request timeouts as large as the > > hardware allows. > > That is about precision. You just need to implement gtm_reset_stimer() > is you want precision with a seconds, this will run a timer at 1 Hz. Enh. I'm not crazy about having to call separately named functions, rather than have the timer code set the reference clock to the highest precision that has the needed range. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: lseek() on entries in /proc/device-tree returns EINVAL
> -Original Message- > From: Timur Tabi [mailto:[EMAIL PROTECTED] > Sent: den 16 april 2008 23:16 > To: Joakim Tjernlund > Cc: linuxppc-dev@ozlabs.org > Subject: Re: lseek() on entries in /proc/device-tree returns EINVAL > > Joakim Tjernlund wrote: > > > Good, bb should probably do the same. I just hope Al will allow a grace > > period and restore > > the old behavior so bb can catch up. > > I don't see any reason why lseek() should not always work. Besides, a "grace > period" would mean that on some future kernel, older busybox will not work. Sure, but better a grace period than none at all. Currently no bb works but with a grace period you can at least tell users to upgrade bb when the grace period is over. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: lseek() on entries in /proc/device-tree returns EINVAL
Joakim Tjernlund wrote: > Good, bb should probably do the same. I just hope Al will allow a grace > period and restore > the old behavior so bb can catch up. I don't see any reason why lseek() should not always work. Besides, a "grace period" would mean that on some future kernel, older busybox will not work. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: lseek() on entries in /proc/device-tree returns EINVAL
> -Original Message- > From: Timur Tabi [mailto:[EMAIL PROTECTED] > Sent: den 16 april 2008 23:11 > To: Joakim Tjernlund > Cc: linuxppc-dev@ozlabs.org > Subject: Re: lseek() on entries in /proc/device-tree returns EINVAL > > Joakim Tjernlund wrote: > > > Yeah, just reported a similar problem at LKML. busybox start-stop-daemon > > broke > > between 2.6.23 and current tree. The change was intentional but the borkage > > was not. Al Viro has been informed, lets see what comes of it. > > I've changed my code to use fstat() instead, which is better for my purposes > anyway. Good, bb should probably do the same. I just hope Al will allow a grace period and restore the old behavior so bb can catch up. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: lseek() on entries in /proc/device-tree returns EINVAL
Joakim Tjernlund wrote: > Yeah, just reported a similar problem at LKML. busybox start-stop-daemon broke > between 2.6.23 and current tree. The change was intentional but the borkage > was not. Al Viro has been informed, lets see what comes of it. I've changed my code to use fstat() instead, which is better for my purposes anyway. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: lseek() on entries in /proc/device-tree returns EINVAL
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linuxppc-dev-
> [EMAIL PROTECTED] On Behalf Of Timur Tabi
> Sent: den 16 april 2008 22:58
> To: linuxppc-dev@ozlabs.org
> Subject: lseek() on entries in /proc/device-tree returns EINVAL
>
> I'm writing a utility that parses the device tree in /proc/device-tree, and in
> order to read a property into memory, I have to first find out how large it
> is.
> So I have the following code:
>
> off_t off;
> int f;
>
> f = open(filename, O_RDONLY);
> if (f == -1) {
> perror(__func__);
> return NULL;
> }
>
> off = lseek(f, 0, SEEK_END);
> if (off == -1) {
> perror(__func__);
> goto fail;
> }
>
> The lseek() call returns -1, and errno is set to EINVAL. According to the man
> page, this means:
>
>EINVAL The whence argument is not a proper value, or the resulting
> file offset would be negative for a regular file, block special
> file, or directory.
>
> Is there a limitation for the implementation of /proc/device-tree that
> prevents
> lseek() from working? If so, how do I determine the size of a property?
Yeah, just reported a similar problem at LKML. busybox start-stop-daemon broke
between 2.6.23 and current tree. The change was intentional but the borkage
was not. Al Viro has been informed, lets see what comes of it.
Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: lseek() on entries in /proc/device-tree returns EINVAL
On Wed, Apr 16, 2008 at 03:57:59PM -0500, Timur Tabi wrote: > Is there a limitation for the implementation of /proc/device-tree that > prevents > lseek() from working? If so, how do I determine the size of a property? Try fstat(). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
On Wed, Apr 16, 2008 at 01:44:42PM -0500, Scott Wood wrote: > On Wed, Apr 16, 2008 at 10:39:04PM +0400, Anton Vorontsov wrote: > > +/** > > + * gtm_reset_utimer16 - reset 16 bits timer > > + * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer > > + * @usec: timer interval in microseconds > > + * @free_run: free run flag > > + * > > + * This function (re)sets GTM timer so it counts up to the interval value > > and > > + * fires the interrupt when the value is reached. If free_run flag was set, > > + * timer will also reset itself upon reference value, otherwise it > > continues to > > + * increment. > > + */ > > +int gtm_reset_utimer16(struct gtm_timer *tmr, u16 usec, bool free_run) > > A maximal timeout of ~65 ms is a little low... For use as a wakeup from > sleep mode, I'd like to be able to request timeouts as large as the > hardware allows. That is about precision. You just need to implement gtm_reset_stimer() is you want precision with a seconds, this will run a timer at 1 Hz. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
lseek() on entries in /proc/device-tree returns EINVAL
I'm writing a utility that parses the device tree in /proc/device-tree, and in
order to read a property into memory, I have to first find out how large it is.
So I have the following code:
off_t off;
int f;
f = open(filename, O_RDONLY);
if (f == -1) {
perror(__func__);
return NULL;
}
off = lseek(f, 0, SEEK_END);
if (off == -1) {
perror(__func__);
goto fail;
}
The lseek() call returns -1, and errno is set to EINVAL. According to the man
page, this means:
EINVAL The whence argument is not a proper value, or the resulting
file offset would be negative for a regular file, block special
file, or directory.
Is there a limitation for the implementation of /proc/device-tree that prevents
lseek() from working? If so, how do I determine the size of a property?
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pseries: phyp dump: Variable size reserve space.
On 07/04/2008, Manish Ahuja <[EMAIL PROTECTED]> wrote:
> A small proposed change in the amount of reserve space we allocate during
> boot.
> Currently we reserve 256MB only.
> The proposed change does one of the 3 things.
>
> A. It checks to see if there is cmdline variable set and if found sets the
>value to it. OR
> B. It computes 5% of total ram and rounds it down to multiples of 256MB. AND
> C. Compares the rounded down value and returns larger of two values, the new
>computed value or 256MB.
>
> Again this is for large systems who have excess memory.
>
[...]
> early_param("phyp_dump", early_phyp_dump_enabled);
I'm pretty sure you will want to document this boot param in the documentation,
as well as add a few words about why it might be interesting to users (i.e.
that its for large systems...)
--linas
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pseries: phyp dump: Variable size reserve space.
The aim is to have more flex space for the kernel on machines with more resources. Although the dump will be collected pretty fast and the memory released really early on allowing the machine to have the full memory available, this alleviates any issues that can be caused by having way too little memory on very very large systems during those few minutes. -Manish I think this would be an issue for distro kernels that have minimum requirements for memory above 256MB. It seems like a reasonable attempt to have good defaults. The user can always override it with boot args. I'm not sure where the exact numbers should be but the general statement that larger memory systems should have more memory to boot with seems like a good one. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
USB on MPC8641D
Hi Everybody, I find this forum very much useful for the people who are working with powerpc's , and i am the one of them.Actually one more thing that make me to join this forum is my interest towards the Freescale MPC8641d board :-). I found that Freescale recently uploaded the linux BSP for MPC8641D board. One of the thing new in this BSP is USB driver. At Ozlabs I found various patches for MPC8641D board,Most of then are regarding the PCI Express fixes, Some patches of ULI1575 chip, but my main concern is USB. Can amyone help me out to find , what are the changes that freescale does for the USB drivers. I tried to search a lot for USB patch, but my bad luck , i don't find anything. It would be a great help if anyone help me out to find what are the changes that freescale does for USB driver. Thanks John - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
On Wed, Apr 16, 2008 at 10:39:04PM +0400, Anton Vorontsov wrote: > +/** > + * gtm_reset_utimer16 - reset 16 bits timer > + * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer > + * @usec:timer interval in microseconds > + * @free_run:free run flag > + * > + * This function (re)sets GTM timer so it counts up to the interval value and > + * fires the interrupt when the value is reached. If free_run flag was set, > + * timer will also reset itself upon reference value, otherwise it continues > to > + * increment. > + */ > +int gtm_reset_utimer16(struct gtm_timer *tmr, u16 usec, bool free_run) A maximal timeout of ~65 ms is a little low... For use as a wakeup from sleep mode, I'd like to be able to request timeouts as large as the hardware allows. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
On Tue, Mar 18, 2008 at 03:48:12PM -0500, Scott Wood wrote:
[...]
> How about:
>
> struct gtm_timer *gtm_get_specific_timer(struct gtm *gtm, int timer,
> int width);
>
> ...with np->data used by the caller to figure out which gtm pointer to
> pass in.
Thanks for the comments, I've tried to address them all.
Updated patch below (not for applying, still waiting for further
comments, if any).
- - - -
From: Anton Vorontsov <[EMAIL PROTECTED]>
Subject: [POWERPC] sysdev,qe_lib: implement FSL GTM support
GTM stands for General-purpose Timers Module and able to generate
timer{1,2,3,4} interrupts.
There are several limitations in this support:
1. Cascaded (32 bit) timers unimplemented (1-2, 3-4).
This is straightforward to implement when needed, two timers should
be marked as "requested" and configured as appropriate.
2. Super-cascaded (64 bit) timers unimplemented (1-2-3-4).
This is also straightforward to implement when needed, all timers
should be marked as "requested" and configured as appropriate.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 32 +++-
arch/powerpc/Kconfig |5 +
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/fsl_gtm.c| 322 ++
include/asm-powerpc/fsl_gtm.h| 106 +
5 files changed, 465 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/sysdev/fsl_gtm.c
create mode 100644 include/asm-powerpc/fsl_gtm.h
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index f19fe9f..ee14ecd 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -57,7 +57,8 @@ Table of Contents
n) 4xx/Axon EMAC ethernet nodes
o) Xilinx IP cores
p) Freescale Synchronous Serial Interface
- q) USB EHCI controllers
+ q) USB EHCI controllers
+ r) Freescale General-purpose Timers Module
VII - Specifying interrupt information for devices
1) interrupts property
@@ -2795,6 +2796,35 @@ platforms are moved over to use the
flattened-device-tree model.
big-endian;
};
+r) Freescale General-purpose Timers Module
+
+Required properties:
+ - compatible : should be "fsl,gtm" ("fsl,qe-gtm" in addition for QE
+ GTMs).
+ - reg : should contain gtm registers location and length (0x40).
+ - interrupts : should contain four interrupts.
+ - interrupt-parent : interrupt source phandle.
+ - clock-frequency : specifies the frequency driving the timer.
+
+Example:
+
+[EMAIL PROTECTED] {
+ compatible = "fsl,gtm";
+ reg = <0x500 0x40>;
+ interrupts = <90 8 78 8 84 8 72 8>;
+ interrupt-parent = <&ipic>;
+ /* filled by u-boot */
+ clock-frequency = <0>;
+};
+
+[EMAIL PROTECTED] {
+ compatible = "fsl,qe-gtm", "fsl,gtm";
+ reg = <0x440 0x40>;
+ interrupts = <12 13 14 15>;
+ interrupt-parent = <&qeic>;
+ /* filled by u-boot */
+ clock-frequency = <0>;
+};
More devices will be defined as this spec matures.
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 00c5e79..dd30ea4 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -520,6 +520,11 @@ config FSL_LBC
help
Freescale Localbus support
+config FSL_GTM
+ bool
+ help
+ Freescale General-purpose Timers support
+
# Yes MCA RS/6000s exist but Linux-PPC does not currently support any
config MCA
bool
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 42b44a1..3974412 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_FSL_PCI) += fsl_pci.o
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
+obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_RAPIDIO) += fsl_rio.o
obj-$(CONFIG_TSI108_BRIDGE)+= tsi108_pci.o tsi108_dev.o
obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
diff --git a/arch/powerpc/sysdev/fsl_gtm.c b/arch/powerpc/sysdev/fsl_gtm.c
new file mode 100644
index 000..6d86983
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_gtm.c
@@ -0,0 +1,322 @@
+/*
+ * Freescale General-purpose Timers Module
+ *
+ * Copyright (c) Freescale Semicondutor, Inc. 2006.
+ * Shlomi Gridish <[EMAIL PROTECTED]>
+ * Jerry Huang <[EMAIL PROTECTED]>
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ * Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the Lic
[PATCH v2][POWERPC] qe_lib and ucc_geth: switch to the cpm_muram implementation
This is very trivial patch. We're transitioning to the cpm_muram_*
calls. That's it.
Less trivial changes:
- BD_SC_* defines were defined in the cpm.h and qe.h, so to avoid redefines
we remove BD_SC from the qe.h and use cpm.h along with cpm_muram_*
prototypes;
- qe_muram_dump was unused and thus removed;
- added some code to the cpm_common.c to support legacy QE bindings
(data-only node name).
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
Oops, this small hunk wormed into the other patch in my series:
>--- a/arch/powerpc/sysdev/cpm_common.c
>+++ b/arch/powerpc/sysdev/cpm_common.c
>@@ -195,7 +195,7 @@ EXPORT_SYMBOL(cpm_muram_addr);
>
> unsigned long cpm_muram_offset(void __iomem *addr)
> {
>- return addr - muram_vbase;
>+ return addr - (void __iomem *)muram_vbase;
> }
> EXPORT_SYMBOL(cpm_muram_offset);
Without it compile will break:
arch/powerpc/sysdev/cpm_common.c: In function ‘cpm_muram_offset’:
arch/powerpc/sysdev/cpm_common.c:198: error: invalid operands to binary -
Fixed patch down below.
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/cpm_common.c | 16 +-
arch/powerpc/sysdev/qe_lib/qe.c | 96 +
arch/powerpc/sysdev/qe_lib/ucc_fast.c |8 ++--
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 18 +++---
drivers/net/ucc_geth.c| 96
include/asm-powerpc/cpm.h |1 +
include/asm-powerpc/qe.h | 29 +--
8 files changed, 79 insertions(+), 186 deletions(-)
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 6d386d0..42b44a1 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -40,6 +40,7 @@ endif
ifeq ($(ARCH),powerpc)
obj-$(CONFIG_CPM) += cpm_common.o
obj-$(CONFIG_CPM2) += cpm2.o cpm2_pic.o
+obj-$(CONFIG_QUICC_ENGINE) += cpm_common.o
obj-$(CONFIG_PPC_DCR) += dcr.o
obj-$(CONFIG_8xx) += mpc8xx_pic.o cpm1.o
obj-$(CONFIG_UCODE_PATCH) += micropatch.o
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index cb7df2d..9b75d16 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -85,9 +85,13 @@ int __init cpm_muram_init(void)
np = of_find_compatible_node(NULL, NULL, "fsl,cpm-muram-data");
if (!np) {
- printk(KERN_ERR "Cannot find CPM muram data node");
- ret = -ENODEV;
- goto out;
+ /* try legacy bindings */
+ np = of_find_node_by_name(NULL, "data-only");
+ if (!np) {
+ printk(KERN_ERR "Cannot find CPM muram data node");
+ ret = -ENODEV;
+ goto out;
+ }
}
muram_pbase = of_translate_address(np, zero);
@@ -189,6 +193,12 @@ void __iomem *cpm_muram_addr(unsigned long offset)
}
EXPORT_SYMBOL(cpm_muram_addr);
+unsigned long cpm_muram_offset(void __iomem *addr)
+{
+ return addr - (void __iomem *)muram_vbase;
+}
+EXPORT_SYMBOL(cpm_muram_offset);
+
/**
* cpm_muram_dma - turn a muram virtual address into a DMA address
* @offset: virtual address from cpm_muram_addr() to convert
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index cff550e..4b48094 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -35,7 +35,6 @@
#include
static void qe_snums_init(void);
-static void qe_muram_init(void);
static int qe_sdma_init(void);
static DEFINE_SPINLOCK(qe_lock);
@@ -99,7 +98,7 @@ void qe_reset(void)
QE_CR_PROTOCOL_UNSPECIFIED, 0);
/* Reclaim the MURAM memory for our use. */
- qe_muram_init();
+ cpm_muram_init();
if (qe_sdma_init())
panic("sdma init failed!");
@@ -314,7 +313,7 @@ static int qe_sdma_init(void)
/* allocate 2 internal temporary buffers (512 bytes size each) for
* the SDMA */
- sdma_buf_offset = qe_muram_alloc(512 * 2, 4096);
+ sdma_buf_offset = cpm_muram_alloc(512 * 2, 4096);
if (IS_ERR_VALUE(sdma_buf_offset))
return -ENOMEM;
@@ -325,97 +324,6 @@ static int qe_sdma_init(void)
return 0;
}
-/*
- * muram_alloc / muram_free bits.
- */
-static DEFINE_SPINLOCK(qe_muram_lock);
-
-/* 16 blocks should be enough to satisfy all requests
- * until the memory subsystem goes up... */
-static rh_block_t qe_boot_muram_rh_block[16];
-static rh_info_t qe_muram_info;
-
-static void qe_muram_init(void)
-{
- struct device_node *np;
- const u32 *address;
- u64 size;
- unsigned int flags;
-
- /* initialize the info header */
- rh_init(&qe_muram_info, 1,
- sizeof(qe_boot_muram_rh_block) /
- sizeof(qe_boot_muram_rh_block[0]), qe_boot_muram_rh_block);
-
- /* Attach the usable muram area */
- /*
[PATCH 1/2] 86xx: mark functions static, other minor cleanups
Cleanups as suggested by Stephen Rothwell and Dale Farnsworth, which
incudes marking a bunch of functions static and add a vendor prefix to
the compat node check for uniqueness.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8641_hpcn.dts |2 +-
arch/powerpc/platforms/86xx/mpc8610_hpcd.c |4 ++--
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |8
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index 79385bc..7f9b999 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -13,7 +13,7 @@
/ {
model = "MPC8641HPCN";
- compatible = "mpc86xx";
+ compatible = "fsl,mpc8641hpcn";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 0b07485..18b8ebe 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -52,7 +52,7 @@ static int __init mpc8610_declare_of_platform_devices(void)
}
machine_device_initcall(mpc86xx_hpcd, mpc8610_declare_of_platform_devices);
-void __init
+static void __init
mpc86xx_hpcd_init_irq(void)
{
struct mpic *mpic1;
@@ -200,7 +200,7 @@ static int __init mpc86xx_hpcd_probe(void)
return 0;
}
-long __init
+static long __init
mpc86xx_time_init(void)
{
unsigned int temp;
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index cfbe8c5..0764032 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -55,7 +55,7 @@ static void mpc86xx_8259_cascade(unsigned int irq, struct
irq_desc *desc)
}
#endif /* CONFIG_PCI */
-void __init
+static void __init
mpc86xx_hpcn_init_irq(void)
{
struct mpic *mpic1;
@@ -162,7 +162,7 @@ mpc86xx_hpcn_setup_arch(void)
}
-void
+static void
mpc86xx_hpcn_show_cpuinfo(struct seq_file *m)
{
struct device_node *root;
@@ -190,13 +190,13 @@ static int __init mpc86xx_hpcn_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (of_flat_dt_is_compatible(root, "mpc86xx"))
+ if (of_flat_dt_is_compatible(root, "fsl,mpc8641hpcn"))
return 1; /* Looks good */
return 0;
}
-long __init
+static long __init
mpc86xx_time_init(void)
{
unsigned int temp;
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] mpc86xx_hpcn: Temporarily accept old dts node identifier.
As suggested by Timur Tabi, we match on the old compat node ID for one
version and warn accordingly. If we don't do this, we plunge people who
try to use an old DTB into silent boot death with no clear indication of
what the problem is.
This patch should be removed at the beginning of the 2.6.27 dev cycle.
It is only meant to ease the transition in the short term.
Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 0764032..f947f55 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -193,6 +193,12 @@ static int __init mpc86xx_hpcn_probe(void)
if (of_flat_dt_is_compatible(root, "fsl,mpc8641hpcn"))
return 1; /* Looks good */
+ /* Be nice and don't give silent boot death. Delete this in 2.6.27 */
+ if (of_flat_dt_is_compatible(root, "mpc86xx")) {
+ pr_warning("WARNING: your dts/dtb is old. You must update
before the next kernel release\n");
+ return 1;
+ }
+
return 0;
}
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib
On Wednesday 16 April 2008 18:05, Anton Vorontsov wrote: > On Wed, Apr 16, 2008 at 04:40:42PM +0200, Laurent Pinchart wrote: > > This patch converts the MII bitband driver to use GPIO lib for GPIO > > access. The driver can now handle MDC and MDIO on different GPIO banks. > > > > The patch depends on Anton Vorontsov GPIO lib support scheduled for > > 2.6.26. It is by no means complete, I just would like to get some feedback > > on the approach. I'll resubmit it when the CPM2 GPIO support patches will > > be available in the powerpc git tree. > > Cool! By the way, maybe it is worth splitting it into completely separate > driver, e.g. net/mdio_gpio.c? Splitting it into a completely separate driver makes sense. > Plus, keep in mind that somebody will eventually want this cool stuff with > platform_device bindings in addition. :-) I'm sure that person will be happy to implement platform_device bindings :-) -- 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 pgpDVmQLRpPPL.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib
On Wed, Apr 16, 2008 at 04:40:42PM +0200, Laurent Pinchart wrote: > This patch converts the MII bitband driver to use GPIO lib for GPIO access. > The driver can now handle MDC and MDIO on different GPIO banks. > > The patch depends on Anton Vorontsov GPIO lib support scheduled for 2.6.26. > It is by no means complete, I just would like to get some feedback on the > approach. I'll resubmit it when the CPM2 GPIO support patches will be > available in the powerpc git tree. Cool! By the way, maybe it is worth splitting it into completely separate driver, e.g. net/mdio_gpio.c? Plus, keep in mind that somebody will eventually want this cool stuff with platform_device bindings in addition. :-) -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC fs_enet: Convert MII bitbang driver to use GPIO lib
This patch converts the MII bitband driver to use GPIO lib for GPIO access.
The driver can now handle MDC and MDIO on different GPIO banks.
The patch depends on Anton Vorontsov GPIO lib support scheduled for 2.6.26.
It is by no means complete, I just would like to get some feedback on the
approach. I'll resubmit it when the CPM2 GPIO support patches will be
available in the powerpc git tree.
---
Documentation/powerpc/booting-without-of.txt | 10 +-
arch/powerpc/boot/dts/mpc8272ads.dts | 16 ++-
arch/powerpc/boot/dts/pq2fads.dts| 16 ++-
drivers/net/fs_enet/fs_enet-main.c | 10 +-
drivers/net/fs_enet/mii-bitbang.c| 177 ++
5 files changed, 127 insertions(+), 102 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 012f231..6f16c2d 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2030,21 +2030,19 @@ platforms are moved over to use the
flattened-device-tree model.
fsl,cpm2-mdio-bitbang (reg is port C registers)
Properties for fsl,cpm2-mdio-bitbang:
- fsl,mdio-pin : pin of port C controlling mdio data
- fsl,mdc-pin : pin of port C controlling mdio clock
+ gpios : GPIOs controlling mdio clock and mdio data (in that order).
Example:
- [EMAIL PROTECTED] {
+ mdio {
device_type = "mdio";
compatible = "fsl,mpc8272ads-mdio-bitbang",
"fsl,mpc8272-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
- reg = <10d40 14>;
#address-cells = <1>;
#size-cells = <0>;
- fsl,mdio-pin = <12>;
- fsl,mdc-pin = <13>;
+ gpios = <&cpm_pio_c 13 0
+&cpm_pio_c 12 0>;
};
v) Baud Rate Generators
diff --git a/arch/powerpc/boot/dts/mpc8272ads.dts
b/arch/powerpc/boot/dts/mpc8272ads.dts
index 7285ca1..bfe359f 100644
--- a/arch/powerpc/boot/dts/mpc8272ads.dts
+++ b/arch/powerpc/boot/dts/mpc8272ads.dts
@@ -164,16 +164,24 @@
fsl,cpm-command = <0ce0>;
};
- [EMAIL PROTECTED] {
+ cpm_pio_c: [EMAIL PROTECTED] {
+ compatible = "fsl,cpm2-pario-bank-c",
+"fsl,cpm2-pario-bank";
+ reg = <0x10d40 0x18>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ mdio {
device_type = "mdio";
compatible = "fsl,mpc8272ads-mdio-bitbang",
"fsl,mpc8272-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
- reg = <10d40 14>;
#address-cells = <1>;
#size-cells = <0>;
- fsl,mdio-pin = <12>;
- fsl,mdc-pin = <13>;
+ gpios = <&cpm_pio_c 13 0/* MDC */
+&cpm_pio_c 12 0/* MDIO */
+ >;
PHY0: [EMAIL PROTECTED] {
interrupt-parent = <&PIC>;
diff --git a/arch/powerpc/boot/dts/pq2fads.dts
b/arch/powerpc/boot/dts/pq2fads.dts
index 2d56492..5c32d42 100644
--- a/arch/powerpc/boot/dts/pq2fads.dts
+++ b/arch/powerpc/boot/dts/pq2fads.dts
@@ -187,16 +187,24 @@
local-mac-address = [00 e0 0c 00 79 01];
};
- [EMAIL PROTECTED] {
+ cpm_pio_c: [EMAIL PROTECTED] {
+ compatible = "fsl,cpm2-pario-bank-c",
+"fsl,cpm2-pario-bank";
+ reg = <0x10d40 0x18>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ mdio {
device_type = "mdio";
compatible = "fsl,pq2fads-mdio-bitbang",
"fsl,mpc8280-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
#address-cells = <1>;
#size-cells = <0>;
- reg = <10d40 14>;
- fsl,mdio-pin = <9>;
- fsl,mdc-pin = ;
+ gpios = <&cpm_pio_c a 0 /* MDC */
+&cpm_pio_c 9 0 /*
EP852
Dear all, I have EP852 board. When I boot the board it gives me an message regarding autoboot ESC for Cancel and Enter to proceed. But I am not able to do either ESC or Enter. So do not know how to proceed. Also would like to ask what is RPX utility ??? Please acknowledge, thanks. Kind Regards,Vijay NikamEmail Disclaimer: ==This e-mail and any files transmitted with it are for the sole use of theintended recipient(s) and may contain confidential and privileged information. Computer viruses can be transmitted via email.The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. Using Symantec Hosted Mail Outbound Server ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull 'for-2.6.26' branch of 4xx tree
On Thu, 17 Apr 2008 00:02:47 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-04-16 at 08:43 -0500, Josh Boyer wrote: > > > > For a final solution, we're going to have to come up with a more > > clever > > way of doing the clocking stuff in ibm_newemac. The SDRs are board > > specific and completely outside of EMAC/MAL itself. So doing a > > dcr_map > > Not board specific... chip specific. Yes, right. Sorry. > > on it becomes a bit more difficult, since there really isn't an SDR > > node in the device tree at the moment. > > That is why I tried hard to avoid the bloody workarounds... > unfortunatly, the HW is crap enough that we have no real choice here. Right. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull 'for-2.6.26' branch of 4xx tree
On Wed, 2008-04-16 at 08:43 -0500, Josh Boyer wrote: > > For a final solution, we're going to have to come up with a more > clever > way of doing the clocking stuff in ibm_newemac. The SDRs are board > specific and completely outside of EMAC/MAL itself. So doing a > dcr_map Not board specific... chip specific. > on it becomes a bit more difficult, since there really isn't an SDR > node in the device tree at the moment. That is why I tried hard to avoid the bloody workarounds... unfortunatly, the HW is crap enough that we have no real choice here. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsl_soc: Factor fsl_get_sys_freq() out of the wdt and spi inits.
On Tue, Apr 15, 2008 at 04:35:54PM -0500, Scott Wood wrote:
> Anton Vorontsov wrote:
>>> +u32 fsl_get_sys_freq(void)
>>> +{
>>> + struct device_node *soc;
>>> + const u32 *prop;
>>> + int size;
>>> +
>>> + if (sysfreq != -1)
>>> + return sysfreq;
>>> +
>>> + soc = of_find_node_by_type(NULL, "soc");
>>> + if (!soc)
>>> + return -1;
>>
>> Um.. can we finally decide on compatible for the soc nodes,
>> and add there compatible matching from the start?
>
> This is just a code reorganization; any change in what we match on
> should be a separate patch.
Yes, it makes sense of course. Just wanted to get rid of the device_type
asap, because I'm going to submit mpc836x_rdk board, and I'd preferred to
submit it w/o device_type = "soc"... Oh well, ok.. later.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: More patches pushed to powerpc.git master and powerpc-next branches
On Wed, 16 Apr 2008 22:42:34 +1000 Paul Mackerras <[EMAIL PROTECTED]> wrote: > I wrote: > > > The following commits are now in the master and powerpc-next branches > > in the powerpc.git tree. This includes commits pulled from Josh > > Boyer's and Olof Johansson's trees. > > Because of a problem caused by a couple of commits in Josh Boyer's > tree, I have forced the master and powerpc-next branches back to where > they were until an hour or so ago. Hopefully no-one has done a pull > in that time; if anyone has then they will need to do a git pull -f > when I eventually push the commits out (since they will have different > IDs). My "next" and "for-2.6.26" branches are reset and the offending patches have been dropped. My apologies for all the trouble. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: More patches pushed to powerpc.git master and powerpc-next branches
On Wed, 16 Apr 2008 22:49:28 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-04-16 at 22:45 +1000, Stephen Rothwell wrote: > > On Wed, 16 Apr 2008 22:32:46 +1000 Paul Mackerras <[EMAIL PROTECTED]> wrote: > > > > > > [POWERPC] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround > > > [POWERPC] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround > > > > So close :-) > > The workaround for those is actually subtely different :-0 He meant that they're broken. See the other threads. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull 'for-2.6.26' branch of 4xx tree
On Wed, 16 Apr 2008 22:50:47 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-04-16 at 07:31 -0500, Josh Boyer wrote:
> > On Wed, 16 Apr 2008 07:27:58 -0500
> > Josh Boyer <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 15 Apr 2008 10:27:04 -0500
> > > Josh Boyer <[EMAIL PROTECTED]> wrote:
> > >
> > > > Valentine Barshak (2):
> > > > [POWERPC] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround
> > > > [POWERPC] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock
> > > > workaround
> > >
> > > These two commits have been dropped from the branch. They cause the
> > > allyesconfig build for powerpc to fail because CONFIG_PPC_DCR_MMIO
> > > doesn't understand the dcri_clrset macro.
> >
> > Crap. Looks like you already pulled the tree. We need to either
> > revert those two commits, or essentially define dcri_clrset to a do {}
> > while(0) in include/asm-powerpc/dcr-mmio.h so things build.
>
> Why ? It should do the right thing, not nop ...
"... so things build." Relax Ben. That isn't a final solution.
I'd rather just do an outright revert of the commits for now.
For a final solution, we're going to have to come up with a more clever
way of doing the clocking stuff in ibm_newemac. The SDRs are board
specific and completely outside of EMAC/MAL itself. So doing a dcr_map
on it becomes a bit more difficult, since there really isn't an SDR
node in the device tree at the moment.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: 4xx build failure
On Wed, 16 Apr 2008 22:51:22 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > Grr. Yes, that's probably the right solution for now. I had forgotten > > about Axon. > > > > Sorry for the trouble. I'll revert those commits locally and repush. > > MMIO is not only Axon.. .some Xilinx stuff too. We should have a proper Yes. But Axon is the only one in-tree that uses it at the moment. > implementation of the dcri stuff for MMIO. Yes, of course. Though neither you or I thought of that when we acked the patch :). josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2.6.26 0/2] Dynamic TBIPA for gianfar
On Apr 16, 2008, at 8:14 AM, Paul Gortmaker wrote: Kumar Gala wrote: On Apr 15, 2008, at 8:57 PM, Paul Gortmaker wrote: On Tue, Apr 15, 2008 at 8:25 PM, Paul Mackerras <[EMAIL PROTECTED]> wrote: Paul Gortmaker writes: This is the resend of the two patches as per Andy's request for v2.6.26 that allow boards with a PHY at the end of the bus to function, by having the TBIPA set dynamically. The 1st patch factors out some of the PHY probe code so it can be recycled by the TBIPA probe, and the second patch implements the dynamic probe itself. I notice that these two patches only touch drivers/net and include/linux. If you want these to go upstream into Linus' tree, you will need to send them to Jeff Garzik and the netdev list. Posting them to the linuxppc-dev list is fine for getting them reviewed but isn't a path to upstream. Yep, they have already been sent to Jeff/netdev earlier today as well. I'd inadvertently left them off the CC but Andy reminded me already. Thanks, Paul. these should get an Ack by Andy before going in to any tree. Andy has already done that, so I think we should be good to go. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/054572.html Cool. I'm guessing these will go via jeff's tree for 2.6.26? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Remove unused machine call outs
When we moved to arch/powerpc we actively tried to avoid using the
ppc_md.setup_io_mappings(). Currently no board ports use it so lets
remove it to avoid any new boards using it.
Also, remove early_serial_map() since we don't even have a call out for
it in arch/powerpc.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/mm/init_32.c |2 --
include/asm-powerpc/machdep.h |3 ---
2 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 0c66a9f..5316cbc 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -184,8 +184,6 @@ void __init MMU_init(void)
/* Map in I/O resources */
if (ppc_md.progress)
ppc_md.progress("MMU:setio", 0x302);
- if (ppc_md.setup_io_mappings)
- ppc_md.setup_io_mappings();
/* Initialize the context management stuff */
mmu_context_init();
diff --git a/include/asm-powerpc/machdep.h b/include/asm-powerpc/machdep.h
index b95386a..54ed64d 100644
--- a/include/asm-powerpc/machdep.h
+++ b/include/asm-powerpc/machdep.h
@@ -198,9 +198,6 @@ struct machdep_calls {
May be NULL. */
void(*init)(void);
- void(*setup_io_mappings)(void);
-
- void(*early_serial_map)(void);
void(*kgdb_map_scc)(void);
/*
--
1.5.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2.6.26 0/2] Dynamic TBIPA for gianfar
Kumar Gala wrote: On Apr 15, 2008, at 8:57 PM, Paul Gortmaker wrote: On Tue, Apr 15, 2008 at 8:25 PM, Paul Mackerras <[EMAIL PROTECTED]> wrote: Paul Gortmaker writes: This is the resend of the two patches as per Andy's request for v2.6.26 that allow boards with a PHY at the end of the bus to function, by having the TBIPA set dynamically. The 1st patch factors out some of the PHY probe code so it can be recycled by the TBIPA probe, and the second patch implements the dynamic probe itself. I notice that these two patches only touch drivers/net and include/linux. If you want these to go upstream into Linus' tree, you will need to send them to Jeff Garzik and the netdev list. Posting them to the linuxppc-dev list is fine for getting them reviewed but isn't a path to upstream. Yep, they have already been sent to Jeff/netdev earlier today as well. I'd inadvertently left them off the CC but Andy reminded me already. Thanks, Paul. these should get an Ack by Andy before going in to any tree. Andy has already done that, so I think we should be good to go. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/054572.html Paul. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: 4xx build failure
> Grr. Yes, that's probably the right solution for now. I had forgotten > about Axon. > > Sorry for the trouble. I'll revert those commits locally and repush. MMIO is not only Axon.. .some Xilinx stuff too. We should have a proper implementation of the dcri stuff for MMIO. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull 'for-2.6.26' branch of 4xx tree
On Wed, 2008-04-16 at 07:31 -0500, Josh Boyer wrote:
> On Wed, 16 Apr 2008 07:27:58 -0500
> Josh Boyer <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 15 Apr 2008 10:27:04 -0500
> > Josh Boyer <[EMAIL PROTECTED]> wrote:
> >
> > > Valentine Barshak (2):
> > > [POWERPC] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround
> > > [POWERPC] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround
> >
> > These two commits have been dropped from the branch. They cause the
> > allyesconfig build for powerpc to fail because CONFIG_PPC_DCR_MMIO
> > doesn't understand the dcri_clrset macro.
>
> Crap. Looks like you already pulled the tree. We need to either
> revert those two commits, or essentially define dcri_clrset to a do {}
> while(0) in include/asm-powerpc/dcr-mmio.h so things build.
Why ? It should do the right thing, not nop ...
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: More patches pushed to powerpc.git master and powerpc-next branches
On Wed, 2008-04-16 at 22:45 +1000, Stephen Rothwell wrote: > On Wed, 16 Apr 2008 22:32:46 +1000 Paul Mackerras <[EMAIL PROTECTED]> wrote: > > > > [POWERPC] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround > > [POWERPC] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround > > So close :-) The workaround for those is actually subtely different :-0 Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: More patches pushed to powerpc.git master and powerpc-next branches
On Wed, 16 Apr 2008 22:32:46 +1000 Paul Mackerras <[EMAIL PROTECTED]> wrote: > > [POWERPC] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround > [POWERPC] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround So close :-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp0muxtxp7gm.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: More patches pushed to powerpc.git master and powerpc-next branches
I wrote: > The following commits are now in the master and powerpc-next branches > in the powerpc.git tree. This includes commits pulled from Josh > Boyer's and Olof Johansson's trees. Because of a problem caused by a couple of commits in Josh Boyer's tree, I have forced the master and powerpc-next branches back to where they were until an hour or so ago. Hopefully no-one has done a pull in that time; if anyone has then they will need to do a git pull -f when I eventually push the commits out (since they will have different IDs). Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull 'for-2.6.26' branch of 4xx tree
On Wed, 16 Apr 2008 07:27:58 -0500
Josh Boyer <[EMAIL PROTECTED]> wrote:
> On Tue, 15 Apr 2008 10:27:04 -0500
> Josh Boyer <[EMAIL PROTECTED]> wrote:
>
> > Valentine Barshak (2):
> > [POWERPC] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround
> > [POWERPC] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround
>
> These two commits have been dropped from the branch. They cause the
> allyesconfig build for powerpc to fail because CONFIG_PPC_DCR_MMIO
> doesn't understand the dcri_clrset macro.
Crap. Looks like you already pulled the tree. We need to either
revert those two commits, or essentially define dcri_clrset to a do {}
while(0) in include/asm-powerpc/dcr-mmio.h so things build.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
More patches pushed to powerpc.git master and powerpc-next branches
The following commits are now in the master and powerpc-next branches in the powerpc.git tree. This includes commits pulled from Josh Boyer's and Olof Johansson's trees. Paul. Adrian Bunk (1): [POWERPC] Add MODULE_LICENSE to powerpc/sysdev/rtc_cmos_setup.c Anton Vorontsov (2): [POWERPC] OF helpers for the GPIO API [POWERPC] Implement support for the GPIO LIB API Benjamin Herrenschmidt (3): [POWERPC] Initialize paca->current earlier [POWERPC] Fixup softirq preempt count [POWERPC] properly declare onstack completion in iseries veth David Woodhouse (1): [POWERPC] Efika: Really, don't pretend to be CHRP Ishizaki Kou (2): [POWERPC] celleb: Coding style cleanup [POWERPC] hvcbeat: Fix buffer manipulation Jerone Young (1): [POWERPC] 4xx: Add idle wait support for 44x platforms Jochen Friedrich (1): [POWERPC] i2c: OF helpers for the i2c API Josh Boyer (2): [POWERPC] 4xx: Reorganize 4xx defconfigs [POWERPC] 4xx: Add ppc40x_defconfig Kumar Gala (12): [POWERPC] Remove Kconfig option BOOT_LOAD [POWERPC] Provide access to arch/powerpc include path on ppc64 [POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr [POWERPC] Introduce lowmem_end_addr to distinguish from total_lowmem [POWERPC] 85xx: Cleanup TLB initialization [POWERPC] Use lowmem_end_addr to limit lmb allocations on ppc32 [POWERPC] Rename __initial_memory_limit to __initial_memory_limit_addr [POWERPC] Clean up some linker and symbol usage [POWERPC] Move phys_addr_t definition into asm/types.h [POWERPC] Update linker script to properly set physical addresses [POWERPC] bootwrapper: Use physical address in PHDR for uImage [POWERPC] Cleanup pgtable-ppc32.h Manish Ahuja (1): [POWERPC] pseries/phyp dump: Reserve a variable amount of space at boot Nate Case (1): pasemi_mac: Netpoll support Olof Johansson (2): pasemi_mac: Jumbo frame bugfixes [POWERPC] pasemi: Minor iommu cleanup Valentine Barshak (3): [POWERPC] kexec: MPIC ack interrupts at mpic_teardown_this_cpu() [POWERPC] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround [POWERPC] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull 'for-2.6.26' branch of 4xx tree
On Tue, 15 Apr 2008 10:27:04 -0500 Josh Boyer <[EMAIL PROTECTED]> wrote: > Valentine Barshak (2): > [POWERPC] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround > [POWERPC] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround These two commits have been dropped from the branch. They cause the allyesconfig build for powerpc to fail because CONFIG_PPC_DCR_MMIO doesn't understand the dcri_clrset macro. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: 4xx build failure
On Wed, 16 Apr 2008 19:42:27 +1000
Stephen Rothwell <[EMAIL PROTECTED]> wrote:
> Hi Josh,
>
> Today's linux-next build (powerpc allyesconfig) failed like this:
>
> drivers/net/ibm_newemac/core.c: In function ‘emac_rx_clk_tx’:
> drivers/net/ibm_newemac/core.c:146: error: implicit declaration of function
> ‘dcri_clrset’
> drivers/net/ibm_newemac/core.c:146: error: ‘SDR0’ undeclared (first use in
> this function)
> drivers/net/ibm_newemac/core.c:146: error: (Each undeclared identifier is
> reported only once
> drivers/net/ibm_newemac/core.c:146: error: for each function it appears in.)
> drivers/net/ibm_newemac/core.c: In function ‘emac_rx_clk_default’:
> drivers/net/ibm_newemac/core.c:152: error: ‘SDR0’ undeclared (first use in
> this function)
> drivers/net/ibm_newemac/core.c: In function ‘emac_init_phy’:
> drivers/net/ibm_newemac/core.c:2361: error: ‘SDR0’ undeclared (first use in
> this function)
>
> I have reverted commit 863a1175e22cb108f596a5aa55b1e535a77e7cce
> ("[POWERPC] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround")
> and commit 4b2d72f5035764cd2e89f5a13ab35c11a27c557b ("[POWERPC]
> ibm_newemac: PowerPC 440GX EMAC PHY clock workaround").
Grr. Yes, that's probably the right solution for now. I had forgotten
about Axon.
Sorry for the trouble. I'll revert those commits locally and repush.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Phy read timeout in ibm_new_emac driver
> My Micrel/Kendin KSZ8721BT on my ppc405EP board needs one us longer to > finish. I was able to reproduce this all the time. So I wonder if the > timeout of 100us is defined by the MII standard, or by the author of > the driver? > If it's a standard I've still a bad feeling if we just correct the > timeout to 100us, maybe 110 should be fine. If it's not defined by the > standard, I would add 50% to the timeout. It won't slow down other > phys, but a scan on the phy bus might get slowed down. > Same applies for __emac_mdio_write. > > Oh and we could save a us by putting the udelay(1) after the if section ;-) Increasing the timeout is fine. In fact, EMAC specifically can sleep in it's MDIO access routines (it already takes mutexes) so maybe a good option here is to use longer sleeping delays and less iterations. Somebody knows off hand what the standard says the timeout should be ? I can check that tomorrow, I don't have it at hand right now and it's getting late but feel free to beat me to it :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
USB @ MPC8343
Dear List,
on my MPC8343 based board there is a "USB3300" ULPI-PHY connected to the
processor.
It's an OTG capable PHY but host mode should be enough right now.
Since USB is not used inside bootloader it's not configured at all...
As far as I can see the setup should be done inside the kernel completely.
My dts looks like this :
[EMAIL PROTECTED] {
device_type = "usb";
compatible = "fsl-usb2-dr";
reg = <0x23000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
interrupt-parent = <&ipic>;
interrupts = <38 0x8>;
dr_mode = "host";
phy_type = "ulpi";
port1;
};
Since the MPC8343 has only one USB port I assume it is "port1" since the
port1-pins are coming out of the package :-)
DR registers are located @ 0x23000
Kernel log :
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 38, io base 0xe0023000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: Freescale On-Chip EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.25-rc8-01233-g6249f9d-dirty ehci_hcd
usb usb1: SerialNumber: fsl-ehci.0
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
usbcore: registered new interface driver cdc_acm
drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for
USB modems and ISDN adapters
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver libusual
Clocks and communication are looking fine (from an electrical point of
view) and bus power is applied.
But : no device (mouse, memory stick, ...) gets recognized.
No interrupts either.
An hints ?
regards,
Andre Schwarz
Matrix Vision
MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht:
Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: State of the MPC5200 PSC AC97 driver
On Tuesday 15 April 2008 10:03, Juergen Beisert wrote:
> Currently it fails to play anything with an external Wolfson WM9712
> connected to it. It seems the current AC97 reset sequence switches the
> WM9712 into testmode due to SDATA_OUT and Sync are not held low while the
> reset is active. Any idea to solve this? Switching both signals to GPIO and
> force them to low level while reset is active? How to cover PSC1 and PSC2
> with different GPIOs for this case?
Cannot reproduce the reset issue now, but in my case the bestcomm was
programmed to service the wrong PSC unit. That was the reason I never heard
any sound.
Can us give the oftree a better differentiation to program the bestcomm in a
correct manner?
Subject: [EMAIL PROTECTED]@/@[EMAIL PROTECTED] mpc52xx: Change the AC97 driver
to be more generic
From: Juergen Beisert <[EMAIL PROTECTED]>
The current AC97 driver for the mpc52xx CPU is fixed to work on PSC2. This
patch tries to make it more generic, as it detects the PSC unit for AC97 usage
to forward this information into the Bestcomm-API.
Signed-off-by: Juergen Beisert <[EMAIL PROTECTED]>
---
sound/ppc/mpc52xx_ac97.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
Index: sound/ppc/mpc52xx_ac97.c
===
--- sound/ppc/mpc52xx_ac97.c.orig
+++ sound/ppc/mpc52xx_ac97.c
@@ -651,6 +651,7 @@ mpc52xx_ac97_probe(struct of_device *op,
struct mpc52xx_ac97_priv *priv;
struct snd_card *card;
struct resource res;
+ int tx_initiator;
int rv;
dev_dbg(&op->dev, "probing MPC52xx PSC AC97 driver\n");
@@ -699,10 +700,27 @@ mpc52xx_ac97_probe(struct of_device *op,
/* Setup Bestcomm tasks */
spin_lock_init(&priv->dma_lock);
+ /*
+* PSC1 or PSC2 can be configured for AC97 usage. Select the right
+* channel, to let the BCOMM unit does its job correctly.
+*/
+ switch (priv->mem_start & 0x) {
+ case 0x2000:/* PSC1 */
+ tx_initiator = 14;
+ break;
+ case 0x2200:/* PSC2 */
+ tx_initiator = 12;
+ break;
+ default:
+ dev_dbg(priv->dev, "Unknown PSC unit for AC97 usage!\n");
+ rv - ENODEV;
+ goto err_irq;
+ }
+
priv->tsk_tx = bcom_gen_bd_tx_init(AC97_TX_NUM_BD,
priv->mem_start + offsetof(struct mpc52xx_psc,
tfdata),
- 12, /* initiator : FIXME */
+ tx_initiator,
2); /* ipr : FIXME */
if (!priv->tsk_tx) {
printk(KERN_ERR DRV_NAME ": bcom_gen_bd_tx_init failed\n");
@@ -759,6 +777,7 @@ err_irqreq:
bcom_gen_bd_tx_release(priv->tsk_tx);
err_bcomm:
mpc52xx_ac97_hwshutdown(priv);
+err_irq:
irq_dispose_mapping(priv->irq);
err_irqmap:
iounmap(priv->psc);
Juergen
--
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Phy read timeout in ibm_new_emac driver
The __emac_mdio_read function of the emac driver (core.c) will retry
100 times and wait 99us (until the last call of emac_phy_done). I
assume this is an off by one error.
/* Wait for read to complete */
n = 100;
while (!emac_phy_done(dev, (r = in_be32(&p->stacr {
udelay(1);
if (!--n) {
DBG2(dev, " -> timeout wait complete\n");
goto bail;
}
}
My Micrel/Kendin KSZ8721BT on my ppc405EP board needs one us longer to
finish. I was able to reproduce this all the time. So I wonder if the
timeout of 100us is defined by the MII standard, or by the author of
the driver?
If it's a standard I've still a bad feeling if we just correct the
timeout to 100us, maybe 110 should be fine. If it's not defined by the
standard, I would add 50% to the timeout. It won't slow down other
phys, but a scan on the phy bus might get slowed down.
Same applies for __emac_mdio_write.
Oh and we could save a us by putting the udelay(1) after the if section ;-)
Regards
Markus
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux-next: 4xx build failure
Hi Josh,
Today's linux-next build (powerpc allyesconfig) failed like this:
drivers/net/ibm_newemac/core.c: In function ‘emac_rx_clk_tx’:
drivers/net/ibm_newemac/core.c:146: error: implicit declaration of function
‘dcri_clrset’
drivers/net/ibm_newemac/core.c:146: error: ‘SDR0’ undeclared (first use in this
function)
drivers/net/ibm_newemac/core.c:146: error: (Each undeclared identifier is
reported only once
drivers/net/ibm_newemac/core.c:146: error: for each function it appears in.)
drivers/net/ibm_newemac/core.c: In function ‘emac_rx_clk_default’:
drivers/net/ibm_newemac/core.c:152: error: ‘SDR0’ undeclared (first use in this
function)
drivers/net/ibm_newemac/core.c: In function ‘emac_init_phy’:
drivers/net/ibm_newemac/core.c:2361: error: ‘SDR0’ undeclared (first use in
this function)
I have reverted commit 863a1175e22cb108f596a5aa55b1e535a77e7cce
("[POWERPC] ibm_newemac: PowerPC 440EP/440GR EMAC PHY clock workaround")
and commit 4b2d72f5035764cd2e89f5a13ab35c11a27c557b ("[POWERPC]
ibm_newemac: PowerPC 440GX EMAC PHY clock workaround").
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpMRHlZHtUze.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Modem control lines support for the cpm_uart driver
This patch replaces the get_mctrl/set_mctrl stubs with modem control line
read/write access through the GPIO lib.
Available modem control lines are described in the device tree using GPIO
bindings.
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 10 ++
drivers/serial/cpm_uart/cpm_uart.h | 10 ++
drivers/serial/cpm_uart/cpm_uart_core.c | 40 --
3 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 1e5572a..012f231 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1976,6 +1976,14 @@ platforms are moved over to use the
flattened-device-tree model.
- fsl,cpm2-scc-uart
- fsl,qe-uart
+ Modem control lines connected to GPIO controllers are listed in the
+ gpios property as described in section VIII.1 in the following order:
+
+ CTS, RTS, DCD, DSR, DTR, and RI.
+
+ The gpios property is optional and can be left out when control lines are
+ not used.
+
Example:
[EMAIL PROTECTED] {
@@ -1987,6 +1995,8 @@ platforms are moved over to use the flattened-device-tree
model.
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <0080>;
+ gpios = <&gpio_c 15 0
+&gpio_d 29 0>;
};
iii) Network
diff --git a/drivers/serial/cpm_uart/cpm_uart.h
b/drivers/serial/cpm_uart/cpm_uart.h
index 0cc39f8..d0c55e2 100644
--- a/drivers/serial/cpm_uart/cpm_uart.h
+++ b/drivers/serial/cpm_uart/cpm_uart.h
@@ -50,6 +50,15 @@
#define SCC_WAIT_CLOSING 100
+#define GPIO_CTS 0
+#define GPIO_RTS 1
+#define GPIO_DCD 2
+#define GPIO_DSR 3
+#define GPIO_DTR 4
+#define GPIO_RI5
+
+#define NUM_GPIOS (GPIO_RI+1)
+
struct uart_cpm_port {
struct uart_portport;
u16 rx_nrfifos;
@@ -82,6 +91,7 @@ struct uart_cpm_port {
int wait_closing;
/* value to combine with opcode to form cpm command */
u32 command;
+ int gpios[NUM_GPIOS];
};
#ifndef CONFIG_PPC_CPM_NEW_BINDING
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index 7a704ff..0f08071 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -42,6 +42,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -152,13 +154,41 @@ static unsigned int cpm_uart_tx_empty(struct uart_port
*port)
static void cpm_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
{
- /* Whee. Do nothing. */
+ struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
+
+ if (pinfo->gpios[GPIO_RTS] >= 0)
+ gpio_set_value(pinfo->gpios[GPIO_RTS], !(mctrl & TIOCM_RTS));
+
+ if (pinfo->gpios[GPIO_DTR] >= 0)
+ gpio_set_value(pinfo->gpios[GPIO_DTR], !(mctrl & TIOCM_DTR));
}
static unsigned int cpm_uart_get_mctrl(struct uart_port *port)
{
- /* Whee. Do nothing. */
- return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
+ struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
+ unsigned int mctrl = TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
+
+ if (pinfo->gpios[GPIO_CTS] >= 0) {
+ if (gpio_get_value(pinfo->gpios[GPIO_CTS]))
+ mctrl &= ~TIOCM_CTS;
+ }
+
+ if (pinfo->gpios[GPIO_DSR] >= 0) {
+ if (gpio_get_value(pinfo->gpios[GPIO_DSR]))
+ mctrl &= ~TIOCM_DSR;
+ }
+
+ if (pinfo->gpios[GPIO_DCD] >= 0) {
+ if (gpio_get_value(pinfo->gpios[GPIO_DCD]))
+ mctrl &= ~TIOCM_CAR;
+ }
+
+ if (pinfo->gpios[GPIO_RI] >= 0) {
+ if (!gpio_get_value(pinfo->gpios[GPIO_RI]))
+ mctrl |= TIOCM_RNG;
+ }
+
+ return mctrl;
}
/*
@@ -959,6 +989,7 @@ static int cpm_uart_init_port(struct device_node *np,
void __iomem *mem, *pram;
int len;
int ret;
+ int i;
data = of_get_property(np, "fsl,cpm-brg", &len);
if (!data || len != 4) {
@@ -1017,6 +1048,9 @@ static int cpm_uart_init_port(struct device_node *np,
goto out_pram;
}
+ for (i = 0; i < NUM_GPIOS; i++)
+ pinfo->gpios[i] = of_get_gpio(np, i);
+
return cpm_uart_request_port(&pinfo->port);
out_pram:
--
1.5.0
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/11] cell: generalize io-workarounds code
On Fri, 2008-03-14 at 21:20 +0900, Ishizaki Kou wrote:
> This patch splits cell io-workaround code into spider-pci dependent
> code and a generic part, and also adds interfaces to the generic
> io-workaround mechanism.
>
> Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
> ---
>
> Please test on CellBlade because I don't have any access to CellBlade.
Unfortunately, that crashes on spider based cell blade, see below:
> +
> + /* setup dummy read */
> + /*
> + * On CellBlade, we can't know that which XDR memory is used by
> + * kmalloc() to allocate dummy_page_va.
> + * In order to imporve the performance, the XDR which is used to
> + * allocate dummy_page_va is the nearest the spider-pci.
> + * We have to select the CBE which is the nearest the spider-pci
> + * to allocate memory from the best XDR, but I don't know that
> + * how to do.
> + *
> + * Celleb does not have this problem, because it has only one XDR.
> + */
> + dummy_page_va = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + if (!dummy_page_va) {
> + pr_err("SPIDERPCI-IOWA:Alloc dummy_page_va failed.\n");
> + return -1;
> + }
> +
> + dummy_page_da = dma_map_single(phb->parent, dummy_page_va,
> +PAGE_SIZE, DMA_FROM_DEVICE);
> + if (dma_mapping_error(dummy_page_da)) {
> + pr_err("SPIDER-IOWA:Map dummy page filed.\n");
> + kfree(dummy_page_va);
> + return -1;
> + }
The above dma_map_single() will crash on QS20 because there is no
phb->parent on these. The QS20 uses the "old style" PCI probing
mechanism where PCI busses are setup off the root node at setup_arch
time and have no struct device attached, which means yo ucan't call
dma_map_single on them unfortunately.
Now I wonder...
> +int __init spiderpci_iowa_init(struct iowa_bus *bus, void *data)
> +{
> + void __iomem *regs = NULL;
> + struct spiderpci_iowa_private *priv;
> + struct device_node *np = bus->phb->dn;
> + struct resource r;
> + unsigned long offset = (unsigned long)data;
> +
> + pr_debug("SPIDERPCI-IOWA:Bus initialize for spider(%s)\n",
> + np->full_name);
> +
.../...
Is the above spiderpci_iowa_init() function ever used on Celleb ? It
looks to me like Celleb relies on the new of_platform stuff to create
the PCI host bridges off OF devices, after boot, in which case that
would work for you. That would mean that the above function is really
only useful for busses created in setup_arch() which is really only the
QS20 cell blade, right ?
In that case, I think that function should be moved to the cell blade
setup.c file instead of here. Now, regarding the above problem, I'm not
sure what is the best fix at this stage. We can't create sane struct
device objects at setup_arch() time.
We could create a hand-made platform or of_platform device from the
above function for every bridge that doesn't have one and hook up it's
DMA ops... I suppose that would fix it.
I've started hacking something but didn't yet get it working, I'll
continue tomorrow unless you come up with some other solution.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
