* next branch update
From: Benjamin Herrenschmidt @ 2009-05-21 7:26 UTC (permalink / raw)
To: linuxppc-dev list
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
^ permalink raw reply
* [RFC Patch 6/6] Adapt kexec and samples code to recognise PPC64 hardware breakpoint usage
From: K.Prasad @ 2009-05-21 7:18 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090521070751.156865078@prasadkr_t60p.in.ibm.com>
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 <prasad@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;
^ permalink raw reply
* [RFC Patch 5/6] Modify Data storage exception code to recognise DABR match first
From: K.Prasad @ 2009-05-21 7:18 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090521070751.156865078@prasadkr_t60p.in.ibm.com>
Modify Data storage exception code to first lookout for a DABR match before
recognising a kprobe or xmon exception.
Signed-off-by: K.Prasad <prasad@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 &= 0x48200000;
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;
^ permalink raw reply
* [RFC Patch 4/6] Modify process and processor handling code to recognise hardware debug registers
From: K.Prasad @ 2009-05-21 7:18 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090521070751.156865078@prasadkr_t60p.in.ibm.com>
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 <prasad@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_PENDING 16 /* 32/64 bit switch needed */
+#define TIF_DEBUG 17 /* uses debug registers */
/* as above, but as bit values */
#define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)
@@ -132,6 +133,7 @@ static inline struct thread_info *curren
#define _TIF_FREEZE (1<<TIF_FREEZE)
#define _TIF_RUNLATCH (1<<TIF_RUNLATCH)
#define _TIF_ABI_PENDING (1<<TIF_ABI_PENDING)
+#define _TIF_DEBUG (1<<TIF_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;
}
^ permalink raw reply
* [RFC Patch 3/6] Modify ptrace code to use Hardware Breakpoint interfaces
From: K.Prasad @ 2009-05-21 7:17 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090521070751.156865078@prasadkr_t60p.in.ibm.com>
Modify the ptrace code to use the hardware breakpoint interfaces for user-space.
Signed-off-by: K.Prasad <prasad@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;
^ permalink raw reply
* [RFC Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces
From: K.Prasad @ 2009-05-21 7:17 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090521070751.156865078@prasadkr_t60p.in.ibm.com>
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 <prasad@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.000000000 +0530
+++ linux-2.6-tip.hbkpt/arch/powerpc/Kconfig 2009-05-21 11:38:30.000000000 +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.000000000 +0530
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/Makefile 2009-05-21 11:38:30.000000000 +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.000000000 +0000
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/hw_breakpoint.c 2009-05-21 11:38:58.000000000 +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 = (unsigned long)
+ kallsyms_lookup_name(bp->info.name);
+ if (bp->info.address)
+ return 0;
+ return -EINVAL;
+}
+
+/*
+ * Validate the arch-specific HW Breakpoint register settings
+ */
+int arch_validate_hwbkpt_settings(struct hw_breakpoint *bp,
+ struct task_struct *tsk)
+{
+ int is_kernel, ret = -EINVAL;
+
+ if (!bp)
+ return ret;
+
+ switch (bp->info.type) {
+ case HW_BREAKPOINT_READ:
+ case HW_BREAKPOINT_WRITE:
+ case HW_BREAKPOINT_RW:
+ break;
+ default:
+ return ret;
+ }
+
+ if (bp->triggered)
+ ret = arch_store_info(bp, tsk);
+
+ /* Check for double word alignment - 8 bytes */
+ if (bp->info.address & HW_BREAKPOINT_ALIGN)
+ return -EINVAL;
+
+ is_kernel = is_kernel_addr(bp->info.address);
+ if ((tsk && is_kernel) || (!tsk && !is_kernel))
+ return -EINVAL;
+
+ return ret;
+}
+
+void arch_update_user_hw_breakpoint(int pos, struct task_struct *tsk)
+{
+ struct thread_struct *thread = &(tsk->thread);
+ struct hw_breakpoint *bp = thread->hbp[0];
+
+ if (bp)
+ thread->dabr = bp->info.address | bp->info.type |
+ DABR_TRANSLATION;
+ else
+ thread->dabr = 0;
+}
+
+void arch_flush_thread_hw_breakpoint(struct task_struct *tsk)
+{
+ struct thread_struct *thread = &(tsk->thread);
+
+ thread->dabr = 0;
+}
+
+/*
+ * Handle debug exception notifications.
+ */
+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 = 1;
+
+ /* Disable breakpoints during exception handling */
+ set_dabr(0);
+ dar = regs->dar & (~HW_BREAKPOINT_ALIGN);
+
+ cpu = get_cpu();
+ /* Determine whether kernel- or user-space address is the trigger */
+ bp = (hbp_kernel_pos == HBP_NUM) ? current->thread.hbp[0] :
+ per_cpu(this_hbp_kernel[0], cpu);
+ /*
+ * bp can be NULL due to lazy debug register switching
+ * or due to the delay between updates of hbp_kernel_pos
+ * and this_hbp_kernel.
+ */
+ if (!bp)
+ goto out;
+
+ if (dar == bp->info.address)
+ per_cpu(dabr_data, cpu) = (hbp_kernel_pos == HBP_NUM) ?
+ current->thread.dabr : kdabr;
+ else {
+ /*
+ * This exception is triggered because of other sources such as
+ * Xmon or kprobe and does not belong to us. Return NOTIFY_DONE.
+ */
+ rc = NOTIFY_DONE;
+ goto out;
+ }
+ (bp->triggered)(bp, regs);
+
+ stepped = emulate_step(regs, regs->nip);
+ /*
+ * Single-step the causative instruction manually if
+ * emulate_step() could not execute it
+ */
+ if (stepped == 0) {
+ regs->msr |= MSR_SE;
+ goto out;
+ }
+ set_dabr(per_cpu(dabr_data, cpu));
+ per_cpu(dabr_data, cpu) = 0;
+
+out:
+ /* Enable pre-emption only if single-stepping is finished */
+ if (stepped)
+ put_cpu_no_resched();
+ return rc;
+}
+
+/*
+ * Handle single-step exceptions following a DABR hit.
+ */
+int __kprobes single_step_dabr_instruction(struct die_args *args)
+{
+ struct pt_regs *regs = args->regs;
+ int cpu = get_cpu();
+ int ret = NOTIFY_DONE;
+ siginfo_t info;
+ unsigned long this_dabr_data = per_cpu(dabr_data, cpu);
+
+ /*
+ * Check if we are single-stepping as a result of a
+ * previous HW Breakpoint exception
+ */
+ if (this_dabr_data == 0)
+ goto out;
+
+ regs->msr &= ~MSR_SE;
+ /* Deliver signal to user-space */
+ if (this_dabr_data < TASK_SIZE) {
+ info.si_signo = SIGTRAP;
+ info.si_errno = 0;
+ info.si_code = TRAP_HWBKPT;
+ info.si_addr = (void __user *)(per_cpu(dabr_data, cpu));
+ force_sig_info(SIGTRAP, &info, current);
+ }
+
+ set_dabr(this_dabr_data);
+ per_cpu(dabr_data, cpu) = 0;
+ ret = NOTIFY_STOP;
+ /*
+ * If single-stepped after hw_breakpoint_handler(), pre-emption is
+ * already disabled.
+ */
+ put_cpu_no_resched();
+
+out:
+ /*
+ * A put_cpu_no_resched() call is required to complement the get_cpu()
+ * call used initially
+ */
+ put_cpu_no_resched();
+ return ret;
+}
+
+/*
+ * Handle debug exception notifications.
+ */
+int __kprobes hw_breakpoint_exceptions_notify(
+ struct notifier_block *unused, unsigned long val, void *data)
+{
+ int ret = NOTIFY_DONE;
+
+ switch (val) {
+ case DIE_DABR_MATCH:
+ ret = hw_breakpoint_handler(data);
+ break;
+ case DIE_SSTEP:
+ ret = single_step_dabr_instruction(data);
+ break;
+ }
+
+ return ret;
+}
^ permalink raw reply
* [RFC Patch 1/6] Prepare the PowerPC platform for HW Breakpoint infrastructure
From: K.Prasad @ 2009-05-21 7:17 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090521070751.156865078@prasadkr_t60p.in.ibm.com>
Prepare the PowerPC code for HW Breakpoint infrastructure patches by including
relevant constant definitions and function declarations.
Signed-off-by: K.Prasad <prasad@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_LEN 4 /* 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 0x00c00000 /* thread enable */
#define CTRL_RUNLATCH 0x1
#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)
^ permalink raw reply
* [RFC Patch 0/6] PPC64: Hardware Breakpoint interfaces - ver III
From: K.Prasad @ 2009-05-21 7:16 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
Roland McGrath
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
^ permalink raw reply
* Re: [RFC Patch 2/6] Introduce PPC64 specific Hardware Breakpointinterfaces
From: K.Prasad @ 2009-05-21 7:15 UTC (permalink / raw)
To: Alan Stern
Cc: Michael Neuling, Benjamin Herrenschmidt, linuxppc-dev, paulus,
Roland McGrath
In-Reply-To: <Pine.LNX.4.44L0.0905181227180.3136-100000@iolanthe.rowland.org>
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
^ permalink raw reply
* problem in registering the device while inserting the kernel module
From: patel rajendra @ 2009-05-21 6:20 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 9116 bytes --]
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: 00000000
REGS: c0705db0 TRAP: 0300 Not tainted (2.6.23xlnx)
MSR: 00029030 <EE,ME,IR,DR> CR: 24000024 XER: 00000000
DEAR: 0000004c, ESR: 00000000
TASK = c04c63d0[186] 'insmod' THREAD: c0704000
GPR00: d1006188 c0705e60 c04c63d0 00000000 000000d0 00000001 00000000 c0220ae0
GPR08: c006c60c 00000000 00000001 c04553f0 026f4bac 100b4260 d1003288 d1007668
GPR16: d1003288 d1003238 0000fff1 0000fff2 0000004c 00000000 d100762c c003e94c
GPR24: d1002e02 00000018 d1002000 00000019 d1000000 d1007598 d10077c8 00000000
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
38a00001 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 led_fops = {
owner: THIS_MODULE,
open: led_open,
read: led_read,
write: led_write,
release:led_release
};
/* Device Registration */
int xilinx_ml403_led_setup(void)
{
XGpio_Config xgpio_config;
struct cdev *cdev=0;
int retval = 0;
dev_t devno;
memset(&xilinx_ml403_led, 0, sizeof(struct led_instance));
/* Map the control registers in */
/* get baseaddress and highaddress */
xilinx_ml403_led.phy_baseaddr = LED_PHY_BASEADDR;
xilinx_ml403_led.remap_size = LED_PHY_HIGHADDR - LED_PHY_BASEADDR + 1;
xilinx_ml403_led.device_id = LED_DEVICE_ID;
if(!xilinx_ml403_led.phy_baseaddr ||
(xilinx_ml403_led.remap_size - xilinx_ml403_led.phy_baseaddr + 1 <
8))
{
printk(KERN_ERR "%s: Couldn't get registers resource\n\r","led");
retval = -EFAULT;
goto failed1;
}
if(!request_mem_region(xilinx_ml403_led.phy_baseaddr, xilinx_ml403_led.remap_size, DRIVER_NAME))
{
printk(KERN_ERR "Couldn't lock
memory region at 0x%08lX\n\r",(unsigned long)
xilinx_ml403_led.phy_baseaddr);
retval = -EBUSY;
goto failed2;
}
xilinx_ml403_led.virtual_baseaddr = ioremap(xilinx_ml403_led.phy_baseaddr, xilinx_ml403_led.remap_size);
if(!xilinx_ml403_led.virtual_baseaddr)
{
printk(KERN_ERR "Couldn't ioremap
memory at 0x%08lX\n\r", (unsigned long) xilinx_ml403_led.phy_baseaddr);
retval = -EFAULT;
goto failed3;
}
if(XGpio_CfgInitialize(&gp_out, &xgpio_config,xilinx_ml403_led.virtual_baseaddr) != XST_SUCCESS)
{
printk(KERN_ERR "%s: Couldn't initialize instance.\n\r","xilinx_led");
retval = -ENODEV;
goto failed3;
}
XGpio_SetDataDirection(&gp_out, LEDChan , 0x00000000);
cdev= kmalloc(sizeof(struct cdev), GFP_KERNEL);
if(!cdev)
{
printk(KERN_ERR "%s: Couldn't allocate device private record\n\r","led");
return -ENOMEM;
}
memset(cdev,0,sizeof(struct cdev));
cdev_init(cdev,&led_fops);
cdev->owner = THIS_MODULE;
cdev->ops = &led_fops;
devno = MKDEV(LED_MAJOR,LED_MINOR);
retval = cdev_add(cdev,devno,1);
xilinx_ml403_led.cdev;
printk(KERN_ERR "%s at 0x%081X mapped to 0x%08X
device:%u,%u\n\r","xilinx_led",xilinx_ml403_led.phy_baseaddr,(unsigned
int) xilinx_ml403_led.virtual_baseaddr,(unsigned
int)MAJOR(xilinx_ml403_led.cdev->dev),(unsigned
int)MINOR(xilinx_ml403_led.cdev->dev));
failed3:
iounmap((void *) (xilinx_ml403_led.phy_baseaddr));
failed2:
release_mem_region(xilinx_ml403_led.phy_baseaddr,xilinx_ml403_led.remap_size);
failed1:
return retval;
}
int __init led_init(void)
{
int retval;
retval=xilinx_ml403_led_setup();
if(retval)
return retval;
return 0;
}
void __exit led_exit(void)
{
cdev_del(xilinx_ml403_led.cdev);
iounmap((void *)(xilinx_ml403_led.virtual_baseaddr));
release_mem_region(xilinx_ml403_led.phy_baseaddr,xilinx_ml403_led..remap_size);
}
module_init(led_init);
module_exit(led_exit);
MODULE_AUTHOR("SANDEEPANI - SCHOOL OF EMBEDDDED DESIGN");
MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
MODULE_LICENSE("Dual BSD/GPL");
Explore your hobbies and interests. Go to http://in.promos.yahoo.com/groups/
[-- Attachment #2: Type: text/html, Size: 17275 bytes --]
^ permalink raw reply
* Re: problem in registering the device while inserting the kernel module
From: Grant Likely @ 2009-05-21 4:36 UTC (permalink / raw)
To: patel rajendra; +Cc: linuxppc-dev
In-Reply-To: <246420.44978.qm@web94801.mail.in2.yahoo.com>
On Wed, May 20, 2009 at 7:48 PM, patel rajendra <rdpatel55@yahoo.co.in> wrote:
> Hi Members of linuxppc,
[...]
> 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?
You really need to post your code before anyone will be able to help
you. We're not mind readers.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/2] maps/mtd-ram: add an of-platform driver
From: Grant Likely @ 2009-05-21 4:21 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, linux-mtd, ben-linux
In-Reply-To: <20090521004626.GA1635@pengutronix.de>
On Wed, May 20, 2009 at 6:46 PM, Wolfram Sang <w.sang@pengutronix.de> wrote=
:
>> > + =A0 =A0 =A0 name =3D of_get_property(op->node, "name", NULL);
>> > + =A0 =A0 =A0 if (!name) {
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D -ENOENT;
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_dbg(&op->dev, "could not get node na=
me\n");
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad1;
>> > + =A0 =A0 =A0 }
>
> Can I just use
>
> =A0 =A0 =A0 =A0name =3D op->node->name
>
> here? I wonder because of_device in asm/of_device.h states 'node' as "to =
be
> obsoleted"
It may be labeled as such, but it's been so for over 2 years now, and
op->node is used all over the place. I think Ben would like to
eventually move to using the node pointer in archdata, but that will
require a fair bit of refactoring.
Ben will kick me if I'm wrong, but I'll go out on a limb and say that
I think you're okay to use it.
>. And could I safely assume that all architectures will have the node
> entry?
All three current users do.
>> > +static struct of_device_id of_ram_match[] =3D {
>> > + =A0 =A0 =A0 { .compatible =3D "mtd-ram", },
>> > + =A0 =A0 =A0 {},
>> > +};
>> > +MODULE_DEVICE_TABLE(of, of_ram_match);
>> > +
>> > +static struct of_platform_driver of_ram_driver =3D {
>>
>> __devinitdata
>
> I assume you mean the match_table and not the of_platform_driver. Shouldn=
't it
> even better be const and using __devinitconst?
correct on both counts.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: question : DMA of PCI bridge
From: David Hawkins @ 2009-05-21 3:57 UTC (permalink / raw)
To: Sauce.Cheng; +Cc: linuxppc-dev
In-Reply-To: <23647394.post@talk.nabble.com>
Hi,
> my processor is MPC8247, on Linux 2.6.11
>
> in MPC8247 manual reference, the interrupt of DMA unit belonged PCI bridge.
> that is different from SDMA and IDMA. through i do not know what 's the
> different. heard SDMA is used to transfer between CPM and 60x. DMA is used
> to transfer between 60x bus and PCI, or 60x bus - 60x bus. i am not sure.
>
>> Whether or not you get packing bytes when you access a
>> 16-bit device and transfer the data to a 32-bit destination
>> depends on how the device is mapped. For example, a 16-bit
>> device can be implemented such that it responds to 8-bit,
>> 16-bit, and 32-bit requests, but the 32-bit requests will
>> require more wait-states, since the device has to be
>> read from twice before constructing a 32-bit word to
>> place on the PCI bus.
>
> ya, that's it
>
>> Its also possible that the DMA controller can be configured
>> to deal with different source and destination widths. However
>> without knowing what processor or DMA controller you are
>> asking about, theres not much to say.
>
> in the manual reference charpter 9.13 DMA, source and destination address
> can be configured. i can not find the hint about source and destination
> widths configured.
I won't have a chance to look at the MPC8247 manual, so
I'll just give a general comment.
If you are DMAing from an internal peripheral, then it's
width will be hard-coded and can be read from the user-manual.
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.
You can investigate to see whether the MPC8247 works similarly.
Cheers,
Dave
^ permalink raw reply
* Re: question : DMA of PCI bridge
From: Sauce.Cheng @ 2009-05-21 3:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4A137E4F.4040900@ovro.caltech.edu>
thank you dave for your reply
my processor is MPC8247, on Linux 2.6.11
in MPC8247 manual reference, the interrupt of DMA unit belonged PCI bridge.
that is different from SDMA and IDMA. through i do not know what 's the
different. heard SDMA is used to transfer between CPM and 60x. DMA is used
to transfer between 60x bus and PCI, or 60x bus - 60x bus. i am not sure.
> Whether or not you get packing bytes when you access a
> 16-bit device and transfer the data to a 32-bit destination
> depends on how the device is mapped. For example, a 16-bit
> device can be implemented such that it responds to 8-bit,
> 16-bit, and 32-bit requests, but the 32-bit requests will
> require more wait-states, since the device has to be
> read from twice before constructing a 32-bit word to
> place on the PCI bus.
ya, that's it
> Its also possible that the DMA controller can be configured
> to deal with different source and destination widths. However
> without knowing what processor or DMA controller you are
> asking about, theres not much to say.
in the manual reference charpter 9.13 DMA, source and destination address
can be configured. i can not find the hint about source and destination
widths configured.
--
View this message in context: http://www.nabble.com/question-%3A-DMA-of-PCI-bridge-tp23628338p23647394.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* problem in registering the device while inserting the kernel module
From: patel rajendra @ 2009-05-21 1:48 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]
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, 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: 00000000
REGS: c0705db0 TRAP: 0300 Not tainted (2.6.23xlnx)
MSR: 00029030 <EE,ME,IR,DR> CR: 24000024 XER: 00000000
DEAR: 0000004c, ESR: 00000000
TASK = c04c63d0[186] 'insmod' THREAD: c0704000
GPR00: d1006188 c0705e60 c04c63d0 00000000 000000d0 00000001 00000000 c0220ae0
GPR08: c006c60c 00000000 00000001 c04553f0 026f4bac 100b4260 d1003288 d1007668
GPR16: d1003288 d1003238 0000fff1 0000fff2 0000004c 00000000 d100762c c003e94c
GPR24: d1002e02 00000018 d1002000 00000019 d1000000 d1007598 d10077c8 00000000
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
38a00001 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?
Rajendra
Bollywood news, movie reviews, film trailers and more! Go to http://in.movies.yahoo.com/
[-- Attachment #2: Type: text/html, Size: 8766 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] maps/mtd-ram: add an of-platform driver
From: Wolfram Sang @ 2009-05-21 0:46 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-mtd, ben-linux
In-Reply-To: <fa686aa40905190757w68b35333j6f0fa84ea253a486@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6832 bytes --]
Hello Grant,
as I am just working on V2 (fixed even some additional things), two more
questions came up:
On Tue, May 19, 2009 at 08:57:15AM -0600, Grant Likely wrote:
> On Wed, Jan 21, 2009 at 11:41 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> > Create an of-aware driver using the now exported generic functions from
> > plat-ram.c. A typical oftree snipplet for it looks like this:
> >
> > sram@04e00000 {
> > compatible = "mtd-ram";
> > reg = <0x04e00000 0x00200000>;
> > bank-width = <2>;
> > };
> >
> > Partitions on this device are not yet supported.
>
> This is a new device tree binding. It must be documented in
> Documentation/powerpc/dts-bindings and posted to
> devicetree-discuss@ozlabs.org for review.
>
> > diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
> > index 6d9ba35..f8e3908 100644
> > --- a/drivers/mtd/maps/Makefile
> > +++ b/drivers/mtd/maps/Makefile
> > @@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_WRSBC8260) += wr_sbc82xx_flash.o
> > obj-$(CONFIG_MTD_DMV182) += dmv182.o
> > obj-$(CONFIG_MTD_SHARP_SL) += sharpsl-flash.o
> > obj-$(CONFIG_MTD_PLATRAM) += plat-ram.o
> > +obj-$(CONFIG_MTD_OFRAM) += of-ram.o
> > obj-$(CONFIG_MTD_OMAP_NOR) += omap_nor.o
> > obj-$(CONFIG_MTD_INTEL_VR_NOR) += intel_vr_nor.o
> > obj-$(CONFIG_MTD_BFIN_ASYNC) += bfin-async-flash.o
> > diff --git a/drivers/mtd/maps/of-ram.c b/drivers/mtd/maps/of-ram.c
> > new file mode 100644
> > index 0000000..4d334a9
> > --- /dev/null
> > +++ b/drivers/mtd/maps/of-ram.c
> > @@ -0,0 +1,120 @@
> > +/*
> > + * drivers/mtd/maps/of-ram.c
> > + *
> > + * Generic of device based RAM map
> > + *
> > + * Copyright (C) 2009 Wolfram Sang, Pengutronix
> > + *
> > + * Using plat-ram.c by Ben Dooks
> > + *
> > + * This program is free software; you can redistribute it and/or modify it
> > + * under the terms of the GNU General Public License version 2 as published by
> > + * the Free Software Foundation.
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/types.h>
> > +#include <linux/init.h>
> > +#include <linux/kernel.h>
> > +#include <linux/device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/of_device.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/mtd/plat-ram.h>
> > +
> > +static int of_ram_probe(struct of_device *op, const struct of_device_id *match)
>
> __devinit
>
> > +{
> > + struct platdata_mtd_ram *pdata;
> > + struct resource *resource;
> > + const char *name;
> > + const u32 *bankwidth;
> > + int ret = -ENOMEM;
> > +
> > + pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
> > + if (!pdata)
> > + goto bad0;
> > + op->dev.platform_data = pdata;
> > +
> > + name = of_get_property(op->node, "name", NULL);
> > + if (!name) {
> > + ret = -ENOENT;
> > + dev_dbg(&op->dev, "could not get node name\n");
> > + goto bad1;
> > + }
Can I just use
name = op->node->name
here? I wonder because of_device in asm/of_device.h states 'node' as "to be
obsoleted". And could I safely assume that all architectures will have the node
entry?
At least, I could drop the error check, if I understand booting-without-of
correctly? A name property will always be constructed, even if it is not
explicitly given.
> > +
> > + resource = kzalloc(sizeof(struct resource), GFP_KERNEL);
> > + if (!resource)
> > + goto bad1;
>
> Why isn't resource on the stack?
>
> > +
> > + if (of_address_to_resource(op->node, 0, resource)) {
> > + ret = -ENXIO;
> > + dev_dbg(&op->dev, "could not create resource\n");
> > + goto bad2;
> > + }
> > +
> > + bankwidth = of_get_property(op->node, "bank-width", NULL);
> > + if (*bankwidth == 0) {
> > + ret = -ENOENT;
> > + dev_dbg(&op->dev, "bank width not set\n");
> > + goto bad2;
> > + }
> > + pdata->bankwidth = *bankwidth;
> > +
> > + ret = __platram_probe(&op->dev, name, resource, pdata);
> > + kfree(resource);
> > +
> > + if (ret)
> > + goto bad1;
> > +
> > + return 0;
> > +
> > + bad2:
> > + kfree(resource);
> > + bad1:
> > + op->dev.platform_data = NULL;
> > + kfree(pdata);
> > + bad0:
> > + return ret;
>
> I'd rather see more meaningful labels. ie "err_kalloc:" and
> "err_platram_probe:".
>
> > +}
> > +
> > +static int of_ram_remove(struct of_device *op)
>
> __devexit
>
> > +{
> > + int ret;
> > + struct platdata_mtd_ram *pdata = op->dev.platform_data;
> > +
> > + ret = __platram_remove(&op->dev);
> > + op->dev.platform_data = NULL;
> > + kfree(pdata);
> > + return ret;
> > +}
> > +
> > +static struct of_device_id of_ram_match[] = {
> > + { .compatible = "mtd-ram", },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, of_ram_match);
> > +
> > +static struct of_platform_driver of_ram_driver = {
>
> __devinitdata
I assume you mean the match_table and not the of_platform_driver. Shouldn't it
even better be const and using __devinitconst?
>
> > + .owner = THIS_MODULE,
> > + .name = "of-ram",
>
> This name is too generic for an of_platform device. 'mtd' needs to be
> in there somewhere.
>
> > + .match_table = of_ram_match,
> > + .probe = of_ram_probe,
> > + .remove = of_ram_remove,
>
> __devexit_p()
>
> > +};
> > +
> > +static int __init of_ram_init(void)
> > +{
> > + return of_register_platform_driver(&of_ram_driver);
> > +}
> > +
> > +static void __exit of_ram_exit(void)
> > +{
> > + of_unregister_platform_driver(&of_ram_driver);
> > +}
> > +
> > +module_init(of_ram_init);
>
> Put the module_init() statement directly after the of_ram_init() definition.
>
> > +module_exit(of_ram_exit);
> > +
> > +MODULE_AUTHOR("Wolfram Sang");
> > +MODULE_DESCRIPTION("MTD OF RAM map driver");
> > +MODULE_LICENSE("GPL v2");
> > --
> > 1.5.6.5
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* RE: RapidIO - general questions
From: Anderson, Trevor @ 2009-05-20 23:42 UTC (permalink / raw)
To: Jan Neskudla, ext Li Yang; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1242802800.9160.143.camel@demuxf9c>
With=20regards=20to=20your=20Oops:=20we=20sometimes=20find=20that,=20altho=
ugh=20a=20switch=20may
report=20a=20port=20being=20active,=20whenever
we=20try=20to=20discover=20what=20lies=20behind=20it,=20transfer=20errors=20=
occur=20that=20are
non-recoverable.
As=20a=20solution,=20on=20Freescale=20MPC8641D,=20we=20use=20a=20DMA=20tra=
nsfer=20to=20perform=20a
simple=20MAINT=20read=20on=20a=20new=20device,=20just=20to=20see=20if=20it=
=20responds.=20Transfer
errors=20may=20still=20happen,=20but=20they=20are=20recoverable=20in=20tha=
t=20case,=20and=20you
can=20train=20your=20code=20to=20avoid=20that=20port=20or=20try=20it=20lat=
er.=20(The=20DMA=20engine
will=20report=20the=20error,=20not=20the=20processor.)
>=20-----Original=20Message-----
>=20From:=20linuxppc-dev-bounces+tanderson=3Dcurtisswright.com@ozlabs.org
[mailto:linuxppc-dev-
>=20bounces+tanderson=3Dcurtisswright.com@ozlabs.org]=20On=20Behalf=20Of=20=
Jan
Neskudla
>=20Sent:=20Wednesday,=20May=2020,=202009=2012:00=20AM
>=20To:=20ext=20Li=20Yang
>=20Cc:=20linuxppc-dev;=20linux-kernel@vger.kernel.org
>=20Subject:=20Re:=20RapidIO=20-=20general=20questions
>=20
>=20n=20Fri,=202009-05-15=20at=2015:56=20+0800,=20ext=20Li=20Yang=20wrote:=
>=20>=20On=20Fri,=20May=2015,=202009=20at=203:33=20PM,=20Jan=20Neskudla
<jan.neskudla.ext@nsn.com>=20wrote:
>=20>=20>=20On=20Wed,=202009-05-13=20at=2018:57=20+0800,=20ext=20Li=20Yang=
=20wrote:
>=20>=20>>=20cc'ed=20LKML
>=20>=20>>
>=20>=20>>=20On=20Tue,=20May=2012,=202009=20at=205:17=20PM,=20Jan=20Neskud=
la
<jan.neskudla.ext@nsn.com>=20wrote:
>=20>=20>>=20>=20Hallo
>=20>=20>>=20>
>=20>=20>>=20>=20we'd=20likes=20to=20use=20a=20RapidIO=20as=20a=20general=20=
communication=20bus=20on
our=20new
>=20>=20>>=20>=20product,=20and=20so=20I=20have=20some=20questions=20about=
=20general=20design=20of
Linux=20RIO
>=20>=20>>=20>=20subsystem.=20I=20did=20not=20find=20any=20better=20mailin=
g=20list=20for=20RapidIO
>=20>=20>>=20>=20discussion.
>=20>=20>>=20>
>=20>=20>>=20>=20[1]=20-=20we'd=20like=20to=20implement=20following=20feat=
ures
>=20>=20>>=20>=20=20=20=20*=20Hot-plug=20(hot-insert/hot-remove)=20of=20de=
vices
>=20>=20>>=20>=20=20=20=20*=20Error=20handling=20(port-write=20packets=20-=
=20configuration,
handling=20of
>=20>=20>>=20>=20them)
>=20>=20>>=20>=20=20=20=20*=20Static=20ID=20configuration=20based=20on=20p=
ort=20numbers
>=20>=20>>=20>=20=20=20=20*=20Aux=20driver=20-=20basic=20driver,=20for=20s=
ending=20messages=20over
different
>=20>=20>>=20>=20mboxes,=20handling=20ranges=20of=20doorbells
>=20>=20>>=20>
>=20>=20>>=20>=20=20=20=20Is=20it=20here=20anyone=20who=20is=20working=20o=
n=20any=20improvement,=20or
anyone=20who
>=20>=20>>=20>=20knows=20the=20development=20plans=20for=20RapidIO=20subsy=
stem?
>=20>=20>>=20>
>=20>=20>>
>=20>=20>>=20AFAIK,=20there=20is=20no=20one=20currently=20working=20on=20t=
hese=20features=20for
Linux.
>=20>=20>>=20It=20will=20be=20good=20if=20you=20can=20add=20these=20useful=
=20features.
>=20>=20>=20Yes=20it=20looks=20like=20that,=20currently=20we=20are=20analy=
zing=20current=20rapidIO
>=20>=20>=20system,=20and=20how=20we=20can=20add=20these=20features.
>=20>=20>
>=20>=20>>
>=20>=20>>=20>=20[2]=20-=20I=20have=20a=20following=20problem=20with=20a=20=
current=20implementation
of
>=20>=20>>=20>=20loading=20drivers.=20The=20driver=20probe-function=20call=
=20is=20based=20on
comparison
>=20>=20>>=20>=20of=20VendorID=20(VID)=20and=20DeviceID=20(DID)=20only.=20=
Thus=20if=20I=20have=203
devices=20with
>=20>=20>>=20>=20same=20DID=20and=20VID=20connected=20to=20the=20same=20ne=
twork=20(bus),=20the
driver=20is
>=20>=20>>=20>=20loaded=203times,=20instead=20only=20once=20for=20the=20ac=
tual=20device=20Master
port.
>=20>=20>>
>=20>=20>>=20This=20should=20be=20the=20correct=20way=20as=20you=20actuall=
y=20have=203=20instances
of=20the=20device.
>=20>=20>>
>=20>=20>>=20>
>=20>=20>>=20>=20Rionet=20driver=20solved=20this=20by=20enabling=20to=20ca=
ll=20initialization
function
>=20>=20>>=20>=20just=20once,=20and=20it=20expect=20that=20this=20is=20the=
=20Master=20port.
>=20>=20>>
>=20>=20>>=20Rionet=20is=20kind=20of=20special.=20=20It's=20not=20working=20=
like=20a=20simple=20device
>=20>=20>>=20driver,=20but=20more=20like=20a=20customized=20protocol=20sta=
ck=20to=20support
multiple
>=20>=20>>=20ethernet=20over=20rio=20links.
>=20>=20>>
>=20>=20>>=20>
>=20>=20>>=20>=20Is=20it=20this=20correct=20behavior=20=20?=20It=20looks=20=
to=20me=20that=20RapidIO=20is
handled
>=20>=20>>=20>=20like=20a=20local=20bus=20(like=20PCI)
>=20>=20>>
>=20>=20>>=20This=20is=20correct=20behavior.=20=20All=20of=20them=20are=20=
using=20Linux
device/driver
>=20>=20>>=20infrastructure,=20but=20rionet=20is=20a=20special=20device.
>=20>=20>
>=20>=20>=20But=20I=20do=20not=20have=20a=203=20devices=20on=20one=20silic=
on.=20I=20am=20talking=20about=203
>=20>=20>=20devices=20(3=20x=20EP8548=20boards=20+=20IDT=20switch)=20conne=
cted=20over=20rapidIO
through
>=20>=20>=20the=20switch.=20And=20in=20this=20case=20I'd=20like=20to=20hav=
e=20only=20one=20driver
siting=20on
>=20>=20>=20the=20top=20of=20Linux=20RapidIO=20subsystem.=20I=20don't=20se=
e=20the=20advantage=20of
loading
>=20>
>=20>=20You=20are=20having=20one=20driver,=20but=20it=20probes=203=20times=
=20for=20each=20device
using
>=20>=20the=20driver.
>=20>
>=20>=20>=20a=20driver=20locally=20for=20remote=20device.=20Am=20I=20missi=
ng=20something=20=20?
>=20>
>=20>=20If=20you=20want=20to=20interact=20with=20the=20remote=20device,=20=
you=20need=20the=20driver
to
>=20>=20do=20the=20work=20locally.
>=20
>=20We=20are=20going=20to=20use=20a=20RapidIO=20as=20a=20bigger=20network=20=
of=20active=20devices,
and
>=20each=20will=20have=20each=20own=20driver=20(sitting=20on=20its=20own),=
=20and=20all=20the
>=20settings=20will=20be=20done=20over=20maintenance=20packets.
>=20
>=20May=20be=20it=20will=20be=20solved=20by=20the=20fact,=20that=20we=20ar=
e=20going=20to=20use=20a
>=20staticIDs,=20so=20there=20will=20be=20no=20discovery=20as=20it=20is=20=
now.=20And=20thus=20there
>=20will=20be=20only=20one=20device=20visible=20in=20the=20internal=20stru=
ctures=20of=20the
>=20subsystem,=20and=20thus=20only=20one=20drive=20will=20be=20loaded.
>=20
>=20>
>=20>=20>
>=20>=20>=20And=20one=20more=20think,=20I=20am=20getting=20so=20much=20Bus=
=20errors=20OOPSes.
Whenever
>=20>=20>=20there=20is=20a=20problem=20with=20a=20comunication=20over=20Ri=
o=20I=20get=20such=20a
kernel=20OPS.
>=20>=20>=20I=20had=20to=20add=20some=20delays=20into=20some=20function=20=
to=20be=20able=20to=20finish
the
>=20>=20>=20enum+discovery=20process.=20Did=20you=20have=20some=20experien=
ce=20with=20some
bigger
>=20>=20>=20rio=20network=20running=20under=20linux=20?
>=20>
>=20>=20It=20looks=20like=20an=20known=20issue=20for=20switched=20rio=20ne=
twork,=20but=20I=20don't
>=20>=20have=20the=20correct=20equipment=20to=20reproduce=20the=20problem=20=
here.=20=20Could=20you
>=20>=20do=20some=20basic=20debugging=20and=20share=20your=20findings?=20=20=
Thanks.
>=20
>=20I=20tried=20to=20acquired=20some=20info=20about=20the=20problem,=20I=20=
found=20that=20the=20OOPS
>=20always=20occur=20when=20there=20is=20no=20respond=20from=20the=20devic=
e=20or=20the=20respond
is
>=20too=20slow.=20I=20always=20got=20that=20error=20during=20function=20ca=
ll
>=20rio_get_host_deviceid_lock=20when=20it=20tries=20to=20access=20a=20rem=
ote=20device=20or
>=20switch.=20This=20function=20is=20the=20first=20call=20of=20the
rio_mport_read_config_32
>=20so=20is=20also=20first=20try=20of=20remote=20access=20to=20any=20devic=
e.
>=20
>=20It=20is=20a=20timing=20issue,=20and=20after=20placing=20a=20printk=20i=
nto=20the
>=20rio_get_host_deviceid_lock=20the=20OOPSing=20almost=20disappeared.
>=20
>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20Jan
>=20
>=20>
>=20>=20-=20Leo
>=20
>=20_______________________________________________
>=20Linuxppc-dev=20mailing=20list
>=20Linuxppc-dev@ozlabs.org
>=20https://ozlabs.org/mailman/listinfo/linuxppc-dev
_______________________________________________________________________
This=20e-mail=20and=20any=20files=20transmitted=20with=20it=20are=20propri=
etary=20and=20intended=20solely=20for=20the=20use=20of=20the=20individual=20=
or=20entity=20to=20whom=20they=20are=20addressed.=20If=20you=20have=20reas=
on=20to=20believe=20that=20you=20have=20received=20this=20e-mail=20in=20er=
ror,=20please=20notify=20the=20sender=20and=20destroy=20this=20email=20and=
=20any=20attached=20files.=20Please=20note=20that=20any=20views=20or=20opi=
nions=20presented=20in=20this=20e-mail=20are=20solely=20those=20of=20the=20=
author=20and=20do=20not=20necessarily=20represent=20those=20of=20the=20Cur=
tiss-Wright=20Corporation=20or=20any=20of=20its=20subsidiaries.=20=20Docum=
ents=20attached=20hereto=20may=20contain=20technology=20subject=20to=20gov=
ernment=20export=20regulations.=20Recipient=20is=20solely=20responsible=20=
for=20ensuring=20that=20any=20re-export,=20transfer=20or=20disclosure=20of=
=20this=20information=20is=20in=20accordance=20with=20applicable=20governm=
ent=20export=20regulations.=20=20The=20recipient=20should=20check=20this=20=
e-mail=20and=20any=20attachments=20for=20the=20presence=20of=20viruses.=20=
Curtiss-Wright=20Corporation=20and=20its=20subsidiaries=20accept=20no=20li=
ability=20for=20any=20damage=20caused=20by=20any=20virus=20transmitted=20b=
y=20this=20e-mail.
^ permalink raw reply
* How to debug a hung multi-core system....
From: Morrison, Tom @ 2009-05-20 23:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Young, Andrew, Brown, Jeff
All,
First off, we turned SPE off completely in our build - so we=20
could debug a much deeper problem that seems to be occurring=20
in our application (before we try to find a potential test=20
case for corruption of GPR registers).
We have had this problem for 3 weeks, and just recently have=20
come down to a single test case that makes it fail (although=20
extremely complicated test case)...
Setup: =20
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=20
capacity too flawlessly). The single 'slave' 8572E blades=20
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)=20
the application works in all conditions (from modestly loaded to=20
well oversubscribed/pegged CPU).
In Multi-core option, the application also works flawlessly. The=20
problem comes when we oversubscribe our application and push=20
this 'slave' blade to the extreme edge of processing (falling=20
behind in our processing...etc).=20
Eventually, sometime between 5-15 minutes, this board becomes=20
hung (where the console becomes completely unresponsive and=20
you cannot 'ping' the box).
I have a JTAG WindRiver ICE and connect to this blade after it=20
is hung, and it appears that both cores are running to some=20
extent:
Core 1 seems to be Idle loop - happily doing nothing=20
(and not servicing TCP and/or the console)...
Core 0 seems to be 'stuck' at the "InstructionStorage"=20
Exception. And it seems to be going 'nowhere' fast
SRR0 seems to point to this same spot (0xc00006C0)
SRR1 value is 0x00021200=20
I am at a loss to see how the kernel (and/or our kernel BSP)=20
cause this exception, and I am even more of a loss on figuring=20
out an application could cause this exception...
Anybody have any ideas - and/or ways to re-configure our=20
setup to obtain more data? Or does this sound familiar to=20
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=20
anybody have an simple 'c' (or ppc assembly) program that=20
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!
Sincerely,
Tom Morrison
Principal Software Engineer
EMPIRIX=20
20 Crosby Drive - Bedford, MA 01730
p: 781.266.3567 f: 781.266.3670=20
email: tmorrison@empirix.com=20
www.empirix.com
^ permalink raw reply
* [PATCH V2] powerpc/pcm030.dts: add i2c eeprom and delete cruft
From: Wolfram Sang @ 2009-05-20 22:59 UTC (permalink / raw)
To: w.sang; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40905200936o63f47937rda28126ce0f46aad@mail.gmail.com>
Add a node for the i2c eeprom and delete the superflous gpio-example.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org
---
Changes since V1: use vendor name in eeprom-node
arch/powerpc/boot/dts/pcm030.dts | 26 ++++----------------------
1 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/boot/dts/pcm030.dts b/arch/powerpc/boot/dts/pcm030.dts
index 8958347..30bfdc0 100644
--- a/arch/powerpc/boot/dts/pcm030.dts
+++ b/arch/powerpc/boot/dts/pcm030.dts
@@ -258,34 +258,16 @@
compatible = "nxp,pcf8563";
reg = <0x51>;
};
- /* FIXME: EEPROM */
+ eeprom@52 {
+ compatible = "catalyst,24c32";
+ reg = <0x52>;
+ };
};
sram@8000 {
compatible = "fsl,mpc5200b-sram","fsl,mpc5200-sram";
reg = <0x8000 0x4000>;
};
-
- /* This is only an example device to show the usage of gpios. It maps all available
- * gpios to the "gpio-provider" device.
- */
- gpio {
- compatible = "gpio-provider";
-
- /* mpc52xx exp.con patchfield */
- gpios = <&gpio_wkup 0 0 /* GPIO_WKUP_7 11d jp13-3 */
- &gpio_wkup 1 0 /* GPIO_WKUP_6 14c */
- &gpio_wkup 6 0 /* PSC2_4 43c x5-11 */
- &gpio_simple 2 0 /* IRDA_1 24c x7-6 set GPS_PORT_CONFIG[IRDA] = 0 */
- &gpio_simple 3 0 /* IRDA_0 x8-5 set GPS_PORT_CONFIG[IRDA] = 0 */
- &gpt2 0 0 /* timer2 12d x4-4 */
- &gpt3 0 0 /* timer3 13d x6-4 */
- &gpt4 0 0 /* timer4 61c x2-16 */
- &gpt5 0 0 /* timer5 44c x7-11 */
- &gpt6 0 0 /* timer6 60c x8-15 */
- &gpt7 0 0 /* timer7 36a x17-9 */
- >;
- };
};
pci@f0000d00 {
--
1.6.2
^ permalink raw reply related
* Re: Musings on PCI busses
From: Benjamin Herrenschmidt @ 2009-05-20 22:49 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, thunderbird2k, John.Linn
In-Reply-To: <20090520.154104.48737237.davem@davemloft.net>
On Wed, 2009-05-20 at 15:41 -0700, David Miller wrote:
> This is exactly what sparc64 does as well, I took the powerpc code. :)
>
> It also avoids a bunch of bugs that get unearthed as a result of
> scanning the entire hierarchy with PCI config access "pokes". Some
> PCI controllers hang when certain PCI config space addresses are
> accessed, meanwhile some hypervisor versions don't generate the bus
> timeout exception properly on PCI config accesses to nonexisting
> devices, the list is endless.
>
> And all of that went away when I imported the ppc64 code to do
> this using the OF device tree.
>
> So if you put this in a common place, let's consolidate the differences
> accumulated in the sparc64 code so I can use it too :-)
Allright, I'll give that a go asap, maybe tomorrow.
Cheers,
Ben.
^ permalink raw reply
* Re: Musings on PCI busses
From: David Miller @ 2009-05-20 22:41 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, thunderbird2k, John.Linn
In-Reply-To: <1242856782.16901.203.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Thu, 21 May 2009 07:59:42 +1000
> On ppc64, we have code that can "create" the pci_bus & pci_dev hierarchy
> from the OF tree (avoiding the config space probing entirely). This is
> very efficient and has some advantages such as avoiding touching the
> BARs for sizing (which mean avoiding to temporarily disable access to
> devices behind them, which can be useful when it's your serial port or
> system controller there) etc...
>
> It also have the advantage of avoiding a double PCI probe pass when the
> FW already did it and since most FW do ...
>
> I'm tempted to extract that code and stick it in a
> drivers/pci/probe_of.c or something like that for more generic usage. We
> also have a per-bus hook that allows to switch to "real" config space
> probing at any point of the hierarchy (for example, you can setup things
> so that only on-board devices are in OF and probed that away and
> anything on your slot gets probed by linux using config space, that sort
> of thing).
This is exactly what sparc64 does as well, I took the powerpc code. :)
It also avoids a bunch of bugs that get unearthed as a result of
scanning the entire hierarchy with PCI config access "pokes". Some
PCI controllers hang when certain PCI config space addresses are
accessed, meanwhile some hypervisor versions don't generate the bus
timeout exception properly on PCI config accesses to nonexisting
devices, the list is endless.
And all of that went away when I imported the ppc64 code to do
this using the OF device tree.
So if you put this in a common place, let's consolidate the differences
accumulated in the sparc64 code so I can use it too :-)
^ permalink raw reply
* Re: Musings on PCI busses
From: Grant Likely @ 2009-05-20 22:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, thunderbird2k, David Miller, John.Linn
In-Reply-To: <1242856782.16901.203.camel@pasglop>
On Wed, May 20, 2009 at 3:59 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2009-05-20 at 14:06 -0600, Grant Likely wrote:
>> On Wed, May 20, 2009 at 1:24 PM, David Miller <davem@davemloft.net> wrot=
e:
>> >> What do you mean by fully resolve ? IE. The issue above is specific t=
o
>> >> IO space, which you can resolve both as MMIO, or as "IO" which in lin=
ux
>> >> means going through the special mapping for IO which allows the use o=
f
>> >> the inX/outX instructions...
>> >
>> > I mean that all OF devices have fully resolved MMIO resources. =A0So
>> > very early serial devices that sit in I/O space on sparc64 end
>> > up being OF device drivers. =A0See for example, drivers/net/sunsu.c
>> > which is simply a 8250 chip that sits behind Sun's I/O space bus
>> > that sits on PCI and provides things normally found via ISA on
>> > x86 machines. =A0Another example is drivers/serial/sunsab.c
>>
>> Unfortunately in the embedded powerpc case we don't actually have real
>> OF. =A0We've only got the flattened device tree which usually doesn't
>> itemize the devices behind the PCI bus. =A0Instead we rely on the kernel
>> probing for them.
>
> We -can- itemize the PCI bus, it's up to you.
Yes, we could. But I don't think it makes any sense to for the FDT
case. The firmware infrastructure is not in place to fill out the
device tree with the PCI bus layout for the off board devices.
>
> That leads to another interesting discussion...
>
> On ppc64, we have code that can "create" the pci_bus & pci_dev hierarchy
> from the OF tree (avoiding the config space probing entirely). This is
> very efficient and has some advantages such as avoiding touching the
> BARs for sizing (which mean avoiding to temporarily disable access to
> devices behind them, which can be useful when it's your serial port or
> system controller there) etc...
>
> It also have the advantage of avoiding a double PCI probe pass when the
> FW already did it and since most FW do ...
>
> I'm tempted to extract that code and stick it in a
> drivers/pci/probe_of.c or something like that for more generic usage. We
> also have a per-bus hook that allows to switch to "real" config space
> probing at any point of the hierarchy (for example, you can setup things
> so that only on-board devices are in OF and probed that away and
> anything on your slot gets probed by linux using config space, that sort
> of thing).
That would be interesting.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Musings on PCI busses
From: Benjamin Herrenschmidt @ 2009-05-20 21:59 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, thunderbird2k, David Miller, John.Linn
In-Reply-To: <fa686aa40905201306j4ef96cafl8ac02736dbdf7e5@mail.gmail.com>
On Wed, 2009-05-20 at 14:06 -0600, Grant Likely wrote:
> On Wed, May 20, 2009 at 1:24 PM, David Miller <davem@davemloft.net> wrote:
> >> What do you mean by fully resolve ? IE. The issue above is specific to
> >> IO space, which you can resolve both as MMIO, or as "IO" which in linux
> >> means going through the special mapping for IO which allows the use of
> >> the inX/outX instructions...
> >
> > I mean that all OF devices have fully resolved MMIO resources. So
> > very early serial devices that sit in I/O space on sparc64 end
> > up being OF device drivers. See for example, drivers/net/sunsu.c
> > which is simply a 8250 chip that sits behind Sun's I/O space bus
> > that sits on PCI and provides things normally found via ISA on
> > x86 machines. Another example is drivers/serial/sunsab.c
>
> Unfortunately in the embedded powerpc case we don't actually have real
> OF. We've only got the flattened device tree which usually doesn't
> itemize the devices behind the PCI bus. Instead we rely on the kernel
> probing for them.
We -can- itemize the PCI bus, it's up to you.
That leads to another interesting discussion...
On ppc64, we have code that can "create" the pci_bus & pci_dev hierarchy
from the OF tree (avoiding the config space probing entirely). This is
very efficient and has some advantages such as avoiding touching the
BARs for sizing (which mean avoiding to temporarily disable access to
devices behind them, which can be useful when it's your serial port or
system controller there) etc...
It also have the advantage of avoiding a double PCI probe pass when the
FW already did it and since most FW do ...
I'm tempted to extract that code and stick it in a
drivers/pci/probe_of.c or something like that for more generic usage. We
also have a per-bus hook that allows to switch to "real" config space
probing at any point of the hierarchy (for example, you can setup things
so that only on-board devices are in OF and probed that away and
anything on your slot gets probed by linux using config space, that sort
of thing).
Cheers,
Ben.
^ permalink raw reply
* Re: Musings on PCI busses
From: Benjamin Herrenschmidt @ 2009-05-20 21:56 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, thunderbird2k, John.Linn
In-Reply-To: <20090520.122453.169463011.davem@davemloft.net>
> I mean that all OF devices have fully resolved MMIO resources. So
> very early serial devices that sit in I/O space on sparc64 end
> up being OF device drivers. See for example, drivers/net/sunsu.c
> which is simply a 8250 chip that sits behind Sun's I/O space bus
> that sits on PCI and provides things normally found via ISA on
> x86 machines. Another example is drivers/serial/sunsab.c
Right. On Cell, we use the "normal" 8250 driver, via of_serial which
basically initializes it from the of device and associated resources.
It gets a bit messy because we -also- create a platform driver that can
be matched by 8250, in fact, we have a bit of generic powerpc code that
does that early at boot, initializes our low level very early udbg
thingy with it and creates the platform devices.
And then the serial port can -also- be detected by 8250_pci.c when it's
on a PCI based UART :-)
Now, generally thinks work fine even if you use all 3 drivers because
they have the same resources and 8250 has some smarts to figure that out
and not re-create ports. It somewhat fails in the case where we end up
with IO looking like MMIO on one side and looking like PCI IO on another
tho.
We -could- try to standardize on a single of those 3 methods of course.
The of_serial one has some appeal but I quite like the platform driver
approach at this stage because we have code to handle all sort of weirdo
special cases in there (more or less insane device-tree's, weird SoC's,
etc...) and still pump out something 8250_platform can grok, and that
code can run -very- early and provide a udbg backend for early debug and
xmon usage.
> I would make these device drivers OF device drivers.
>
> Another option is to make use of the "address" property if present.
> You can bypass all of the hassle of figuring out what the 'reg'
> property resolves to by using that and if the device is the
> console it is pretty reliable to expect OF to provide that "address"
> property.
>
> Of course this doesn't work well for non-console devices.
Also we have various broken firmwares with non usable "address"
properties to deal with.
Ben.
^ permalink raw reply
* Re: Musings on PCI busses
From: Grant Likely @ 2009-05-20 20:06 UTC (permalink / raw)
To: David Miller; +Cc: thunderbird2k, John.Linn, linuxppc-dev
In-Reply-To: <20090520.122453.169463011.davem@davemloft.net>
On Wed, May 20, 2009 at 1:24 PM, David Miller <davem@davemloft.net> wrote:
>> What do you mean by fully resolve ? IE. The issue above is specific to
>> IO space, which you can resolve both as MMIO, or as "IO" which in linux
>> means going through the special mapping for IO which allows the use of
>> the inX/outX instructions...
>
> I mean that all OF devices have fully resolved MMIO resources. =A0So
> very early serial devices that sit in I/O space on sparc64 end
> up being OF device drivers. =A0See for example, drivers/net/sunsu.c
> which is simply a 8250 chip that sits behind Sun's I/O space bus
> that sits on PCI and provides things normally found via ISA on
> x86 machines. =A0Another example is drivers/serial/sunsab.c
Unfortunately in the embedded powerpc case we don't actually have real
OF. We've only got the flattened device tree which usually doesn't
itemize the devices behind the PCI bus. Instead we rely on the kernel
probing for them.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox