Re: [RFC Patch 2/6] Introduce PPC64 specific Hardware Breakpointinterfaces
On Mon, May 18, 2009 at 12:30:41PM -0400, Alan Stern wrote:
On Mon, 18 May 2009, K.Prasad wrote:
+int __kprobes hw_breakpoint_handler(struct die_args *args)
+{
+ int rc = NOTIFY_STOP;
+ struct hw_breakpoint *bp;
+ struct pt_regs *regs = args-regs;
+ unsigned long dar;
+ int cpu, stepped, is_kernel;
+
+ /* Disable breakpoints during exception handling */
+ set_dabr(0);
+
+ dar = regs-dar (~HW_BREAKPOINT_ALIGN);
+ is_kernel = (dar = TASK_SIZE) ? 1 : 0;
is_kernel_addr() ?
Ok.
Shouldn't this test hbp_kernel_pos instead?
Testing hbp_kernel_pos should be sufficient for PPC64 with just one
breakpoint register. However the above code is more extensible to other
PowerPC implementations which have more than one breakpoint register.
Then maybe you don't want to test this at all. Just compare the dar
value with each of the breakpoint addresses. That's more like what the
x86 code does.
Alan Stern
Comparing the DAR register value with each breakpoint address is
required to determine if the exception is the cause of a breakpoint hit
and I've added the code to hw_breakpoint_handler(). With this check in
place, I find that using hbp_kernel_pos to determine kernel/user space
origin is much easier (as you suggested) and the code is modified
accordingly.
Please find the changes in the new patchset being sent.
Thanks,
K.Prasad
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC Patch 0/6] PPC64: Hardware Breakpoint interfaces - ver III
Hi All, Please find a new patchset that includes suggestions from the community and a few issues discovered during code inspection and testing. The changes are as documented below. Kindly let me know your comments on the same, in the absence of which I intend to submit the patchset for upstream inclusion in the subsequent iteration. Changelog - ver III -- (Ver I: http://ozlabs.org/pipermail/linuxppc-dev/2009-May/071942.html) (Ver II: http://ozlabs.org/pipermail/linuxppc-dev/2009-May/072106.html) 19th May 2009 -- - Patches are based on commit 08f16e060bf54bdc34f800ed8b5362cdeda75d8b of -tip tree. - The declarations in arch/powerpc/include/asm/hw_breakpoint.h are done only if CONFIG_PPC64 is defined. This eliminates the need to conditionally include this header file. - load_debug_registers() is done in start_secondary() i.e. during CPU initialisation. - arch_check_va_ routines in hw_breakpoint.c are now replaced with a much simpler is_kernel_addr() check in arch_validate_hwbkpt_settings() - Return code of hw_breakpoint_handler() when triggered due to Lazy debug register switching is now changed to NOTIFY_STOP. - The ptrace code no longer sets the TIF_DEBUG task flag as it is proposed to be done in register_user_hw_breakpoint() routine. - hw_breakpoint_handler() is now modified to use hbp_kernel_pos value to determine if the trigger was a user/kernel space address. The DAR register value is checked with the address stored in 'struct hw_breakpoint' to avoid handling of exceptions that belong to kprobe/Xmon. Thanks, K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC Patch 1/6] Prepare the PowerPC platform for HW Breakpoint infrastructure
Prepare the PowerPC code for HW Breakpoint infrastructure patches by including
relevant constant definitions and function declarations.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/hw_breakpoint.h | 57 +++
arch/powerpc/include/asm/processor.h |1
arch/powerpc/include/asm/reg.h |3 +
3 files changed, 61 insertions(+)
Index: linux-2.6-tip.hbkpt/arch/powerpc/include/asm/hw_breakpoint.h
===
--- /dev/null
+++ linux-2.6-tip.hbkpt/arch/powerpc/include/asm/hw_breakpoint.h
@@ -0,0 +1,57 @@
+#ifndef_PPC64_HW_BREAKPOINT_H
+#define_PPC64_HW_BREAKPOINT_H
+
+#ifdef __KERNEL__
+#define__ARCH_HW_BREAKPOINT_H
+#ifdef CONFIG_PPC64
+
+struct arch_hw_breakpoint {
+ char*name; /* Contains name of the symbol to set bkpt */
+ unsigned long address;
+ u8 type;
+};
+
+#include linux/kdebug.h
+#include asm/reg.h
+#include asm-generic/hw_breakpoint.h
+
+#define HW_BREAKPOINT_READ DABR_DATA_READ
+#define HW_BREAKPOINT_WRITE DABR_DATA_WRITE
+#define HW_BREAKPOINT_RW (DABR_DATA_READ | DABR_DATA_WRITE)
+
+#define HW_BREAKPOINT_ALIGN 0x7
+#define HW_BREAKPOINT_LEN INSTRUCTION_LEN
+
+extern struct hw_breakpoint *hbp_kernel[HBP_NUM];
+DECLARE_PER_CPU(struct hw_breakpoint*, this_hbp_kernel[HBP_NUM]);
+extern unsigned int hbp_user_refcount[HBP_NUM];
+
+extern void arch_install_thread_hw_breakpoint(struct task_struct *tsk);
+extern void arch_uninstall_thread_hw_breakpoint(void);
+extern int arch_validate_hwbkpt_settings(struct hw_breakpoint *bp,
+ struct task_struct *tsk);
+extern void arch_update_user_hw_breakpoint(int pos, struct task_struct *tsk);
+extern void arch_flush_thread_hw_breakpoint(struct task_struct *tsk);
+extern void arch_update_kernel_hw_breakpoint(void *);
+extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
+unsigned long val, void *data);
+
+extern void flush_thread_hw_breakpoint(struct task_struct *tsk);
+extern int copy_thread_hw_breakpoint(struct task_struct *tsk,
+ struct task_struct *child, unsigned long clone_flags);
+extern void load_debug_registers(void );
+
+static inline void hw_breakpoint_disable(void)
+{
+ set_dabr(0);
+}
+
+#else
+static inline void hw_breakpoint_disable(void)
+{
+ /* Function is defined only on PPC64 for now */
+}
+#endif /* CONFIG_PPC64 */
+#endif /* __KERNEL__ */
+#endif /* _PPC64_HW_BREAKPOINT_H */
+
Index: linux-2.6-tip.hbkpt/arch/powerpc/include/asm/processor.h
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/include/asm/processor.h
+++ linux-2.6-tip.hbkpt/arch/powerpc/include/asm/processor.h
@@ -177,6 +177,7 @@ struct thread_struct {
#ifdef CONFIG_PPC64
unsigned long start_tb; /* Start purr when proc switched in */
unsigned long accum_tb; /* Total accumilated purr for process */
+ struct hw_breakpoint *hbp[HBP_NUM];
#endif
unsigned long dabr; /* Data address breakpoint register */
#ifdef CONFIG_ALTIVEC
Index: linux-2.6-tip.hbkpt/arch/powerpc/include/asm/reg.h
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/include/asm/reg.h
+++ linux-2.6-tip.hbkpt/arch/powerpc/include/asm/reg.h
@@ -26,6 +26,8 @@
#include asm/reg_8xx.h
#endif /* CONFIG_8xx */
+#define INSTRUCTION_LEN4 /* Length of any instruction */
+
#define MSR_SF_LG 63 /* Enable 64 bit mode */
#define MSR_ISF_LG 61 /* Interrupt 64b mode valid on 630 */
#define MSR_HV_LG 60 /* Hypervisor state */
@@ -184,6 +186,7 @@
#define CTRL_TE 0x00c0 /* thread enable */
#define CTRL_RUNLATCH0x1
#define SPRN_DABR 0x3F5 /* Data Address Breakpoint Register */
+#define HBP_NUM 1 /* Number of physical HW breakpoint registers */
#define DABR_TRANSLATION (1UL 2)
#define DABR_DATA_WRITE (1UL 1)
#define DABR_DATA_READ (1UL 0)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces
Introduce PPC64 implementation for the generic hardware breakpoint interfaces
defined in kernel/hw_breakpoint.c. Enable the HAVE_HW_BREAKPOINT flag and the
Makefile.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/Kconfig|1
arch/powerpc/kernel/Makefile|2
arch/powerpc/kernel/hw_breakpoint.c | 281
3 files changed, 283 insertions(+), 1 deletion(-)
Index: linux-2.6-tip.hbkpt/arch/powerpc/Kconfig
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/Kconfig 2009-05-21
11:05:07.0 +0530
+++ linux-2.6-tip.hbkpt/arch/powerpc/Kconfig2009-05-21 11:38:30.0
+0530
@@ -125,6 +125,7 @@
select USE_GENERIC_SMP_HELPERS if SMP
select HAVE_OPROFILE
select HAVE_SYSCALL_WRAPPERS if PPC64
+ select HAVE_HW_BREAKPOINT if PPC64
config EARLY_PRINTK
bool
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/Makefile
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/Makefile 2009-05-21
11:05:07.0 +0530
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/Makefile2009-05-21
11:38:30.0 +0530
@@ -33,7 +33,7 @@
signal_64.o ptrace32.o \
paca.o cpu_setup_ppc970.o \
cpu_setup_pa6t.o \
- firmware.o nvram_64.o
+ firmware.o nvram_64.o hw_breakpoint.o
obj64-$(CONFIG_RELOCATABLE)+= reloc_64.o
obj-$(CONFIG_PPC64)+= vdso64/
obj-$(CONFIG_ALTIVEC) += vecemu.o vector.o
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/hw_breakpoint.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/hw_breakpoint.c 2009-05-21
11:38:58.0 +0530
@@ -0,0 +1,281 @@
+/*
+ * HW_breakpoint: a unified kernel/user-space hardware breakpoint facility,
+ * using the CPU's debug registers.
+ */
+
+/*
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright © 2009 IBM Corporation
+ */
+
+#include linux/notifier.h
+#include linux/kallsyms.h
+#include linux/kprobes.h
+#include linux/percpu.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/sched.h
+#include linux/init.h
+#include linux/smp.h
+
+#include asm/hw_breakpoint.h
+#include asm/processor.h
+#include asm/sstep.h
+
+/* Store the kernel-space breakpoint address value */
+static unsigned long kdabr;
+
+/*
+ * Temporarily stores address for DABR before it is written by the
+ * single-step handler routine
+ */
+static DEFINE_PER_CPU(unsigned long, dabr_data);
+
+void arch_update_kernel_hw_breakpoint(void *unused)
+{
+ struct hw_breakpoint *bp;
+
+ /* Check if there is nothing to update */
+ if (hbp_kernel_pos == HBP_NUM)
+ return;
+
+ per_cpu(this_hbp_kernel[hbp_kernel_pos], get_cpu()) = bp =
+ hbp_kernel[hbp_kernel_pos];
+ if (bp == NULL)
+ kdabr = 0;
+ else
+ kdabr = bp-info.address | bp-info.type | DABR_TRANSLATION;
+ set_dabr(kdabr);
+ put_cpu_no_resched();
+}
+
+/*
+ * Install the thread breakpoints in their debug registers.
+ */
+void arch_install_thread_hw_breakpoint(struct task_struct *tsk)
+{
+ set_dabr(tsk-thread.dabr);
+}
+
+/*
+ * Install the debug register values for just the kernel, no thread.
+ */
+void arch_uninstall_thread_hw_breakpoint()
+{
+ set_dabr(0);
+}
+
+/*
+ * Store a breakpoint's encoded address, length, and type.
+ */
+int arch_store_info(struct hw_breakpoint *bp, struct task_struct *tsk)
+{
+ /*
+* User-space requests will always have the address field populated
+ * Symbol names from user-space are rejected
+ */
+ if (tsk bp-info.name)
+ return -EINVAL;
+ /*
+* User-space requests will always have the address field populated
+* For kernel-addresses, either the address or symbol name can be
+* specified.
+*/
+ if (bp-info.name)
+ bp-info.address =
[RFC Patch 3/6] Modify ptrace code to use Hardware Breakpoint interfaces
Modify the ptrace code to use the hardware breakpoint interfaces for user-space.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/kernel/ptrace.c | 45 +++
1 file changed, 45 insertions(+)
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/ptrace.c
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/ptrace.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/ptrace.c
@@ -37,6 +37,7 @@
#include asm/page.h
#include asm/pgtable.h
#include asm/system.h
+#include asm/hw_breakpoint.h
/*
* does not yet catch signals sent when the child dies.
@@ -735,9 +736,22 @@ void user_disable_single_step(struct tas
clear_tsk_thread_flag(task, TIF_SINGLESTEP);
}
+static void ptrace_triggered(struct hw_breakpoint *bp, struct pt_regs *regs)
+{
+ /*
+* The SIGTRAP signal is generated automatically for us in do_dabr().
+* We don't have to do anything here
+*/
+}
+
int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
unsigned long data)
{
+#ifdef CONFIG_PPC64
+ struct thread_struct *thread = (task-thread);
+ struct hw_breakpoint *bp;
+ int ret;
+#endif
/* For ppc64 we support one DABR and no IABR's at the moment (ppc64).
* For embedded processors we support one DAC and no IAC's at the
* moment.
@@ -767,6 +781,37 @@ int ptrace_set_debugreg(struct task_stru
if (data !(data DABR_TRANSLATION))
return -EIO;
+#ifdef CONFIG_PPC64
+ bp = thread-hbp[0];
+ if ((data ~HW_BREAKPOINT_ALIGN) == 0) {
+ if (bp) {
+ unregister_user_hw_breakpoint(task, bp);
+ kfree(bp);
+ thread-hbp[0] = NULL;
+ }
+ return 0;
+ }
+
+ if (bp) {
+ bp-info.type = data HW_BREAKPOINT_RW;
+ task-thread.dabr = bp-info.address =
+ (data ~HW_BREAKPOINT_ALIGN);
+ return modify_user_hw_breakpoint(task, bp);
+ }
+ bp = kzalloc(sizeof(struct hw_breakpoint), GFP_KERNEL);
+ if (!bp)
+ return -ENOMEM;
+
+ /* Store the type of breakpoint */
+ bp-info.type = data HW_BREAKPOINT_RW;
+ bp-triggered = ptrace_triggered;
+ task-thread.dabr = bp-info.address = (data ~HW_BREAKPOINT_ALIGN);
+
+ ret = register_user_hw_breakpoint(task, bp);
+ if (ret)
+ return ret;
+#endif /* CONFIG_PPC64 */
+
/* Move contents to the DABR register */
task-thread.dabr = data;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC Patch 4/6] Modify process and processor handling code to recognise hardware debug registers
Modify process handling code to recognise hardware debug registers during copy
and flush operations. Introduce a new TIF_DEBUG task flag to indicate a
process's use of debug register. Load the debug register values into a
new CPU during initialisation.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/thread_info.h |2 ++
arch/powerpc/kernel/process.c | 18 ++
arch/powerpc/kernel/smp.c |2 ++
3 files changed, 22 insertions(+)
Index: linux-2.6-tip.hbkpt/arch/powerpc/include/asm/thread_info.h
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/include/asm/thread_info.h
+++ linux-2.6-tip.hbkpt/arch/powerpc/include/asm/thread_info.h
@@ -114,6 +114,7 @@ static inline struct thread_info *curren
#define TIF_FREEZE 14 /* Freezing for suspend */
#define TIF_RUNLATCH 15 /* Is the runlatch enabled? */
#define TIF_ABI_PENDING16 /* 32/64 bit switch needed */
+#define TIF_DEBUG 17 /* uses debug registers */
/* as above, but as bit values */
#define _TIF_SYSCALL_TRACE (1TIF_SYSCALL_TRACE)
@@ -132,6 +133,7 @@ static inline struct thread_info *curren
#define _TIF_FREEZE(1TIF_FREEZE)
#define _TIF_RUNLATCH (1TIF_RUNLATCH)
#define _TIF_ABI_PENDING (1TIF_ABI_PENDING)
+#define _TIF_DEBUG (1TIF_DEBUG)
#define _TIF_SYSCALL_T_OR_A
(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP)
#define _TIF_USER_WORK_MASK(_TIF_SIGPENDING | _TIF_NEED_RESCHED | \
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/process.c
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/process.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/process.c
@@ -50,6 +50,7 @@
#include asm/syscalls.h
#ifdef CONFIG_PPC64
#include asm/firmware.h
+#include asm/hw_breakpoint.h
#endif
#include linux/kprobes.h
#include linux/kdebug.h
@@ -254,8 +255,10 @@ void do_dabr(struct pt_regs *regs, unsig
11, SIGSEGV) == NOTIFY_STOP)
return;
+#ifndef CONFIG_PPC64
if (debugger_dabr_match(regs))
return;
+#endif
/* Clear the DAC and struct entries. One shot trigger */
#if defined(CONFIG_BOOKE)
@@ -372,8 +375,13 @@ struct task_struct *__switch_to(struct t
#endif /* CONFIG_SMP */
+#ifdef CONFIG_PPC64
+ if (unlikely(test_tsk_thread_flag(new, TIF_DEBUG)))
+ arch_install_thread_hw_breakpoint(new);
+#else
if (unlikely(__get_cpu_var(current_dabr) != new-thread.dabr))
set_dabr(new-thread.dabr);
+#endif /* CONFIG_PPC64 */
#if defined(CONFIG_BOOKE)
/* If new thread DAC (HW breakpoint) is the same then leave it */
@@ -550,6 +558,10 @@ void show_regs(struct pt_regs * regs)
void exit_thread(void)
{
discard_lazy_cpu_state();
+#ifdef CONFIG_PPC64
+ if (unlikely(test_tsk_thread_flag(current, TIF_DEBUG)))
+ flush_thread_hw_breakpoint(current);
+#endif /* CONFIG_PPC64 */
}
void flush_thread(void)
@@ -605,6 +617,9 @@ int copy_thread(unsigned long clone_flag
struct pt_regs *childregs, *kregs;
extern void ret_from_fork(void);
unsigned long sp = (unsigned long)task_stack_page(p) + THREAD_SIZE;
+#ifdef CONFIG_PPC64
+ struct task_struct *tsk = current;
+#endif
CHECK_FULL_REGS(regs);
/* Copy registers */
@@ -672,6 +687,9 @@ int copy_thread(unsigned long clone_flag
* function.
*/
kregs-nip = *((unsigned long *)ret_from_fork);
+
+ if (unlikely(test_tsk_thread_flag(tsk, TIF_DEBUG)))
+ copy_thread_hw_breakpoint(tsk, p, clone_flags);
#else
kregs-nip = (unsigned long)ret_from_fork;
#endif
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/smp.c
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/smp.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/smp.c
@@ -48,6 +48,7 @@
#include asm/vdso_datapage.h
#ifdef CONFIG_PPC64
#include asm/paca.h
+#include asm/hw_breakpoint.h
#endif
#ifdef DEBUG
@@ -536,6 +537,7 @@ int __devinit start_secondary(void *unus
local_irq_enable();
+ load_debug_registers();
cpu_idle();
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC Patch 5/6] Modify Data storage exception code to recognise DABR match first
Modify Data storage exception code to first lookout for a DABR match before
recognising a kprobe or xmon exception.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/mm/fault.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
Index: linux-2.6-tip.hbkpt/arch/powerpc/mm/fault.c
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/mm/fault.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/mm/fault.c
@@ -137,6 +137,12 @@ int __kprobes do_page_fault(struct pt_re
error_code = 0x4820;
else
is_write = error_code DSISR_ISSTORE;
+
+ if (error_code DSISR_DABRMATCH) {
+ /* DABR match */
+ do_dabr(regs, address, error_code);
+ return 0;
+ }
#else
is_write = error_code ESR_DST;
#endif /* CONFIG_4xx || CONFIG_BOOKE */
@@ -151,14 +157,6 @@ int __kprobes do_page_fault(struct pt_re
if (!user_mode(regs) (address = TASK_SIZE))
return SIGSEGV;
-#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
- if (error_code DSISR_DABRMATCH) {
- /* DABR match */
- do_dabr(regs, address, error_code);
- return 0;
- }
-#endif /* !(CONFIG_4xx || CONFIG_BOOKE)*/
-
if (in_atomic() || mm == NULL) {
if (!user_mode(regs))
return SIGSEGV;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC Patch 6/6] Adapt kexec and samples code to recognise PPC64 hardware breakpoint usage
Modify kexec code to disable DABR registers before a reboot. Adapt the samples
code to populate PPC64-arch specific fields.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/kernel/machine_kexec_64.c |3 +++
samples/hw_breakpoint/data_breakpoint.c |4
2 files changed, 7 insertions(+)
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/machine_kexec_64.c
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/machine_kexec_64.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/machine_kexec_64.c
@@ -24,6 +24,7 @@
#include asm/sections.h /* _end */
#include asm/prom.h
#include asm/smp.h
+#include asm/hw_breakpoint.h
int default_machine_kexec_prepare(struct kimage *image)
{
@@ -214,6 +215,7 @@ static void kexec_prepare_cpus(void)
put_cpu();
local_irq_disable();
+ hw_breakpoint_disable();
}
#else /* ! SMP */
@@ -233,6 +235,7 @@ static void kexec_prepare_cpus(void)
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(0, 0);
local_irq_disable();
+ hw_breakpoint_disable();
}
#endif /* SMP */
Index: linux-2.6-tip.hbkpt/samples/hw_breakpoint/data_breakpoint.c
===
--- linux-2.6-tip.hbkpt.orig/samples/hw_breakpoint/data_breakpoint.c
+++ linux-2.6-tip.hbkpt/samples/hw_breakpoint/data_breakpoint.c
@@ -54,6 +54,10 @@ static int __init hw_break_module_init(v
sample_hbp.info.type = HW_BREAKPOINT_WRITE;
sample_hbp.info.len = HW_BREAKPOINT_LEN_4;
#endif /* CONFIG_X86 */
+#ifdef CONFIG_PPC64
+ sample_hbp.info.name = ksym_name;
+ sample_hbp.info.type = HW_BREAKPOINT_WRITE;
+#endif /* CONFIG_PPC64 */
sample_hbp.triggered = (void *)sample_hbp_handler;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
next branch update
I updated my next branch with the following patches. If something older than a week old is missing (and not already delegated to a maintainer on patchwork) please let me know. Anton Blanchard (1): powerpc: Improve decrementer accuracy Anton Vorontsov (6): powerpc/85xx: Add PCI IDs for MPC8569 family processors powerpc/85xx: Fix mpc8569emds crypto node to include SNOW unit powerpc/85xx: Fix reg interrupts for mpc8569emds localbus added NAND powerpc/85xx: Add eSDHC support for MPC8569E-MDS boards powerpc/85xx: Enable Serial RapidIO for MPC85xx MDS boards powerpc/85xx: Add STMicro M25P40 serial flash support for MPC8569E-MDS Becky Bruce (3): powerpc/86xx: Add 36-bit device tree for mpc8641hpcn powerpc: make dma_window_* in pci_controller struct avail on 32b powerpc: Use sg-dma_length in sg_dma_len() macro on 32-bit Geert Uytterhoeven (1): powerpc: Keep track of emulated instructions Geoff Levand (1): powerpc/ps3: Use smp_request_message_ipi Haiying Wang (7): powerpc/85xx: clean up for mpc8568_mds name powerpc/qe: update risc allocation for QE net/ucc_geth: update riscTx and riscRx in ucc_geth powerpc/qe: update QE Serial Number net/ucc_geth: Assign six threads to Rx for UEC powerpc/85xx: Add MPC8569MDS board support powerpc/qe: add new qe properties for QE based chips Jan Blunck (1): powerpc/spufs: Remove double check for non-negative dentry Kumar Gala (32): powerpc/fsl: Remove cell-index from PCI nodes powerpc: Refactor board check for PCI quirks on FSL boards with uli1575 powerpc/fsl: use of_iomap() for rstcr mapping powerpc/85xx: Add binding for LAWs and ECM powerpc/85xx: Add new LAW ECM device tree nodes for all 85xx systems powerpc/86xx: Add binding for LAWs and MCM powerpc/86xx: Add new LAW MCM device tree nodes for all 86xx systems powerpc/cpm: Remove some cruft code and defines powerpc/86xx: clean up smp init code powerpc/fsl: Removed reg property from 85xx/86xx soc node fsldma: Fix compile warnings powerpc/85xx: Add MSI nodes for MPC8568/9 MDS systems powerpc/fsl: Support unique MSI addresses per PCIe Root Complex powerpc/8xxx: Update PCI outbound window addresses for 36-bit configs powerpc/fsl_rio: Fix compile warnings powerpc/fsl: Update FSL esdhc binding powerpc/85xx: Add P2020DS board support powerpc/fsl: Setup PCI inbound window based on actual amount of memory powerpc: Fix up elf_read_implies_exec() usage powerpc/pci: Clean up direct access to sysdata by indirect ops powerpc/pci: Clean up direct access to sysdata by FSL platforms powerpc/pci: Clean up direct access to sysdata by 52xx platforms powerpc/pci: Clean up direct access to sysdata by 4xx platforms powerpc/pci: Clean up direct access to sysdata by CHRP platforms powerpc/pci: Clean up direct access to sysdata on tsi108 platforms powerpc/pci: Clean up direct access to sysdata by powermac platforms powerpc/pci: Clean up direct access to sysdata by RTAS powerpc/pci: Clean up direct access to sysdata by celleb platforms powerpc/pci: Move pseries code into pseries platform specific area powerpc/pci: Cleanup some minor cruft powerpc/pci: Remove redundant pcnet32 fixup powerpc/pci: clean up direct access to sysdata by iseries platform Li Yang (2): powerpc/fsl_rio: use LAW address from device tree rapidio: fix section mismatch warnings Michael Ellerman (7): powerpc/oprofile: Remove unused dump_pmcs() in FSL oprofile powerpc/irq: Move #ifdef'ed body of do_IRQ() into a separate function powerpc/irq: Move stack overflow check into a separate function powerpc/irq: Move get_irq() comment into header powerpc/irq: Remove fallback to __do_IRQ() powerpc/powermac: Use generic_handle_irq() in gatwick_action() powerpc/irq: We don't need __do_IRQ() anymore Michael Neuling (2): powerpc: Cleanup macros in ppc-opcode.h powerpc: Move VSX load/stores into ppc-opcode.h Milton Miller (2): powerpc: Enable MMU feature sections for inline asm powerpc: Add 2.06 tlbie mnemonics Robert Jennings (1): powerpc/pseries: CMO unused page hinting Sean MacLennan (1): powerpc: Update Warp to use leds-gpio driver Tony Breeds (1): powerpc/mpic: Cleanup mpic_find() implementation Vinay Sridhar (1): powerpc/xmon: Add dl command to dump contents of __log_buf ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
problem in registering the device while inserting the kernel module
Hi Members of linuxppc,
I'm working on XUPV2P board with Virtex II Pro FPGA device.
I written a kernel module for LED device. I got that module run
successfuly on ML403 board having Virtex 4 FPGA.I have not make any
change in my source code for XUP board, because I don't feel any change is
required.
On XUP board when I run insmod xilinx_led.ko command on my target board, I
got following message.
# insmod xilinx_led.ko
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: d1006190 LR: d1006188 CTR:
REGS: c0705db0 TRAP: 0300 Not tainted (2.6.23xlnx)
MSR: 00029030 EE,ME,IR,DR CR: 2424 XER:
DEAR: 004c, ESR:
TASK = c04c63d0[186] 'insmod' THREAD: c0704000
GPR00: d1006188 c0705e60 c04c63d0 00d0 0001 c0220ae0
GPR08: c006c60c 0001 c04553f0 026f4bac 100b4260 d1003288 d1007668
GPR16: d1003288 d1003238 fff1 fff2 004c d100762c c003e94c
GPR24: d1002e02 0018 d1002000 0019 d100 d1007598 d10077c8
NIP [d1006190] xilinx_ml403_led_setup+0x174/0x1dc [xilinx_led]
LR [d1006188] xilinx_ml403_led_setup+0x16c/0x1dc [xilinx_led]
Call Trace:
[c0705e60] [d1006188] xilinx_ml403_led_setup+0x16c/0x1dc [xilinx_led]
(unreliable)
[c0705e90] [c0040be0] sys_init_module+0x120c/0x12f8
[c0705f40] [c0002c10] ret_from_syscall+0x0/0x3c
Instruction dump:
48000819 3d20d100 39297620 913f003c 93bf0040 3c800fc0 60840001 7fe3fb78
38a1 48000805 813e0014 7c7f1b78 80e9004c 3c60d100 3c80d100 80bc77c8
Note: After above output when I execute lsmod command. I observed that led
device is tainted.
~ # lsmod
Module Size Used by Tainted: G
xilinx_led 6172 1
~ #
What I understood from above message is that there is a problem in registering
the device in function xilinx_ml403_led_setup( ).
Anyone can help me out to solve this problem?
The source code is given below.
Rajendra
---Xilinx_led.c---
#include linux/init.h
#include linux/module.h
#include linux/kernel.h
#include linux/slab.h
#include linux/fs.h
#include linux/errno.h
#include linux/types.h
#include linux/mm.h
#include linux/cdev.h
#include linux/proc_fs.h
#include linux/fcntl.h
#include linux/ioport.h
#include linux/interrupt.h
#include linux/xilinx_devices.h
#include asm/system.h
#include asm/io.h
#include asm/uaccess.h
#include xparameters.h
#include xio.h
#include xgpio.h
#include xgpio_l.h
#include xstatus.h
#include xbasic_types.h
/* LED constant */
#define DRIVER_NAME led
#define DRIVER_DESCRIPTION GPIO based 4 bit led peripheral driver
#define LED_PHY_BASEADDR XPAR_LEDS_4BIT_BASEADDR
#define LED_PHY_HIGHADDR XPAR_LEDS_4BIT_HIGHADDR
#define LED_DEVICE_ID XPAR_LEDS_4BIT_DEVICE_ID
#define LED_MAJOR 252
#define LED_MINOR 1
#define LEDChan 1
XGpio gp_out;
/* Device Structure */
struct led_instance
{
Xuint32 phy_baseaddr;
Xuint32 phy_highaddr;
Xuint32 remap_size;
Xuint32 virtual_baseaddr;
u32 device_id;
struct cdev *cdev;
XGpio gpio;
};
struct led_instance xilinx_ml403_led;
/*Open and Release method */
int led_open(struct inode *inode, struct file *filp)
{
struct led_instance *dev;
dev = container_of(inode - i_cdev, struct led_instance, cdev);
filp - private_data = dev;
return 0;
}
int led_release(struct inode *inode, struct file *filp)
{
return 0;
}
/* Read Method */
ssize_t led_read(struct file *flip, char __user *buf, size_t count, loff_t
*f_pos)
{
size_t retval = 0;
u32 data;
printk(KERN_INFO %s: Entering\n\r, __FUNCTION__);
if(*f_pos = sizeof(data))
{
goto out01;
}
if(*f_pos + count = sizeof(data))
{
count = sizeof(data) - *f_pos;
}
data = XGpio_DiscreteRead(gp_out, LEDChan);
printk(KERN_INFO data = 0x%08X!\n\r, data);
if(copy_to_user(buf, data, count))
{
retval = -EFAULT;
goto out01;
}
*f_pos += count;
retval = count;
out01: return retval;
}
/* Write Method */
ssize_t led_write(struct file *flip, const char __user *buf, size_t count,
loff_t *f_pos)
{
size_t retval = 0;
Xuint32 data;
printk(KERN_INFO %s: Entering\n\r, __FUNCTION__);
if(count sizeof(data))
{
printk(argument to small!\n\r);
retval = -EINVAL;
goto out01;
}
if(*f_pos + count = sizeof(data))
{
count = sizeof(data) - *f_pos;
}
if(copy_from_user(data,buf, count))
{
retval = -EFAULT;
goto out01;
}
XGpio_DiscreteWrite(gp_out,LEDChan,data);
*f_pos += count;
retval = count;
out01: return retval;
}
/* File Operations Structure */
struct file_operations
Re: next branch update
Hi Ben, On Thu, 21 May 2009 17:26:00 +1000 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: I updated my next branch with the following patches. If something older than a week old is missing (and not already delegated to a maintainer on patchwork) please let me know. Not older than a week, but trivial and has nowhere else to go: http://patchwork.ozlabs.org/patch/27437/ -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpq7MOKaZw5p.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
Thursday 14 May 2009 16:00:33 Grant Likely wrote: MPC5121 support was added to drivers/net/fs_enet. MPC52xx uses drivers/net/fec_mpc52xx.c. Do you think that creating one universal driver from these two is now possible? You said that it should be easy, however you also said that cache coherency issues makes this imposible. Not impossible. Hard. I thought a bit more about merging FEC drivers and I see one problem more. Driver fs_enet works with FEC's with own DMA engine and fec_mpc52xx.c uses BestComm. Integration of these two drivers will need a DMA abstraction layer to keep everything clean. Unfortuanetly BestComm driver does not provide any abstraction - it only exports set of functions to deal with specific hardware: FEC and PATA. More #ifdef's will be needed to remove linking with BestComm driver if kernel will be compiled without 52xx support and resulting code will not be much better than existing one. Especially that new DMA abstraction layer probably will be quite complex. -- Best Regards. Piotr Ziecik ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/6] powerpc: add memory map support to Freescale RapidIO block
On Wed, May 13, 2009 at 6:05 AM, Andrew Morton
a...@linux-foundation.org wrote:
On Tue, 12 May 2009 16:36:00 +0800
Li Yang le...@freescale.com wrote:
+ align = (size 0x1000) ? 0x1000 : 1 (__ilog2(size - 1) + 1);
+
+ /* Align the size */
+ if ((lstart + size) (_ALIGN_DOWN(lstart, align) + align)) {
__ilog2() and _ALIGN_DOWN() are powerpc-specific functions. It would
be preferable to use more general helpers if possible. ALIGN() and ilog2()
might suit here.
Will change to use ilog2().
_ALIGN_DOWN() gets a lower aligned address while ALIGN() gets a higher
address. It seems that we don't have a general helper to do the same.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to debug a hung multi-core system....
On May 20, 2009, at 6:17 PM, Morrison, Tom wrote: All, First off, we turned SPE off completely in our build - so we could debug a much deeper problem that seems to be occurring in our application (before we try to find a potential test case for corruption of GPR registers). We have had this problem for 3 weeks, and just recently have come down to a single test case that makes it fail (although extremely complicated test case)... Setup: Master Blade (8548E) with Linux 2.6.23 (and custom BSP) Slave Blade (8572E) with Linux 2.6.23 (and similar custom BSP). The Master Blade works flawlessly (and also works in a slave capacity too flawlessly). The single 'slave' 8572E blades communicates with the 'master' blade over TCP/IP PCI Express (and is running a similar application)... Running Single Core on slave 8572E (nosmp option on command line) the application works in all conditions (from modestly loaded to well oversubscribed/pegged CPU). In Multi-core option, the application also works flawlessly. The problem comes when we oversubscribe our application and push this 'slave' blade to the extreme edge of processing (falling behind in our processing...etc). Eventually, sometime between 5-15 minutes, this board becomes hung (where the console becomes completely unresponsive and you cannot 'ping' the box). I have a JTAG WindRiver ICE and connect to this blade after it is hung, and it appears that both cores are running to some extent: Core 1 seems to be Idle loop - happily doing nothing (and not servicing TCP and/or the console)... Core 0 seems to be 'stuck' at the InstructionStorage Exception. And it seems to be going 'nowhere' fast SRR0 seems to point to this same spot (0xc6C0) SRR1 value is 0x00021200 I am at a loss to see how the kernel (and/or our kernel BSP) cause this exception, and I am even more of a loss on figuring out an application could cause this exception... This is a bit odd as we shouldn't see an ISI from 0xc6C0. Are you able to single step Core0? Can you dump the contents of the TLBs on Core0 Anybody have any ideas - and/or ways to re-configure our setup to obtain more data? Or does this sound familiar to a bug somebody has already found in the kernel? We are even having trouble defining a test program that can cause (on purpose) the 'InstructionStorage' Exception (does anybody have an simple 'c' (or ppc assembly) program that causes this exception (so we can run in user application land and see if the symptoms are similar))? Thank you in advance for any / all help you can provide because I am completely stumped on even how to proceed! Is your application generating a lot of processes or have a lot of concurrent processes on the 8572? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to debug a hung multi-core system....
[Morrison, Tom] BKMtat Entry EPN RPNTID TMASK WIMGE TSIZ U0:3 X0:1 PID TS PROT SHEN UR UW UX SR SW SX TIDZ VAL LT0 C000 00 0FF 04 9 0 0 00PPEEDEEDDV LT1 D000 0100 00 0FF 04 9 0 0 00PPEEDEEDDV LT2 E000 0200 00 0FF 04 9 0 0 00PPEEDEEDDV LT4 F924E000 7C054500 BA 000 0B E 0 3 00PSEEDEEDDV LT6 8000 1F00 F2 0FF 1D 9 B 3 00USDEDEEEDV LT7 6400 1F00 B3 07F 02 8 B 0 01USDEDDEEDV LT8 E5BF1000 995EA900 96 000 0C D 8 0 01USDEEEEDDV LT11 6B00 F570 BC 03F 04 7 D 0 01PSEEEEEEDV LT12 712DB000 F1B59100 2A 000 19 C F 1 01PSEEEEDEDV LT13 F000 7F 0FF 07 B 0 0 01PSDDEEEEDV LT14 A300 FDD0 C5 03F 16 7 E 3 01PSEEEDDEDV LT15 F7F0 B0B8 82 00F 1F 5 F 0 01PPEEDDDDDV Do you know what the Entry field means? Are you guys putting your own mappings into the TLB? LT4..LT15 (with VAL = V) seem very odd to me. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: How to debug a hung multi-core system....
see middle post -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Thursday, May 21, 2009 9:13 AM To: Morrison, Tom Cc: linuxppc-dev@ozlabs.org; Young, Andrew; Brown, Jeff Subject: Re: How to debug a hung multi-core system On May 20, 2009, at 6:17 PM, Morrison, Tom wrote: [Morrison, Tom] snip some verbose explanations Core 1 seems to be Idle loop - happily doing nothing (and not servicing TCP and/or the console)... Core 0 seems to be 'stuck' at the InstructionStorage Exception. And it seems to be going 'nowhere' fast SRR0 seems to point to this same spot (0xc6C0) SRR1 value is 0x00021200 I am at a loss to see how the kernel (and/or our kernel BSP) cause this exception, and I am even more of a loss on figuring out an application could cause this exception... This is a bit odd as we shouldn't see an ISI from 0xc6C0. Are you able to single step Core0? Can you dump the contents of the TLBs on Core0 [Morrison, Tom] [Morrison, Tom] snip some of verbose explanation Yes, very odd... And I am able to get TLB entries from the core that is in Instruction Storage Exception, I made [Morrison, Tom] BKMtat Entry EPN RPNTID TMASK WIMGE TSIZ U0:3 X0:1 PID TS PROT SHEN UR UW UX SR SW SX TIDZ VAL IT0 C000 00 000 0A 0 0 0 0 0UPDDDDDDDI IT1 C000 00 000 0A 0 0 0 0 0UPDDDDDDDI IT2 C000 00 000 0A 0 0 0 0 0UPDDDDDDDI IT3 C000 00 000 0A 0 0 0 0 0UPDDDDDDDI DT0 0011C000 00 000 06 0 0 0 0 0UPDDDDDDDI DT1 D435C000 2000 00 000 1E 0 0 0 0 0UPDDDDDDDI DT2 0011C000 00 000 06 0 0 0 0 0UPDDDDDDDI DT3 D435C000 2000 00 000 1E 0 0 0 0 0UPDDDDDDDI LT0 C000 00 0FF 04 9 0 0 0 0PPEEDEEDDV LT1 D000 0100 00 0FF 04 9 0 0 0 0PPEEDEEDDV LT2 E000 0200 00 0FF 04 9 0 0 0 0PPEEDEEDDV LT3 39A4 027FF700 0D 000 06 E A 3 0 1USDDDEEDDI LT4 F924E000 7C054500 BA 000 0B E 0 3 0 0PSEEDEEDDV LT5 82A9F000 46664C00 FB 000 1A F 4 2 0 0USEEDDEDDI LT6 8000 1F00 F2 0FF 1D 9 B 3 0 0USDEDEEEDV LT7 6400 1F00 B3 07F 02 8 B 0 0 1USDEDDEEDV LT8 E5BF1000 995EA900 96 000 0C D 8 0 0 1USDEEEEDDV LT9 7F3BF000 C6DF7300 DF 000 15 1 2 3 0 1USEDDEEEDI LT10 917C7000 EEA67F00 7F 000 17 C 5 3 0 1PSEEEEEEDI LT11 6B00 F570 BC 03F 04 7 D 0 0 1PSEEEEEEDV LT12 712DB000 F1B59100 2A 000 19 C F 1 0 1PSEEEEDEDV LT13 F000 7F 0FF 07 B 0 0 0 1PSDDEEEEDV LT14 A300 FDD0 C5 03F 16 7 E 3 0 1PSEEEDDEDV LT15 F7F0 B0B8 82 00F 1F 5 F 0 0 1PPEEDDDDDV To answer your 2nd question - we have about 10 processes, and about 60-70 threads total (30+ for the main processing process)... Anybody have any ideas - and/or ways to re-configure our setup to obtain more data? Or does this sound familiar to a bug somebody has already found in the kernel? We are even having trouble defining a test program that can cause (on purpose) the 'InstructionStorage' Exception (does anybody have an simple 'c' (or ppc assembly) program that causes this exception (so we can run in user application land and see if the symptoms are similar))? Thank you
RE: How to debug a hung multi-core system....
What do you mean by 'odd' mappings (the EPN or RPNor ??) Entry EPN RPNTID TMASK WIMGE TSIZ U0:3 X0:1 --- LT8 E5BF1000 995EA900 96 000 0C D 8 0 continued PID TS PROT SHEN UR UW UX SR SW SX TIDZ VAL 01USDEEEEDDV We are using a 36bit address (mainly to remap our I/O and local bus devices to outside the 32bit addressing space)... t -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Thursday, May 21, 2009 10:45 AM To: Morrison, Tom Cc: linuxppc-dev@ozlabs.org; Young, Andrew; Brown, Jeff; Geary Sean- R60898 Subject: Re: How to debug a hung multi-core system [Morrison, Tom] BKMtat Entry EPN RPNTID TMASK WIMGE TSIZ U0:3 X0:1 PID TS PROT SHEN UR UW UX SR SW SX TIDZ VAL LT0 C000 00 0FF 04 9 0 0 00PPEEDEEDDV LT1 D000 0100 00 0FF 04 9 0 0 00PPEEDEEDDV LT2 E000 0200 00 0FF 04 9 0 0 00PPEEDEEDDV LT4 F924E000 7C054500 BA 000 0B E 0 3 00PSEEDEEDDV LT6 8000 1F00 F2 0FF 1D 9 B 3 00USDEDEEEDV LT7 6400 1F00 B3 07F 02 8 B 0 01USDEDDEEDV LT8 E5BF1000 995EA900 96 000 0C D 8 0 01USDEEEEDDV LT11 6B00 F570 BC 03F 04 7 D 0 01PSEEEEEEDV LT12 712DB000 F1B59100 2A 000 19 C F 1 01PSEEEEDEDV LT13 F000 7F 0FF 07 B 0 0 01PSDDEEEEDV LT14 A300 FDD0 C5 03F 16 7 E 3 01PSEEEDDEDV LT15 F7F0 B0B8 82 00F 1F 5 F 0 01PPEEDDDDDV Do you know what the Entry field means? Are you guys putting your own mappings into the TLB? LT4..LT15 (with VAL = V) seem very odd to me. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: How to debug a hung multi-core system....
Just had a little conference with several co-workers...to go over results We think that LT0 (the one that maps the kernel) has been corrupted: Entry EPN RPNTID TMASK WIMGE TSIZ U0:3 X0:1 --- LT0 C000 00 0FF 04 9 0 0 PID TS PROT SHEN UR UW UX SR SW SX TIDZ VAL --- 00PPEEDEEDDV Is absolutely wrong - this is TLB for the kernel - and as you can see ...it does NOT have execution privileges (and in fact the user space HAS executive privileges for this area (complete opposite of what it should be)... This is why it is stuck AT that instruction (can't even single step from that location).. (one of) The first problem(s) is how can/when did this TLB get corrupted! Tom ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
2009/5/21 Piotr Zięcik ko...@semihalf.com: Thursday 14 May 2009 16:00:33 Grant Likely wrote: MPC5121 support was added to drivers/net/fs_enet. MPC52xx uses drivers/net/fec_mpc52xx.c. Do you think that creating one universal driver from these two is now possible? You said that it should be easy, however you also said that cache coherency issues makes this imposible. Not impossible. Hard. I thought a bit more about merging FEC drivers and I see one problem more. Driver fs_enet works with FEC's with own DMA engine and fec_mpc52xx.c uses BestComm. Integration of these two drivers will need a DMA abstraction layer to keep everything clean. Unfortuanetly BestComm driver does not provide any abstraction - it only exports set of functions to deal with specific hardware: FEC and PATA. More #ifdef's will be needed to remove linking with BestComm driver if kernel will be compiled without 52xx support and resulting code will not be much better than existing one. Especially that new DMA abstraction layer probably will be quite complex. If it looks too ugly, then just fork the driver. 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
[PATCH v4 0/3] Add support for ML510 board
Heck, I don't know if this stuff even works, but I've refactored Roderick's patches into something closer to the structure that I'd like to see. There are still a few things that bother me, but I think it is mostly there. It at least boots on an ML507 board. Roderick, can you please take a look? Thanks, 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
[PATCH v4 1/3] powerpc/virtex: Add support for Xilinx PCI host bridge
From: Roderick Colenbrander thunderbir...@gmail.com
This patch adds support for the Xilinx plbv46-pci-1.03.a PCI host
bridge IPcore.
Signed-off-by: Roderick Colenbrander thunderbir...@gmail.com
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/include/asm/xilinx_pci.h | 21 +
arch/powerpc/platforms/40x/virtex.c |2 +
arch/powerpc/platforms/44x/virtex.c |2 +
arch/powerpc/platforms/Kconfig|4 +
arch/powerpc/sysdev/Makefile |1
arch/powerpc/sysdev/xilinx_pci.c | 132 +
6 files changed, 162 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/xilinx_pci.h
create mode 100644 arch/powerpc/sysdev/xilinx_pci.c
diff --git a/arch/powerpc/include/asm/xilinx_pci.h
b/arch/powerpc/include/asm/xilinx_pci.h
new file mode 100644
index 000..7a8275c
--- /dev/null
+++ b/arch/powerpc/include/asm/xilinx_pci.h
@@ -0,0 +1,21 @@
+/*
+ * Xilinx pci external definitions
+ *
+ * Copyright 2009 Roderick Colenbrander
+ * Copyright 2009 Secret Lab Technologies Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#ifndef INCLUDE_XILINX_PCI
+#define INCLUDE_XILINX_PCI
+
+#ifdef CONFIG_XILINX_PCI
+extern void __init xilinx_pci_init(void);
+#else
+static inline void __init xilinx_pci_init(void) { return; }
+#endif
+
+#endif /* INCLUDE_XILINX_PCI */
diff --git a/arch/powerpc/platforms/40x/virtex.c
b/arch/powerpc/platforms/40x/virtex.c
index fc7fb00..d0fc686 100644
--- a/arch/powerpc/platforms/40x/virtex.c
+++ b/arch/powerpc/platforms/40x/virtex.c
@@ -14,6 +14,7 @@
#include asm/prom.h
#include asm/time.h
#include asm/xilinx_intc.h
+#include asm/xilinx_pci.h
#include asm/ppc4xx.h
static struct of_device_id xilinx_of_bus_ids[] __initdata = {
@@ -47,6 +48,7 @@ static int __init virtex_probe(void)
define_machine(virtex) {
.name = Xilinx Virtex,
.probe = virtex_probe,
+ .setup_arch = xilinx_pci_init,
.init_IRQ = xilinx_intc_init_tree,
.get_irq= xilinx_intc_get_irq,
.restart= ppc4xx_reset_system,
diff --git a/arch/powerpc/platforms/44x/virtex.c
b/arch/powerpc/platforms/44x/virtex.c
index 68637fa..cf96cca 100644
--- a/arch/powerpc/platforms/44x/virtex.c
+++ b/arch/powerpc/platforms/44x/virtex.c
@@ -16,6 +16,7 @@
#include asm/prom.h
#include asm/time.h
#include asm/xilinx_intc.h
+#include asm/xilinx_pci.h
#include asm/reg.h
#include asm/ppc4xx.h
#include 44x.h
@@ -53,6 +54,7 @@ static int __init virtex_probe(void)
define_machine(virtex) {
.name = Xilinx Virtex440,
.probe = virtex_probe,
+ .setup_arch = xilinx_pci_init,
.init_IRQ = xilinx_intc_init_tree,
.get_irq= xilinx_intc_get_irq,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index e3e8707..04a8061 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -329,4 +329,8 @@ config MCU_MPC8349EMITX
also register MCU GPIOs with the generic GPIO API, so you'll able
to use MCU pins as GPIOs.
+config XILINX_PCI
+ bool Xilinx PCI host bridge support
+ depends on PCI XILINX_VIRTEX
+
endmenu
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index b33b28a..2d1c87d 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_IPIC)+= ipic.o
obj-$(CONFIG_4xx) += uic.o
obj-$(CONFIG_4xx_SOC) += ppc4xx_soc.o
obj-$(CONFIG_XILINX_VIRTEX)+= xilinx_intc.o
+obj-$(CONFIG_XILINX_PCI) += xilinx_pci.o
obj-$(CONFIG_OF_RTC) += of_rtc.o
ifeq ($(CONFIG_PCI),y)
obj-$(CONFIG_4xx) += ppc4xx_pci.o
diff --git a/arch/powerpc/sysdev/xilinx_pci.c b/arch/powerpc/sysdev/xilinx_pci.c
new file mode 100644
index 000..1453b0e
--- /dev/null
+++ b/arch/powerpc/sysdev/xilinx_pci.c
@@ -0,0 +1,132 @@
+/*
+ * PCI support for Xilinx plbv46_pci soft-core which can be used on
+ * Xilinx Virtex ML410 / ML510 boards.
+ *
+ * Copyright 2009 Roderick Colenbrander
+ * Copyright 2009 Secret Lab Technologies Ltd.
+ *
+ * The pci bridge fixup code was copied from ppc4xx_pci.c and was written
+ * by Benjamin Herrenschmidt.
+ * Copyright 2007 Ben. Herrenschmidt b...@kernel.crashing.org, IBM Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include linux/ioport.h
+#include linux/of.h
+#include linux/pci.h
+#include mm/mmu_decl.h
+#include asm/io.h
+#include
[PATCH v4 2/3] powerpc/virtex: refactor intc driver and add support for i8259 cascading
From: Grant Likely grant.lik...@secretlab.ca
This patch refactors some of the xilinx_intc interrupt controller driver
and adds support for cascading an i8259 off one of the irq lines.
This patch was based on the ML510 support work done by Roderick
Colenbrander.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/sysdev/xilinx_intc.c | 76 -
1 files changed, 58 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/sysdev/xilinx_intc.c
b/arch/powerpc/sysdev/xilinx_intc.c
index c658b41..90b5772 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -25,6 +25,7 @@
#include linux/of.h
#include asm/io.h
#include asm/processor.h
+#include asm/i8259.h
#include asm/irq.h
/*
@@ -191,20 +192,14 @@ struct irq_host * __init
xilinx_intc_init(struct device_node *np)
{
struct irq_host * irq;
- struct resource res;
void * regs;
- int rc;
/* Find and map the intc registers */
- rc = of_address_to_resource(np, 0, res);
- if (rc) {
- printk(KERN_ERR __FILE__ : of_address_to_resource() failed\n);
+ regs = of_iomap(np, 0);
+ if (!regs) {
+ pr_err(xilinx_intc: could not map registers\n);
return NULL;
}
- regs = ioremap(res.start, 32);
-
- printk(KERN_INFO Xilinx intc at 0x%08llx mapped to 0x%p\n,
- (unsigned long long) res.start, regs);
/* Setup interrupt controller */
out_be32(regs + XINTC_IER, 0); /* disable all irqs */
@@ -217,6 +212,7 @@ xilinx_intc_init(struct device_node *np)
if (!irq)
panic(__FILE__ : Cannot allocate IRQ host\n);
irq-host_data = regs;
+
return irq;
}
@@ -227,23 +223,65 @@ int xilinx_intc_get_irq(void)
return irq_linear_revmap(master_irqhost, in_be32(regs + XINTC_IVR));
}
+#if defined(CONFIG_PPC_I8259)
+/*
+ * Support code for cascading to 8259 interrupt controllers
+ */
+static void xilinx_i8259_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned int cascade_irq = i8259_irq();
+ if (cascade_irq)
+ generic_handle_irq(cascade_irq);
+
+ /* Let xilinx_intc end the interrupt */
+ desc-chip-ack(irq);
+ desc-chip-unmask(irq);
+}
+
+static void __init xilinx_i8259_setup_cascade(void)
+{
+ struct device_node *cascade_node;
+ int cascade_irq;
+
+ /* Initialize i8259 controller */
+ cascade_node = of_find_compatible_node(NULL, NULL, chrp,iic);
+ if (!cascade_node)
+ return;
+
+ cascade_irq = irq_of_parse_and_map(cascade_node, 0);
+ if (!cascade_irq) {
+ pr_err(virtex_ml510: Failed to map cascade interrupt\n);
+ goto out;
+ }
+
+ i8259_init(cascade_node, 0);
+ set_irq_chained_handler(cascade_irq, xilinx_i8259_cascade);
+
+ out:
+ of_node_put(cascade_node);
+}
+#else
+static inline void xilinx_i8259_setup_cascade(void) { return; }
+#endif /* defined(CONFIG_PPC_I8259) */
+
+static struct of_device_id xilinx_intc_match[] __initconst = {
+ { .compatible = xlnx,opb-intc-1.00.c, },
+ { .compatible = xlnx,xps-intc-1.00.a, },
+ {}
+};
+
+/*
+ * Initialize master Xilinx interrupt controller
+ */
void __init xilinx_intc_init_tree(void)
{
struct device_node *np;
/* find top level interrupt controller */
- for_each_compatible_node(np, NULL, xlnx,opb-intc-1.00.c) {
+ for_each_matching_node(np, xilinx_intc_match) {
if (!of_get_property(np, interrupts, NULL))
break;
}
- if (!np) {
- for_each_compatible_node(np, NULL, xlnx,xps-intc-1.00.a) {
- if (!of_get_property(np, interrupts, NULL))
- break;
- }
- }
-
- /* xilinx interrupt controller needs to be top level */
BUG_ON(!np);
master_irqhost = xilinx_intc_init(np);
@@ -251,4 +289,6 @@ void __init xilinx_intc_init_tree(void)
irq_set_default_host(master_irqhost);
of_node_put(np);
+
+ xilinx_i8259_setup_cascade();
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4 3/3] powerpc/virtex: Add Xilinx ML510 reference design support
From: Roderick Colenbrander thunderbir...@gmail.com
Signed-off-by: Roderick Colenbrander thunderbir...@gmail.com
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/platforms/44x/Kconfig| 10 +-
arch/powerpc/platforms/44x/Makefile |1 +
arch/powerpc/platforms/44x/virtex_ml510.c | 29 +
arch/powerpc/sysdev/xilinx_intc.c |5 +
4 files changed, 44 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index 0d83a6a..af1c51d 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -156,7 +156,7 @@ config YOSEMITE
#This option enables support for the IBM PPC440GX evaluation board.
config XILINX_VIRTEX440_GENERIC_BOARD
- bool Generic Xilinx Virtex 440 board
+ bool Xilinx Virtex 5 support
depends on 44x
default n
select XILINX_VIRTEX_5_FXT
@@ -171,6 +171,14 @@ config XILINX_VIRTEX440_GENERIC_BOARD
Most Virtex 5 designs should use this unless it needs to do some
special configuration at board probe time.
+config XILINX_ML510
+ bool Xilinx ML510 board support
+ depends on XILINX_VIRTEX440_GENERIC_BOARD
+ select PPC_PCI_CHOICE
+ select XILINX_PCI if PCI
+ select PPC_INDIRECT_PCI if PCI
+ select PPC_I8259 if PCI
+
config PPC44x_SIMPLE
bool Simple PowerPC 44x board support
depends on 44x
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index 01f51da..ee6185a 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
+obj-$(CONFIG_XILINX_ML510) += virtex_ml510.o
diff --git a/arch/powerpc/platforms/44x/virtex_ml510.c
b/arch/powerpc/platforms/44x/virtex_ml510.c
new file mode 100644
index 000..ba4a6e3
--- /dev/null
+++ b/arch/powerpc/platforms/44x/virtex_ml510.c
@@ -0,0 +1,29 @@
+#include asm/i8259.h
+#include linux/pci.h
+#include 44x.h
+
+/**
+ * ml510_ail_quirk
+ */
+static void __devinit ml510_ali_quirk(struct pci_dev *dev)
+{
+ /* Enable the IDE controller */
+ pci_write_config_byte(dev, 0x58, 0x4c);
+ /* Assign irq 14 to the primary ide channel */
+ pci_write_config_byte(dev, 0x44, 0x0d);
+ /* Assign irq 15 to the secondary ide channel */
+ pci_write_config_byte(dev, 0x75, 0x0f);
+ /* Set the ide controller in native mode */
+ pci_write_config_byte(dev, 0x09, 0xff);
+
+ /* INTB = disabled, INTA = disabled */
+ pci_write_config_byte(dev, 0x48, 0x00);
+ /* INTD = disabled, INTC = disabled */
+ pci_write_config_byte(dev, 0x4a, 0x00);
+ /* Audio = INT7, Modem = disabled. */
+ pci_write_config_byte(dev, 0x4b, 0x60);
+ /* USB = INT7 */
+ pci_write_config_byte(dev, 0x74, 0x06);
+}
+DECLARE_PCI_FIXUP_EARLY(0x10b9, 0x1533, ml510_ali_quirk);
+
diff --git a/arch/powerpc/sysdev/xilinx_intc.c
b/arch/powerpc/sysdev/xilinx_intc.c
index 90b5772..3ee1fd3 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -257,6 +257,11 @@ static void __init xilinx_i8259_setup_cascade(void)
i8259_init(cascade_node, 0);
set_irq_chained_handler(cascade_irq, xilinx_i8259_cascade);
+ /* Program irq 7 (usb/audio), 14/15 (ide) to level sensitive */
+ /* This looks like a dirty hack to me --gcl */
+ outb(0xc0, 0x4d0);
+ outb(0xc0, 0x4d1);
+
out:
of_node_put(cascade_node);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v4 3/3] powerpc/virtex: Add Xilinx ML510 reference designsupport
-Original Message-
From: linuxppc-dev-bounces+stephen.neuendorffer=xilinx@ozlabs.org
[mailto:linuxppc-dev-
bounces+stephen.neuendorffer=xilinx@ozlabs.org] On Behalf Of Grant
Likely
Sent: Thursday, May 21, 2009 9:25 AM
To: linuxppc-dev@ozlabs.org; Roderick Colenbrander
Subject: [PATCH v4 3/3] powerpc/virtex: Add Xilinx ML510 reference
designsupport
From: Roderick Colenbrander thunderbir...@gmail.com
Signed-off-by: Roderick Colenbrander thunderbir...@gmail.com
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/platforms/44x/Kconfig| 10 +-
arch/powerpc/platforms/44x/Makefile |1 +
arch/powerpc/platforms/44x/virtex_ml510.c | 29
+
arch/powerpc/sysdev/xilinx_intc.c |5 +
4 files changed, 44 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index 0d83a6a..af1c51d 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -156,7 +156,7 @@ config YOSEMITE
# This option enables support for the IBM PPC440GX evaluation
board.
config XILINX_VIRTEX440_GENERIC_BOARD
- bool Generic Xilinx Virtex 440 board
+ bool Xilinx Virtex 5 support
'Virtex 5' is a little ambiguous.. I'd suggest keeping the old wording,
or saying 'Virtex 5 FXT support'. Even then it's somewhat ambiguous,
since you could conceivably run linux on microblaze on V5FXT and use the
powerpc for something else..
depends on 44x
default n
select XILINX_VIRTEX_5_FXT
@@ -171,6 +171,14 @@ config XILINX_VIRTEX440_GENERIC_BOARD
Most Virtex 5 designs should use this unless it needs to do
some
special configuration at board probe time.
+config XILINX_ML510
+ bool Xilinx ML510 board support
+ depends on XILINX_VIRTEX440_GENERIC_BOARD
+ select PPC_PCI_CHOICE
+ select XILINX_PCI if PCI
+ select PPC_INDIRECT_PCI if PCI
+ select PPC_I8259 if PCI
+
config PPC44x_SIMPLE
bool Simple PowerPC 44x board support
depends on 44x
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index 01f51da..ee6185a 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
+obj-$(CONFIG_XILINX_ML510) += virtex_ml510.o
diff --git a/arch/powerpc/platforms/44x/virtex_ml510.c
b/arch/powerpc/platforms/44x/virtex_ml510.c
new file mode 100644
index 000..ba4a6e3
--- /dev/null
+++ b/arch/powerpc/platforms/44x/virtex_ml510.c
@@ -0,0 +1,29 @@
+#include asm/i8259.h
+#include linux/pci.h
+#include 44x.h
+
+/**
+ * ml510_ail_quirk
Tpyo, but is the comment even necessary if it doesn't say anything
useful?
+ */
+static void __devinit ml510_ali_quirk(struct pci_dev *dev)
+{
+ /* Enable the IDE controller */
+ pci_write_config_byte(dev, 0x58, 0x4c);
+ /* Assign irq 14 to the primary ide channel */
+ pci_write_config_byte(dev, 0x44, 0x0d);
+ /* Assign irq 15 to the secondary ide channel */
+ pci_write_config_byte(dev, 0x75, 0x0f);
+ /* Set the ide controller in native mode */
+ pci_write_config_byte(dev, 0x09, 0xff);
+
+ /* INTB = disabled, INTA = disabled */
+ pci_write_config_byte(dev, 0x48, 0x00);
+ /* INTD = disabled, INTC = disabled */
+ pci_write_config_byte(dev, 0x4a, 0x00);
+ /* Audio = INT7, Modem = disabled. */
+ pci_write_config_byte(dev, 0x4b, 0x60);
+ /* USB = INT7 */
+ pci_write_config_byte(dev, 0x74, 0x06);
+}
+DECLARE_PCI_FIXUP_EARLY(0x10b9, 0x1533, ml510_ali_quirk);
+
diff --git a/arch/powerpc/sysdev/xilinx_intc.c
b/arch/powerpc/sysdev/xilinx_intc.c
index 90b5772..3ee1fd3 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -257,6 +257,11 @@ static void __init
xilinx_i8259_setup_cascade(void)
i8259_init(cascade_node, 0);
set_irq_chained_handler(cascade_irq, xilinx_i8259_cascade);
+ /* Program irq 7 (usb/audio), 14/15 (ide) to level sensitive */
+ /* This looks like a dirty hack to me --gcl */
+ outb(0xc0, 0x4d0);
+ outb(0xc0, 0x4d1);
+
Yeow... I agree about the dirty hack part... shouldn't this be in the
device tree somewhere, or in the ali driver?
I'm curious if this works on ml410 as well.. (Yes, I know, does this
really matter much? But there are still a bunch of them floating around
in universities.) It may be nice to factor this out so ml410/ppc405 and
microblaze can get it as well.
Steve
out:
of_node_put(cascade_node);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
Becky Bruce wrote:
If we have something like in arch/{x86|ia64|powerpc}/dma-mapping.h:
static inline int is_buffer_dma_capable(struct device *dev,
dma_addr_t addr, size_t size)
then we don't need two checking functions, address_needs_mapping and
range_needs_mapping.
It's never been clear to me *why* we had both in the first place - if
you can explain this, I'd be grateful :)
I was about to ask the same thing. It seems that range_needs_mapping
should be able to do both jobs.
I think range_needs_mapping came from the Xen swiotlb changes, and
address_needs_mapping came from your powerpc changes. Many of the
changes were exact overlaps; I think this was one of the few instances
where there was a difference.
We need a range check in Xen (rather than iterating over individual
pages) because we want to check that the underlying pages are machine
contiguous, but I think that's also sufficient to do whatever checks you
need to do.
The other difference is that is_buffer_dma_capable operates on a
dma_addr_t, which presumes that you can generate a dma address and then
test for its validity. For Xen, it doesn't make much sense to talk
about the dma_addr_t for memory which isn't actually dma-capable; we
need the test to be in terms of phys_addr_t. Given that the two
functions are always called from the same place, that doesn't seem to
pose a problem.
So I think the unified function would be something like:
int range_needs_mapping(struct device *hwdev, phys_addr_t addr,
size_t size);
which would be defined somewhere under asm/*.h. Would that work for
powerpc?
J
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4 3/3] powerpc/virtex: Add Xilinx ML510 reference designsupport
Yeow... I agree about the dirty hack part... shouldn't this be in the device tree somewhere, or in the ali driver? I'm curious if this works on ml410 as well.. (Yes, I know, does this really matter much? But there are still a bunch of them floating around in universities.) It may be nice to factor this out so ml410/ppc405 and microblaze can get it as well. Steve Yes the code can work one the ML410 as well. The thing is that you would need a recent reference design from Xilinx. Before Xilinx used a OPB pci bridge and these days they use a PLB (v46) pci bridge. The old reference designs use the OPB core. I saw someone using a ML410 reference design which used the PBL pci soft-core and the same memory addresses were even used as in the ml510 reference design I'm using. I'm not sure where the guy got the design since the xilinx site only shows old opb_pci stuff. (though the core is nearly the same) Further most devices are also at the same locations on the pci bus. Further the ml410 also offers good old lpt1 and some other things which aren't on the ml510 but yes the pci code and big parts of the dts file I wrote can be reused. Roderick ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/pcm030.dts: add i2c eeprom and delete cruft
On Thu, May 21, 2009 at 11:43 AM, Segher Boessenkool seg...@kernel.crashing.org wrote: However, on the other point, Jon is correct. The first value in the list should be atmel,24c32, not at24,24c32. Yeah. So perhaps atmel,24c32,24c32 ? I'm not terribly happy with that last name, but these devices are _very_ common. I don't think the last name is necessary at all. I'd leave it at atmel,24c32. non-atmel parts can claim compatibility with the atmel version if really necessary. I don't like the 'generic' version either. 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: [PATCH v4 0/3] Add support for ML510 board
On Thu, May 21, 2009 at 6:24 PM, Grant Likely grant.lik...@secretlab.ca wrote: Heck, I don't know if this stuff even works, but I've refactored Roderick's patches into something closer to the structure that I'd like to see. There are still a few things that bother me, but I think it is mostly there. It at least boots on an ML507 board. Roderick, can you please take a look? Thanks, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. From a quick glance it looks good. I will test it on monday. Roderick ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
On May 21, 2009, at 12:43 PM, Jeremy Fitzhardinge wrote:
Becky Bruce wrote:
If we have something like in arch/{x86|ia64|powerpc}/dma-mapping.h:
static inline int is_buffer_dma_capable(struct device *dev,
dma_addr_t addr, size_t size)
then we don't need two checking functions, address_needs_mapping and
range_needs_mapping.
It's never been clear to me *why* we had both in the first place -
if you can explain this, I'd be grateful :)
I was about to ask the same thing. It seems that
range_needs_mapping should be able to do both jobs.
I think range_needs_mapping came from the Xen swiotlb changes, and
address_needs_mapping came from your powerpc changes. Many of the
changes were exact overlaps; I think this was one of the few
instances where there was a difference.
I think address_needs_mapping was already there and I added the
ability for an arch to provide its own version. Ian added
range_needs_mapping in commit b81ea27b2329bf44b. At the time, it
took a virtual address as its argument, so we couldn't use it for
highmem. That's since been changed to phys_addr_t, so I think we
should be able to merge the two.
We need a range check in Xen (rather than iterating over individual
pages) because we want to check that the underlying pages are
machine contiguous, but I think that's also sufficient to do
whatever checks you need to do.
Yes.
The other difference is that is_buffer_dma_capable operates on a
dma_addr_t, which presumes that you can generate a dma address and
then test for its validity. For Xen, it doesn't make much sense to
talk about the dma_addr_t for memory which isn't actually dma-
capable; we need the test to be in terms of phys_addr_t. Given that
the two functions are always called from the same place, that
doesn't seem to pose a problem.
So I think the unified function would be something like:
int range_needs_mapping(struct device *hwdev, phys_addr_t addr,
size_t size);
which would be defined somewhere under asm/*.h. Would that work for
powerpc?
I can work with that, but it's going to be a bit inefficient, as I
actually need the dma_addr_t, not the phys_addr_t, so I'll have to
convert. In every case, this is a conversion I've already done and
that I need in the calling code as well. Can we pass in both the
phys_addr_t and the dma_addr_t? We have both in every case but one,
which is in swiotlb_map_page where we call address_needs_mapping()
without calling range_needs_mapping. It's not actually clear to me
that we need that check, though. Can someone explain what case that
was designed to catch?
Cheers,
Becky
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ipr boot failure caused by MSI (2.6.30-rc1+)
cc'ing linuxppc-dev... -Brian James Bottomley wrote: Kernels after 2.6.30-rc1 stopped booting on my powerstation. The ipr just times out and refuses to probe devices. If I let it drop into the initramfs system, this is what the interrupts shows: (initramfs) cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 16: 20 10 13 11 MPIC Level pata_amd 20: 0 0 0 0 MPIC Level ohci_hcd:usb1, ohci_hcd:usb2 21: 0 0 0 0 MPIC-U3MSI Edge ipr 68: 37 37 48 37 MPIC Edge serial 251: 10 71 69 72 MPIC Edge ipi call function 252: 1555 1779 1372 1155 MPIC Edge ipi reschedule 253: 0 0 0 0 MPIC Edge ipi call function single 254: 0 0 0 0 MPIC Edge ipi debugger BAD:416 So you see the IPR is the only device not receiving them. I can fix the boot hang by reverting commit 5a9ef25b14d39b8413364df12cb8d9bb7a673a32 Author: Wayne Boyer way...@linux.vnet.ibm.com Date: Fri Jan 23 09:17:35 2009 -0800 [SCSI] ipr: add MSI support The system in question is: SYSTEM INFORMATION Processor = PowerPC,970MP @ 2500 MHz I/O Bridge = U4 (4.4) SMP Size = 4 (#0 #1 #2 #3) Boot-Date = 2009-04-21 17:13:36 Memory = 2 GB of RAM @ 666 MHz Board Type = Bimini (7047191/000/1) MFG Date = 1608 Part No. = 10N8748 FRU No.= 10N7182 FRU Serial = YL30W8106038 UUID = Flashside = 1 (temporary) Version= HEAD Build Date = 12-04-2008 16:13 James -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Brian King Linux on Power Virtualization IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Audio and mpc5200 bestcomm tasks
ALSA really wants to dynamically know the address of the current DMA location while transfers are active. This is an important piece of implementing pause/resume. Pause doesn't work too well if there is 2s of music already queued. The work around is to know the sample rate and use the jiffy count to estimate how far into the buffer DMA has progressed. But that's not as accurate as just asking the DMA hardware. I poked around in the SRAM data and couldn't find the address. Is it there or can the Bestcomm tasks be modified to leave it somewhere visible? -- Jon Smirl jonsm...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc:beyond ARRAY_SIZE of args.args
Do not go beyond ARRAY_SIZE of args.args Signed-off-by: Roel Kluin roel.kl...@gmail.com --- I'm quite sure the first is correct, but should maybe `args.nret' and `nargs + args.nret' also be `= ARRAY_SIZE(args.args)'? diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c index 1f8505c..c94ab76 100644 --- a/arch/powerpc/kernel/rtas.c +++ b/arch/powerpc/kernel/rtas.c @@ -779,7 +779,7 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs) return -EFAULT; nargs = args.nargs; - if (nargs ARRAY_SIZE(args.args) + if (nargs = ARRAY_SIZE(args.args) || args.nret ARRAY_SIZE(args.args) || nargs + args.nret ARRAY_SIZE(args.args)) return -EINVAL; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE
Hello list, Commit 33f00dcedb0e22cdb156a23632814fc580fcfcf8 seems to have broken DMA coherent allocations for CONFIG_NOT_COHERENT_CACHE platforms. The problems seem to be that the new __dma_alloc_coherent() and __dma_free_coherent() implementations: - don't respect anymore the passed gfp flags (__dma_alloc_coherent() unconditionally uses GFP_KERNEL within the function irrespective of the caller flags) - can't be used in interrupt context as they use get_vm_area_caller()/vfree() which end up triggering BUG_ON(in_interrupt()) One victim happens to be the USB core subsystem which sometimes frees dma coherent memory in interrupt context for drivers flagged HCD_LOCAL_MEM. This has been experienced while writing a new EHCI driver for the Nintendo Wii platform. usb 1-1: new high speed USB device using ehci-mipc and address 2 [ cut here ] kernel BUG at mm/vmalloc.c:1328! Oops: Exception in kernel mode, sig: 5 [#1] PREEMPT wii Modules linked in: NIP: c008ea20 LR: c0015890 CTR: c00111d4 REGS: d2c65b10 TRAP: 0700 Not tainted (2.6.30-rc2-isobel-wii-00092-gcba94db-dirty) MSR: 00021032 ME,CE,IR,DR CR: 42482028 XER: TASK = d2c600f0[28] 'kmmcd' THREAD: d2c64000 GPR00: 0001 d2c65bc0 d2c600f0 d403 d403 d403 12da1000 0001 GPR08: d2c64000 0020 22482022 94fdfb98 6e1979bc c6bbdbdd GPR16: 0020 00200200 00100100 d4020060 0001 d401c0ec 0001 d401c0ec GPR24: d2d9a6c0 d2f69de0 d2d9a600 d2f69e30 d2f69e2c d2da08e0 NIP [c008ea20] vfree+0xc/0x18 LR [c0015890] __dma_free_coherent+0x14/0x24 Call Trace: [d2c65bc0] [c0017af8] __mipc_recv_req+0x160/0x178 (unreliable) [d2c65bd0] [c00111ec] dma_direct_free_coherent+0x18/0x28 [d2c65be0] [c01cfca4] hcd_free_coherent+0x7c/0x12c [d2c65c10] [c01d00b8] unmap_urb_for_dma+0x150/0x1cc [d2c65c20] [c01d0174] usb_hcd_giveback_urb+0x40/0xe4 [d2c65c30] [c01df474] ehci_urb_done+0xf0/0x114 [d2c65c50] [c01e3870] qh_completions+0x41c/0x4dc [d2c65ca0] [c01e44e0] scan_async+0x9c/0x1a0 [d2c65cc0] [c01e49ec] ehci_work+0x58/0xc4 [d2c65cd0] [c01e5424] ehci_irq+0x22c/0x230 [d2c65d00] [c01cfa88] usb_hcd_irq+0x50/0xa8 [d2c65d20] [c00597d8] handle_IRQ_event+0xdc/0x250 [d2c65d60] [c005ba20] handle_level_irq+0x9c/0x138 [d2c65d80] [c001cbc8] hollywood_pic_irq_cascade+0x7c/0xf8 [d2c65da0] [c00064b4] do_IRQ+0x9c/0xc4 [d2c65dc0] [c0011fb8] ret_from_except+0x0/0x14 Any comments on how to address this issue (other than reverting the above mentioned commit, which fixes it) are welcome. Thanks, Albert ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote: We have both in every case but one, which is in swiotlb_map_page where we call address_needs_mapping() without calling range_needs_mapping. The reason it calls address_needs_mapping without range_needs_mapping is that in the swiotlb_force=1 case it would trigger every time. If address_needs_mapping and range_needs_mapping are merged as proposed and they do not subsume the swiotlb_force check (and I don't think they would) then I think this will work fine. It's not actually clear to me that we need that check, though. Can someone explain what case that was designed to catch? If map_single fails and returns NULL then we try to use io_tlb_overflow_buffer, if that is somehow not DMA-able (for the particular device) then the check will trigger. I would have thought we could arrange that the overflow buffer is always OK and really if map_page is failing we must be close the edge already. Ian. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] KVM: powerpc: beyond ARRAY_SIZE of vcpu-arch.guest_tlb
Do not go beyond ARRAY_SIZE of vcpu-arch.guest_tlb
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index 0fce4fb..c2cfd46 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -125,7 +125,7 @@ static int kvmppc_emul_tlbwe(struct kvm_vcpu *vcpu, u32
inst)
ws = get_ws(inst);
index = vcpu-arch.gpr[ra];
- if (index PPC44x_TLB_SIZE) {
+ if (index = PPC44x_TLB_SIZE) {
printk(%s: index %d\n, __func__, index);
kvmppc_dump_vcpu(vcpu);
return EMULATE_FAIL;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4 3/3] powerpc/virtex: Add Xilinx ML510 reference designsupport
On Thu, May 21, 2009 at 10:50 AM, Stephen Neuendorffer stephen.neuendorf...@xilinx.com wrote: diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig index 0d83a6a..af1c51d 100644 --- a/arch/powerpc/platforms/44x/Kconfig +++ b/arch/powerpc/platforms/44x/Kconfig @@ -156,7 +156,7 @@ config YOSEMITE # This option enables support for the IBM PPC440GX evaluation board. config XILINX_VIRTEX440_GENERIC_BOARD - bool Generic Xilinx Virtex 440 board + bool Xilinx Virtex 5 support 'Virtex 5' is a little ambiguous.. I'd suggest keeping the old wording, or saying 'Virtex 5 FXT support'. Even then it's somewhat ambiguous, since you could conceivably run linux on microblaze on V5FXT and use the powerpc for something else.. Considering that this option only appears when AMCC 44x is selected, I think the ambiguity is minimal. :-) I'll add the FXT though. diff --git a/arch/powerpc/platforms/44x/virtex_ml510.c b/arch/powerpc/platforms/44x/virtex_ml510.c new file mode 100644 index 000..ba4a6e3 --- /dev/null +++ b/arch/powerpc/platforms/44x/virtex_ml510.c @@ -0,0 +1,29 @@ +#include asm/i8259.h +#include linux/pci.h +#include 44x.h + +/** + * ml510_ail_quirk Tpyo, but is the comment even necessary if it doesn't say anything useful? Oops; I started writing a comment and then never completed it. Roderick; care to contribute some lines as to the purpose of this block? diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c index 90b5772..3ee1fd3 100644 --- a/arch/powerpc/sysdev/xilinx_intc.c +++ b/arch/powerpc/sysdev/xilinx_intc.c @@ -257,6 +257,11 @@ static void __init xilinx_i8259_setup_cascade(void) i8259_init(cascade_node, 0); set_irq_chained_handler(cascade_irq, xilinx_i8259_cascade); + /* Program irq 7 (usb/audio), 14/15 (ide) to level sensitive */ + /* This looks like a dirty hack to me --gcl */ + outb(0xc0, 0x4d0); + outb(0xc0, 0x4d1); + Yeow... I agree about the dirty hack part... shouldn't this be in the device tree somewhere, or in the ali driver? Chatting with Roderick on IRC today, it may be that these two lines aren't even necessary. They come from an old guide for porting Linux to the ml410 in the pre-arch/powerpc days. Now that IRQ sense is encoded into the device tree, this probably isn't needed. I'm curious if this works on ml410 as well.. (Yes, I know, does this really matter much? But there are still a bunch of them floating around in universities.) It should do (at least I hope it does). If I get my hands on an ML410, then I'll try it out. It may be nice to factor this out so ml410/ppc405 and microblaze can get it as well. indeed. -- 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: ipr boot failure caused by MSI (2.6.30-rc1+)
On Thu, 2009-05-21 at 13:47 -0500, Brian King wrote: cc'ing linuxppc-dev... -Brian James Bottomley wrote: Kernels after 2.6.30-rc1 stopped booting on my powerstation. The ipr just times out and refuses to probe devices. If I let it drop into the initramfs system, this is what the interrupts shows: (initramfs) cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 16: 20 10 13 11 MPIC Level pata_amd 20: 0 0 0 0 MPIC Level ohci_hcd:usb1, ohci_hcd:usb2 21: 0 0 0 0 MPIC-U3MSI Edge ipr 68: 37 37 48 37 MPIC Edge serial 251: 10 71 69 72 MPIC Edge ipi call function 252: 1555 1779 1372 1155 MPIC Edge ipi reschedule 253: 0 0 0 0 MPIC Edge ipi call function single 254: 0 0 0 0 MPIC Edge ipi debugger BAD:416 So you see the IPR is the only device not receiving them. I can fix the boot hang by reverting commit 5a9ef25b14d39b8413364df12cb8d9bb7a673a32 Author: Wayne Boyer way...@linux.vnet.ibm.com Date: Fri Jan 23 09:17:35 2009 -0800 [SCSI] ipr: add MSI support The system in question is: SYSTEM INFORMATION Processor = PowerPC,970MP @ 2500 MHz I/O Bridge = U4 (4.4) SMP Size = 4 (#0 #1 #2 #3) Boot-Date = 2009-04-21 17:13:36 Memory = 2 GB of RAM @ 666 MHz Board Type = Bimini (7047191/000/1) MFG Date = 1608 Part No. = 10N8748 FRU No.= 10N7182 FRU Serial = YL30W8106038 UUID = Flashside = 1 (temporary) Version= HEAD Build Date = 12-04-2008 16:13 OK, so as an update, I booted to the initrd and inserted the network modules, which are also MSI enabled and this is what I get: (initramfs) cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 16: 14 11 11 18 MPIC Level pata_amd 20: 0 0 0 0 MPIC Level ohci_hcd:usb1, ohci_hcd:usb2 21: 0 0 0 0 MPIC-U3MSI Edge ipr 22: 1 0 1 0 MPIC-U3MSI Edge eth0 23: 0 2 1 0 MPIC-U3MSI Edge eth1 68:193166113177 MPIC Edge serial 251: 16 65 71 70 MPIC Edge ipi call function 252: 1574 1804 1346 1289 MPIC Edge ipi reschedule 253: 0 0 0 0 MPIC Edge ipi call function single 254: 0 0 0 0 MPIC Edge ipi debugger BAD: 1866 So clearly the MSI interrupts to the network cards are working and it looks like just a local problem with the ipr rather than a platform problem with MSI. James ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
Becky Bruce wrote: I can work with that, but it's going to be a bit inefficient, as I actually need the dma_addr_t, not the phys_addr_t, so I'll have to convert. In every case, this is a conversion I've already done and that I need in the calling code as well. Can we pass in both the phys_addr_t and the dma_addr_t? The Xen implementation would needs to do the phys to bus conversion page by page anyway, so it wouldn't help much. But it also wouldn't hurt. How expensive is the phys-to-bus conversion on power? Is it worth making the interface more complex for? Would passing phys+bus mean that we wouldn't also need to pass dev? We have both in every case but one, which is in swiotlb_map_page where we call address_needs_mapping() without calling range_needs_mapping. It's not actually clear to me that we need that check, though. Can someone explain what case that was designed to catch? It called them together a little earlier in the function, and the phys address is still available. I guess the test is checking for a bad implementation of map_single(). I found a single instance of someone reporting the message (in 2.6.11, when swiotlb was ia64-specific: http://lkml.org/lkml/2008/3/3/249). panic() is an odd way to handle an error (even an one which is an implementation bug), but I guess it's better than scribbling on the wrong memory. J ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4 3/3] powerpc/virtex: Add Xilinx ML510 reference designsupport
Hi Stephen,
Grant forgot to attach the dts file (but a next patch will add it).
The dts file contains some lines for the pci bus mapping. The lines
are attached below. For pci support I'm using the reference bsb with
pci 'ML510 BSB1 Pcores Design' for PowerPC at:
http://www.xilinx.com/products/boards/ml510/ml510_10.1_3_1/bsb.htm.
The patch also contains a tutorial on how to add pci yourself.
As I mention in the comment of the plbv46_pci stuff C_IPIFBAR2PCIBAR_0
is not set correctly. Benjamin Herrenschmidt told me that inbound and
outbound pci transactions shouldn't overlap. With the value at ipif
plb 0xa000 maps to 0 on the pci side while the pci soft-core also
thinks that 0 maps to address 0 of the system memory. Setting
C_IPIFBAR2PCIBAR_0 to e.g. 0xa000 like I'm doing maps ipif plb
0xa000 to 0xa000 on the pci side and prevents this confusion.
The same is also wrong in the guides for the ml410.
Could you forward it to the right people so that this can get fixed?
No other changes are needed except for this one.
Roderick
+ plbv46_pci_0: plbv46-...@85e0 {
+ #size-cells = 2;
+ #address-cells = 3;
+ compatible = xlnx,plbv46-pci-1.03.a;
+ device_type = pci;
+ reg = 0x85e0 0x1 ;
+ /* The default ML510 BSB has
C_IPIFBAR2PCIBAR_0 set to 0 which means that a read/write to
+* the memory mapped i/o region (which starts
at 0xa000) for pci bar 0 on the plb side
+* translates to 0.
+* It is important to this value to
0xa000, so that inbound and outbound pci transactions
+* work properly including DMA.
+*/
+ ranges = 0x0200 0x 0xa000
0xa000 0x 0x2000
+ 0x0100 0x 0x
0xf000 0x 0x0001;
+
+ #interrupt-cells = 1;
+ interrupt-parent = xps_intc_0;
+ interrupt-map-mask = 0xff00 0x0 0x0 0x7;
+ interrupt-map =
+ /* IRQ mapping for pci slots and ALI
M1533 periperhals. In total there are
+* 5 interrupt lines connected to a
xps_intc controller. Four of them are PCI
+* IRQ A, B, C, D and which correspond
to respectively xpx_intc 5, 4, 3 and 2.
+* The fifth interrupt line is
connected to the south bridge and this one
+* uses irq 1 and is active high
instead of active low.
+*
+* The M1533 contains various
peripherals including AC97 audio, a modem, USB,
+* IDE and some power management
stuff. The modem isn't connected on the ML510
+* and the power management core also
isn't used.
+*/
+
+ /* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */
+ 0x3000 0 0 1 xps_intc_0 3 2
+ 0x3000 0 0 2 xps_intc_0 2 2
+ 0x3000 0 0 3 xps_intc_0 5 2
+ 0x3000 0 0 4 xps_intc_0 4 2
+
+ /* IDSEL 0x13 / dev=3, bus=1 / PCI slot 4 */
+ /*
+ 0x11800 0 0 1 xps_intc_0 5 0 2
+ 0x11800 0 0 2 xps_intc_0 4 0 2
+ 0x11800 0 0 3 xps_intc_0 3 0 2
+ 0x11800 0 0 4 xps_intc_0 2 0 2
+ */
+
+ /* According to the datasheet +
schematic ABCD [FPGA] of slot 5 is mapped to DABC.
+* Testing showed that at least A maps
to B, the mapping of the other pins is a guess
+* and for that reason the lines have
been commented.
+*/
+ /* IDSEL 0x15 / dev=5, bus=0 / PCI slot 5 */
+ 0x2800 0 0 1 xps_intc_0 4 2
+ /*
+ 0x2800 0 0 2 xps_intc_0 3 2
+ 0x2800 0 0 3 xps_intc_0 2 2
+ 0x2800 0 0 4 xps_intc_0 5 2
+ */
+
+ /* IDSEL 0x12 / dev=2, bus=1 / PCI slot 6 */
+ /*
+ 0x11000 0 0 1 xps_intc_0 4 0 2
+ 0x11000 0 0 2 xps_intc_0 3 0 2
+ 0x11000 0 0 3 xps_intc_0 2 0 2
+ 0x11000 0 0 4 xps_intc_0 5 0 2
+ */
+
Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
On Thu, 2009-05-21 at 16:18 -0400, Jeremy Fitzhardinge wrote: I guess the test is checking for a bad implementation of map_single(). More importantly the io_tlb_overflow_buffer is basically a second chance if you exhaust the swiotlb pool. The check seems to be there to ensure that the second chance memory is suitable for the device (it's hard to imagine, but possible I suppose, that it wouldn't be), a bad implementation of map_single() is a secondary concern I suspect. If all the callers of map_page did proper error handling this would all be unnecessary. I guess someone was worried, at least at one point, that they didn't. The failure case could possibly be scribbling into a random memory location or more worryingly sprinkling random memory locations onto your disk or whatever. That said I'd imagine that map_page returning NULL would cause an oops long before anything tried to DMA anything and the second chance probably doesn't buy us much in practice. Ian. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc:beyond ARRAY_SIZE of args.args
Roel Kluin writes: Do not go beyond ARRAY_SIZE of args.args Signed-off-by: Roel Kluin roel.kl...@gmail.com --- I'm quite sure the first is correct, but should maybe `args.nret' and `nargs + args.nret' also be `= ARRAY_SIZE(args.args)'? I don't think this change is needed, and it changes a user-visible API, so I'm nacking it unless you can convince me there's really a problem. If nargs == ARRAY_SIZE(args.args), then args.nret must be zero, so nothing will access *(args.rets). Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux-next: powerpc tree build warning
Hi Ben, Today's linux-next build (powerpc ppc64_defconfig) produced this warning: arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_create': arch/powerpc/platforms/cell/spufs/inode.c:647: warning: label 'out_dput' defined but not used Introduced by commit 45db9240890d9343c934db1fe82d6e68ac2d28da (powerpc/spufs: Remove double check for non-negative dentry). -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpqsKvlqA0R7.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux-next: powerpc tree build warning
Hi Ben, Today's linux-next build (powerpc ppc64_defconfig) produced this warning: arch/powerpc/xmon/xmon.c: In function 'dump_log_buf': arch/powerpc/xmon/xmon.c:2133: warning: unused variable 'i' Introduced by commit f312deb4cd0c88196edf6dab192b7d42514398d6 (powerpc/xmon: Add dl command to dump contents of __log_buf). [As an aside, that commit contains this: Signed-off-by: Michael Ellerman michael at ellerman.id.au but we use real email addresses normally] -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpfbCyiSOyRc.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: question : DMA of PCI bridge
in the manual reference charpter 9.13 DMA, source and destination address If you are DMAing from an internal peripheral, then it's width will be hard-coded and can be read from the user-manual. you mean it will be set by hard circuit ? maybe i should talk with your hard engineer. but as you say, the width will be hard-coded, mean that the width can not be changed ? it can fetch 16 bits to 32bits, can not tetch 16bits to 16bits ? i am sorry about my poor English, i am not sure if i expressed clearly If you are DMAing from a local bus then the local bus definition should determine what happens. For example, on the MPC8349, you can put 16-bit flash on the local bus, and configure the local bus controller to know that it is 16-bits wide. A 32-bit access by the CPU or DMA controller will generate two reads on the local bus. that's right, BRx and ORx should be configured for setting width, but that is bus width, not data width. or bus width should be equal to data width what fetch from the bus ? You can investigate to see whether the MPC8247 works similarly. all right, i will , thanks a lot -- View this message in context: http://www.nabble.com/question-%3A-DMA-of-PCI-bridge-tp23628338p23663840.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/1] Remove __devinit annotation from pcibios_claim_one_bus()
pcibios_finish_adding_to_bus() is NOT annotated __devinit but it calls
pcibios_claim_one_bus(). pcibios_finish_adding_to_bus() is called from
at least the rpadlpar code which also is NOT annotated __devinit.
The annotation seems bogus so remove it.
Found by Jeremy Huddleston a reported at:
http://bugzilla.kernel.org/show_bug.cgi?id=13228
Signed-off-by: Tony Breeds t...@bakeyournoodle.com
---
arch/powerpc/kernel/pci-common.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 0f41812..a9f988f 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1469,7 +1469,7 @@ void __init pcibios_resource_survey(void)
* rest of the code later, for now, keep it as-is as our main
* resource allocation function doesn't deal with sub-trees yet.
*/
-void __devinit pcibios_claim_one_bus(struct pci_bus *bus)
+void pcibios_claim_one_bus(struct pci_bus *bus)
{
struct pci_dev *dev;
struct pci_bus *child_bus;
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio and mpc5200 bestcomm tasks
On Thu, May 21, 2009 at 12:52 PM, Jon Smirl jonsm...@gmail.com wrote: ALSA really wants to dynamically know the address of the current DMA location while transfers are active. This is an important piece of implementing pause/resume. Pause doesn't work too well if there is 2s of music already queued. The work around is to know the sample rate and use the jiffy count to estimate how far into the buffer DMA has progressed. But that's not as accurate as just asking the DMA hardware. I poked around in the SRAM data and couldn't find the address. Is it there or can the Bestcomm tasks be modified to leave it somewhere visible? It may be possible, but I haven't made any attempts at writing bestcomm task code. I've got no idea how difficult it would be. 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: [net-next-2.6 PATCH] can: SJA1000: generic OF platform bus driver
On Wed, May 20, 2009 at 11:06 AM, Wolfgang Grandegger w...@grandegger.com
wrote:
This patch adds a generic driver for SJA1000 chips on the OpenFirmware
platform bus found on embedded PowerPC systems. You need a SJA1000 node
definition in your flattened device tree source (DTS) file similar to:
c...@3,100 {
compatible = philips,sja1000;
reg = 3 0x100 0x80;
clock-frequency = 800;
cdr-reg = 0x48;
ocr-reg = 0x0a;
interrupts = 2 0;
interrupt-parent = mpic;
};
This new binding must be documented in Documentation/powerpc/dts-bindings
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: [PATCH] mpc52xx_psc_spi: Convert to cs_control callback
On Thu, Apr 30, 2009 at 4:31 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
mpc52xx_psc_spi driver is the last user of the legacy activate_cs
and deactivate_cs callbacks, so convert the driver to the cs_control
hook and remove the legacy callbacks from fsl_spi_platform_data
struct.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
David, will you pick this one up, or can I put it into Ben's powerpc
-next tree (since it is a powerpc-only device driver).
g.
---
drivers/spi/mpc52xx_psc_spi.c | 22 +-
include/linux/fsl_devices.h | 4
2 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index 68c77a9..e1901fd 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -13,6 +13,7 @@
#include linux/module.h
#include linux/init.h
+#include linux/types.h
#include linux/errno.h
#include linux/interrupt.h
#include linux/of_platform.h
@@ -30,8 +31,7 @@
struct mpc52xx_psc_spi {
/* fsl_spi_platform data */
- void (*activate_cs)(u8, u8);
- void (*deactivate_cs)(u8, u8);
+ void (*cs_control)(struct spi_device *spi, bool on);
u32 sysclk;
/* driver internal data */
@@ -111,18 +111,16 @@ static void mpc52xx_psc_spi_activate_cs(struct
spi_device *spi)
out_be16((u16 __iomem *)psc-ccr, ccr);
mps-bits_per_word = cs-bits_per_word;
- if (mps-activate_cs)
- mps-activate_cs(spi-chip_select,
- (spi-mode SPI_CS_HIGH) ? 1 : 0);
+ if (mps-cs_control)
+ mps-cs_control(spi, (spi-mode SPI_CS_HIGH) ? 1 : 0);
}
static void mpc52xx_psc_spi_deactivate_cs(struct spi_device *spi)
{
struct mpc52xx_psc_spi *mps = spi_master_get_devdata(spi-master);
- if (mps-deactivate_cs)
- mps-deactivate_cs(spi-chip_select,
- (spi-mode SPI_CS_HIGH) ? 1 : 0);
+ if (mps-cs_control)
+ mps-cs_control(spi, (spi-mode SPI_CS_HIGH) ? 0 : 1);
}
#define MPC52xx_PSC_BUFSIZE (MPC52xx_PSC_RFNUM_MASK + 1)
@@ -388,15 +386,13 @@ static int __init mpc52xx_psc_spi_do_probe(struct
device *dev, u32 regaddr,
mps-irq = irq;
if (pdata == NULL) {
dev_warn(dev, probe called without platform data, no
- (de)activate_cs function will be called\n);
- mps-activate_cs = NULL;
- mps-deactivate_cs = NULL;
+ cs_control function will be called\n);
+ mps-cs_control = NULL;
mps-sysclk = 0;
master-bus_num = bus_num;
master-num_chipselect = 255;
} else {
- mps-activate_cs = pdata-activate_cs;
- mps-deactivate_cs = pdata-deactivate_cs;
+ mps-cs_control = pdata-cs_control;
mps-sysclk = pdata-sysclk;
master-bus_num = pdata-bus_num;
master-num_chipselect = pdata-max_chipselect;
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index 244677c..43fc95d 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -79,10 +79,6 @@ struct fsl_spi_platform_data {
u16 max_chipselect;
void (*cs_control)(struct spi_device *spi, bool on);
u32 sysclk;
-
- /* Legacy hooks, used by mpc52xx_psc_spi driver. */
- void (*activate_cs)(u8 cs, u8 polarity);
- void (*deactivate_cs)(u8 cs, u8 polarity);
};
struct mpc8xx_pcmcia_ops {
--
1.6.2.2
--
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
[PATCH] powerpc/maple: Add a quirk to disable MSI for IPR on Bimini
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/platforms/maple/pci.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
It's getting late in the cycle, so until we can work out what's wrong
with IPR + MSI on Bimini, add a quirk to disable MSI for IPR.
diff --git a/arch/powerpc/platforms/maple/pci.c
b/arch/powerpc/platforms/maple/pci.c
index 3018552..04296ff 100644
--- a/arch/powerpc/platforms/maple/pci.c
+++ b/arch/powerpc/platforms/maple/pci.c
@@ -592,3 +592,17 @@ int maple_pci_get_legacy_ide_irq(struct pci_dev *pdev, int
channel)
}
return irq;
}
+
+static void __devinit quirk_ipr_msi(struct pci_dev *dev)
+{
+ /* Something prevents MSIs from the IPR from working on Bimini,
+* and the driver has no smarts to recover. So disable MSI
+* on it for now. */
+
+ if (machine_is(maple)) {
+ dev-no_msi = 1;
+ dev_info(dev-dev, Quirk disabled MSI\n);
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_OBSIDIAN,
+ quirk_ipr_msi);
--
1.6.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: problem in registering the device while inserting the kernel module
On Thu, May 21, 2009 at 12:20 AM, patel rajendra rdpate...@yahoo.co.in wrote: Hi Members of linuxppc, I'm working on XUPV2P board with Virtex II Pro FPGA device. I written a kernel module for LED device. I got that module run successfuly on ML403 board having Virtex 4 FPGA.I have not make any change in my source code for XUP board, because I don't feel any change is required. What kernel version are you using? Are you using arch/ppc or arch/powerpc? -- 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: [PATCH] powerpc/maple: Add a quirk to disable MSI for IPR on Bimini
On Fri, 2009-05-22 at 15:10 +1000, Michael Ellerman wrote:
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/platforms/maple/pci.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
It's getting late in the cycle, so until we can work out what's wrong
with IPR + MSI on Bimini, add a quirk to disable MSI for IPR.
Thanks, I'll send that to Linus for 2.6.30
Cheers,
Ben.
diff --git a/arch/powerpc/platforms/maple/pci.c
b/arch/powerpc/platforms/maple/pci.c
index 3018552..04296ff 100644
--- a/arch/powerpc/platforms/maple/pci.c
+++ b/arch/powerpc/platforms/maple/pci.c
@@ -592,3 +592,17 @@ int maple_pci_get_legacy_ide_irq(struct pci_dev *pdev,
int channel)
}
return irq;
}
+
+static void __devinit quirk_ipr_msi(struct pci_dev *dev)
+{
+ /* Something prevents MSIs from the IPR from working on Bimini,
+ * and the driver has no smarts to recover. So disable MSI
+ * on it for now. */
+
+ if (machine_is(maple)) {
+ dev-no_msi = 1;
+ dev_info(dev-dev, Quirk disabled MSI\n);
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_OBSIDIAN,
+ quirk_ipr_msi);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
