* [PATCH V3 0/4] mpc5200 audio rework for AC97
From: Jon Smirl @ 2009-05-25 1:38 UTC (permalink / raw)
To: grant.likely, linuxppc-dev, alsa-devel, broonie
The following series implements audio support for the mpc5200. It adds an AC97 driver and STAC9766 codec driver.
Board support for the Efika and Phytec pcm030 are also included.
I've tried to implement the feedback received on the previous two versions.
based on commit 0bc53a67ac831ec84f730a657dbcadd80a589ef5 on broonie/for-2.6.31 at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git
---
Jon Smirl (4):
Fabric bindings for STAC9766 on the Efika
Support for AC97 on Phytec pmc030 base board.
AC97 driver for mpc5200
Main rewite of the mpc5200 audio DMA code
sound/soc/fsl/Kconfig | 27 ++
sound/soc/fsl/Makefile | 5
sound/soc/fsl/efika-audio-fabric.c | 95 +++++++
sound/soc/fsl/mpc5200_dma.c | 504 +++++++++++++++++++++++------------
sound/soc/fsl/mpc5200_dma.h | 33 +-
sound/soc/fsl/mpc5200_psc_ac97.c | 392 +++++++++++++++++++++++++++
sound/soc/fsl/mpc5200_psc_ac97.h | 15 +
sound/soc/fsl/mpc5200_psc_i2s.c | 247 +++--------------
sound/soc/fsl/mpc5200_psc_i2s.h | 12 +
sound/soc/fsl/pcm030-audio-fabric.c | 95 +++++++
10 files changed, 1036 insertions(+), 389 deletions(-)
create mode 100644 sound/soc/fsl/efika-audio-fabric.c
create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.c
create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.h
create mode 100644 sound/soc/fsl/mpc5200_psc_i2s.h
create mode 100644 sound/soc/fsl/pcm030-audio-fabric.c
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [Patch 6/6] Adapt kexec and samples code to recognise PPC64 hardware breakpoint usage
From: K.Prasad @ 2009-05-25 1:17 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090525004730.944465878@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
* [Patch 5/6] Modify Data storage exception code to recognise DABR match first
From: K.Prasad @ 2009-05-25 1:17 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090525004730.944465878@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
* [Patch 4/6] Modify process and processor handling code to recognise hardware debug registers
From: K.Prasad @ 2009-05-25 1:16 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090525004730.944465878@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
* [Patch 3/6] Modify ptrace code to use Hardware Breakpoint interfaces
From: K.Prasad @ 2009-05-25 1:16 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090525004730.944465878@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 | 44 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 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,36 @@ int ptrace_set_debugreg(struct task_stru
if (data && !(data & DABR_TRANSLATION))
return -EIO;
+#ifdef CONFIG_PPC64
+ bp = thread->hbp[0];
+ if (data == 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;
+ 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;
+
+ 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
* [Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces
From: K.Prasad @ 2009-05-25 1:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090525004730.944465878@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 | 279 ++++++++++++++++++++++++++++++++++++
3 files changed, 281 insertions(+), 1 deletion(-)
Index: linux-2.6-tip.hbkpt/arch/powerpc/Kconfig
===================================================================
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/Kconfig
+++ linux-2.6-tip.hbkpt/arch/powerpc/Kconfig
@@ -125,6 +125,7 @@ config PPC
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
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/Makefile
@@ -33,7 +33,7 @@ obj-$(CONFIG_PPC64) += setup_64.o sys_p
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
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/hw_breakpoint.c
@@ -0,0 +1,279 @@
+/*
+ * 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 & ~HW_BREAKPOINT_ALIGN) |
+ 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);
+
+ 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 & ~HW_BREAKPOINT_ALIGN) |
+ 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 = regs->dar;
+ int cpu, stepped = 1;
+
+ /* Disable breakpoints during exception handling */
+ set_dabr(0);
+
+ 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 not because of a memory access on
+ * the monitored variable but in the double-word address range
+ * in which it is contained. We will consume this exception,
+ * considering it as 'noise'.
+ */
+ rc = NOTIFY_STOP;
+ 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
* [Patch 1/6] Prepare the PowerPC platform for HW Breakpoint infrastructure
From: K.Prasad @ 2009-05-25 1:14 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090525004730.944465878@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
* [Patch 0/6] PPC64: Hardware Breakpoint interfaces - ver IV
From: K.Prasad @ 2009-05-25 1:13 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
Roland McGrath
Hi All,
Please find a new patchset that implements Hardware Breakpoint interfaces
for PPC64 architecture, the previous version of which was posted here:
http://ozlabs.org/pipermail/linuxppc-dev/2009-May/072387.html and the changes over
it are mentioned in the changelog below.
Changelog - ver IV
------------------
(Ver I: http://ozlabs.org/pipermail/linuxppc-dev/2009-May/071942.html)
(Ver II: http://ozlabs.org/pipermail/linuxppc-dev/2009-May/072106.html)
(Ver III: http://ozlabs.org/pipermail/linuxppc-dev/2009-May/072387.html
- While DABR register requires double-word (8 bytes) aligned addresses, i.e.
the breakpoint is active over a range of 8 bytes, PPC64 allows byte-level
addressability. This may lead to stray exceptions which have to be ignored in
hw_breakpoint_handler(), when DAR != (Breakpoint request address). However DABR
will be populated with the requested breakpoint address aligned to the previous
double-word address. The code is now modified to store user-requested address
in 'bp->info.address' but update the DABR with a double-word aligned address.
- Please note that the Data Breakpoint facility in Xmon is broken as of 2.6.29
and the same has not been integrated into this facility as described in Ver I.
Kindly review the patches and let me know if they're in a form that is ready for
upstream inclusion.
Thanks,
K.Prasad
^ permalink raw reply
* Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE
From: Benjamin Herrenschmidt @ 2009-05-25 0:21 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Albert Herranz, Ilya Yanok
In-Reply-To: <1243160487.22770.59.camel@pasglop>
On Sun, 2009-05-24 at 20:21 +1000, Benjamin Herrenschmidt wrote:
> We need to see if we can get the vmalloc allocator safe for GFP_ATOMIC
> context, might be doable.
>
> As for free, unfortunately, even the old allocator won't help with SMP,
> since that needs to do IPIs for cross TLB invalidates.
>
> Maybe we should enqueue free blocks and do the actual freeing from a
> workqueue or something similar.
Ok, so here's my conclusion:
First, I need to apologize as I'm the one iirc who told Ilya to
implement it that way... oops.
I don't think we can easily get the mm/vmalloc.c code irq safe,
especially not since it got bloated recently for scalability.
So at this stage, we have no choice I think be re-instate the old code.
This won't fix all the issues because we still can't do TLB shootdown in
SMP at interrupt time, but I don't think there's any released platform
in 2.6.30 that does SMP and non-coherent DMA, so we can fix that later.
I'll do the revert as it's not trivial (we removed CONFIG_CONSISTENT_*
etc...) for now.
Note that I still think the right approach in the long run is to ban the
consistent allocs from atomic contexts generically in linux, though that
will be a hard nut to crack.
Cheers,
Ben.
> Cheers,
> Ben.
>
> > On Thu, May 21, 2009 at 10:50 AM, Albert Herranz
> > <albert_herranz@yahoo.es> wrote:
> > >
> > > 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: 00000000
> > > TASK = d2c600f0[28] 'kmmcd' THREAD: d2c64000
> > > GPR00: 00010000 d2c65bc0 d2c600f0 d4030000 d4030000 d4030000 12da1000 00000001
> > > GPR08: 00000000 d2c64000 00000020 00000000 22482022 94fdfb98 6e1979bc c6bbdbdd
> > > GPR16: 00000020 00200200 00100100 d4020060 00000001 d401c0ec 00000001 d401c0ec
> > > GPR24: d2d9a6c0 00000000 00000000 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
> > >
> >
> >
> >
^ permalink raw reply
* Re: U-boot and linux command line parameters
From: David Gibson @ 2009-05-25 0:06 UTC (permalink / raw)
To: Mirek23; +Cc: linuxppc-dev
In-Reply-To: <23698384.post@talk.nabble.com>
On Sun, May 24, 2009 at 02:38:52PM -0700, Mirek23 wrote:
>
> Dear All,
>
> I use linux kernel 2.6.23 and u-boot 1.2.0 (on ppc405 virtex-4 ) for
> some time. All works fine when the kernel together with initramfs is
> smaller than 8MB. If it is bigger than the kernel does not boot
> properly.
>
> First of all I would like to know how the address for the linux
> command line parameters is "transferred" from u-boot to linux for
> ppc405 (virtex4 chip)? (via some registers or is it a fixed address
> in the memory ie. 8MB?) Does somebody know what should be changed,
> in the kernel, in order to move this limitation from 8MB to let say
> 12MB? I would be grateful for any hint.
IIRC, U-boot 1.2.0 is a version of u-boot before it became device tree
aware. Which means if I'm reading the cuboot.c code correctly, the
command line address is passed to the kernel at entry in r6, with the
length in r7. With later, device-tree aware u-boot versions, the
command line is instead passed as a device tree property.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
From: Arnd Bergmann @ 2009-05-24 22:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Linux Netdev List, devicetree-discuss
In-Reply-To: <4A18298E.8090209@grandegger.com>
On Saturday 23 May 2009, Wolfgang Grandegger wrote:
> Arnd Bergmann wrote:
> >
> > Minor nitpicking: dev->base_addr should be defined as an __iomem pointer
> > so you can avoid the cast here and in the ioremap/iounmap path.
>
> Here the member "base_addr" of "struct net_device" is used and it's not
> up to me to change the type.
Right, that makes sense. However, most drivers use the field to store the
physical address, not the iomap token. Maybe there should be a new field
in struct sja1000_priv for the virtual address, but that would be a change
to the base driver, not just to the OF portion.
Thanks,
Arnd <><
^ permalink raw reply
* Re: U-boot and linux command line parameters
From: Hunter Cobbs @ 2009-05-24 21:41 UTC (permalink / raw)
To: Mirek23; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <23698384.post@talk.nabble.com>
Have you considered using a kernel and initrd?
Hunter Cobbs
On May 24, 2009, at 4:38 PM, Mirek23 <miroslaw.dach@psi.ch> wrote:
>
> Dear All,
>
> I use linux kernel 2.6.23 and u-boot 1.2.0 (on ppc405 virtex-4 )
> for some
> time. All works fine when the
> kernel together with initramfs is smaller than 8MB. If it is bigger
> than the
> kernel does not boot properly.
>
> First of all I would like to know how the address for the linux
> command line
> parameters is "transferred" from u-boot to linux for ppc405 (virtex4
> chip)?
> (via some registers or is it a fixed address in the memory ie. 8MB?)
> Does somebody know what should be changed, in the kernel, in order
> to move
> this limitation from 8MB to let say 12MB? I would be grateful for
> any hint.
>
> Thanks in advance.
> M.
> --
> View this message in context: http://www.nabble.com/U-boot-and-linux-command-line-parameters-tp23698384p23698384.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
^ permalink raw reply
* U-boot and linux command line parameters
From: Mirek23 @ 2009-05-24 21:38 UTC (permalink / raw)
To: linuxppc-dev
Dear All,
I use linux kernel 2.6.23 and u-boot 1.2.0 (on ppc405 virtex-4 ) for some
time. All works fine when the
kernel together with initramfs is smaller than 8MB. If it is bigger than the
kernel does not boot properly.
First of all I would like to know how the address for the linux command line
parameters is "transferred" from u-boot to linux for ppc405 (virtex4 chip)?
(via some registers or is it a fixed address in the memory ie. 8MB?)
Does somebody know what should be changed, in the kernel, in order to move
this limitation from 8MB to let say 12MB? I would be grateful for any hint.
Thanks in advance.
M.
--
View this message in context: http://www.nabble.com/U-boot-and-linux-command-line-parameters-tp23698384p23698384.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH V2 5/9] Main rewite of the mpc5200 audio DMA code
From: Wolfram Sang @ 2009-05-24 20:35 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <9e4733910905241310n59952fd2oaafd7f1363db324@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]
On Sun, May 24, 2009 at 04:10:52PM -0400, Jon Smirl wrote:
> On Sun, May 24, 2009 at 2:55 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> >> Rewrite the mpc5200 audio DMA code to support both I2S and AC97. Make it more robust.
> >
> > Why is it more robust?
>
> I've implemented retries for when the AC97 hardware doesn't reset on
> first try. About 10% of the time both the Efika and pcm030 AC97 codecs
> don't reset on first try and need to be poked multiple times. Failure
> is indicated by not having the link clock start ticking. Every once in
> a while even five pokes won't get the link started and I have to power
> cycle.
>
> I don't have an oscilloscope, after I get these basic drivers in maybe
> someone can put a scope on this and figure out why reset is failing.
> I've read the various datasheets and I believe my reset pulses have
> the correct timings.
That's good to know. In fact, I think a summary of this should go into the
patch description.
--
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: [PATCH V2 5/9] Main rewite of the mpc5200 audio DMA code
From: Jon Smirl @ 2009-05-24 20:10 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <20090524185509.GA3561@pengutronix.de>
On Sun, May 24, 2009 at 2:55 PM, Wolfram Sang <w.sang@pengutronix.de> wrote=
:
>> Rewrite the mpc5200 audio DMA code to support both I2S and AC97. Make it=
more robust.
>
> Why is it more robust?
I've implemented retries for when the AC97 hardware doesn't reset on
first try. About 10% of the time both the Efika and pcm030 AC97 codecs
don't reset on first try and need to be poked multiple times. Failure
is indicated by not having the link clock start ticking. Every once in
a while even five pokes won't get the link started and I have to power
cycle.
I don't have an oscilloscope, after I get these basic drivers in maybe
someone can put a scope on this and figure out why reset is failing.
I've read the various datasheets and I believe my reset pulses have
the correct timings.
>
> --
> Pengutronix e.K. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Wo=
lfram Sang =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> Industrial Linux Solutions =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | http://www.p=
engutronix.de/ =A0|
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkoZmA0ACgkQD27XaX1/VRvugwCgsluxfp1rJH2MVFMTH6Yqo8bX
> dnIAn1z0QRIFEUJa0XpGFE937siwf8Cy
> =3DM0wP
> -----END PGP SIGNATURE-----
>
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [alsa-devel] [PATCH V2 1/9] Register the wm9712 DAIs on module load
From: Mark Brown @ 2009-05-24 19:14 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <9e4733910905240828q4b4cfd96xe840f3ae983143dc@mail.gmail.com>
On Sun, May 24, 2009 at 11:28:15AM -0400, Jon Smirl wrote:
> On Sun, May 24, 2009 at 7:11 AM, Mark Brown
> > Why do you wish to do this - ASoC does not require or use DAI registration
> > for AC97 CODECs?
> Then what is wrong with my binding code? If I take out the
> registration my bind fails.
It appears that the problem here is that your CPU DAI isn't marked as an
ac97 DAI by having ac97_control set so the core expects the codec to
instantiate prior to the card. Setting ac97_control ought to fix the
problem, but obviously I can't test.
When looking at problems like this it's worth taking a step back and
looking at why the existing code is the way that it is when considering
if you've found the right fix. In this case AC97 is fairly widely used
and there are also a number of WM9712 users but neither WM9712 or any of
the other AC97 CODEC drivers ever register their DAIs. That should be
an indication that either things probably should work without a change
to existing code or things are completely broken and something wider
than a change in a single driver is required in order to get things
working.
^ permalink raw reply
* Re: [PATCH V2 5/9] Main rewite of the mpc5200 audio DMA code
From: Wolfram Sang @ 2009-05-24 18:55 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <20090523231305.17919.12239.stgit@terra>
[-- Attachment #1: Type: text/plain, Size: 274 bytes --]
> Rewrite the mpc5200 audio DMA code to support both I2S and AC97. Make it more robust.
Why is it more robust?
--
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: [alsa-devel] [PATCH V2 0/9] mpc5200 audio rework for AC97
From: Mark Brown @ 2009-05-24 18:35 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <9e4733910905240821p7313f82bu171e0d4a2f3dbbff@mail.gmail.com>
On Sun, May 24, 2009 at 11:21:15AM -0400, Jon Smirl wrote:
> My AC97 driver is detecting the codec id and printing it before trying
> to access the codec driver. I can convert that to a load_module() call
> when the drivers are ready.
No, your AC97 driver shouldn't be doing any of this at all - it should
be leaving any enumeration of the hardware up to the machine driver and
the core. In so far as it is standardised the process for probing AC97
is something that can be implemented in terms of the operations exported
by the DAI so it should be done in the core for all AC97 DAIs. Where
standardised probing can't work it needs to be machine specific anyway.
^ permalink raw reply
* Re: [alsa-devel] [PATCH V2 4/9] Add a few more mpc5200 PSC defines
From: Mark Brown @ 2009-05-24 18:32 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <fa686aa40905241119t5e85311cj8a181c11b3890f0b@mail.gmail.com>
On Sun, May 24, 2009 at 12:19:37PM -0600, Grant Likely wrote:
> Nothing else needs it in MPC5200 land and I haven't applied it to my
> tree yet. Go ahead and add it to the ASoC tree.
OK, applied this and the two refactoring patches - thanks!
^ permalink raw reply
* Re: [PATCH V2 4/9] Add a few more mpc5200 PSC defines
From: Grant Likely @ 2009-05-24 18:19 UTC (permalink / raw)
To: Mark Brown; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20090524180023.GA4525@sirena.org.uk>
On Sun, May 24, 2009 at 12:00 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Sun, May 24, 2009 at 08:13:19AM -0600, Grant Likely wrote:
>> On Sat, May 23, 2009 at 5:13 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>> > Add a few more mpc5200 PSC defines. More bit fields defines for mpc5200 PSC registers. This patch is going in via Grant's tree.
>
>> > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
>
>> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> Jon's commit log says this is going in via your tree - is that the case
> or should I apply it to ASoC?
Nothing else needs it in MPC5200 land and I haven't applied it to my
tree yet. Go ahead and add it to the ASoC tree.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH V2 4/9] Add a few more mpc5200 PSC defines
From: Mark Brown @ 2009-05-24 18:00 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <fa686aa40905240713g2e79367mec0ba185432a94a@mail.gmail.com>
On Sun, May 24, 2009 at 08:13:19AM -0600, Grant Likely wrote:
> On Sat, May 23, 2009 at 5:13 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> > Add a few more mpc5200 PSC defines. More bit fields defines for mpc5200 PSC registers. This patch is going in via Grant's tree.
> > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Jon's commit log says this is going in via your tree - is that the case
or should I apply it to ASoC?
^ permalink raw reply
* Re: [alsa-devel] [PATCH V2 1/9] Register the wm9712 DAIs on module load
From: Jon Smirl @ 2009-05-24 15:32 UTC (permalink / raw)
To: Mark Brown; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <9e4733910905240828q4b4cfd96xe840f3ae983143dc@mail.gmail.com>
Output with SOC DEBUG turned on:
Advanced Linux Sound Architecture Driver Version 1.0.19.
No device for DAI stac9766 analog
Registered DAI 'stac9766 analog'
No device for DAI stac9766 IEC958
Registered DAI 'stac9766 IEC958'
No device for DAI tas5504
Registered DAI 'tas5504'
Registered platform 'mpc5200-psc-audio'
irq: irq 129 on host /soc5200@f0000000/interrupt-controller@500 mapped
to virtual irq 129
irq: irq 194 on host /soc5200@f0000000/interrupt-controller@500 mapped
to virtual irq 194
irq: irq 195 on host /soc5200@f0000000/interrupt-controller@500 mapped
to virtual irq 195
Registered DAI 'AC97'
Registered DAI 'SPDIF'
mpc5200-psc-ac97 f0002000.ac97: Codec ID is 574d 4c12
soc-audio soc-audio.1: DAI AC97 HiFi not registered
soc-audio soc-audio.1: Registered card 'pcm030'
ALSA device list:
No soundcards found.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [alsa-devel] [PATCH V2 1/9] Register the wm9712 DAIs on module load
From: Jon Smirl @ 2009-05-24 15:28 UTC (permalink / raw)
To: Mark Brown; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20090524111118.GC4933@sirena.org.uk>
On Sun, May 24, 2009 at 7:11 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Sat, May 23, 2009 at 07:12:57PM -0400, Jon Smirl wrote:
>> Register the wm9712 DAIs on module load
>
>> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
>
> Why do you wish to do this - ASoC does not require or use DAI registration
> for AC97 CODECs?
>
Then what is wrong with my binding code? If I take out the
registration my bind fails.
static struct snd_soc_dai_link pcm030_fabric_dai[] = {
{
.name = "AC97",
.stream_name = "AC97 Analog",
.codec_dai = &wm9712_dai[WM9712_DAI_AC97_HIFI],
.cpu_dai = &psc_ac97_dai[MPC5200_AC97_NORMAL],
},
{
.name = "AC97",
.stream_name = "AC97 IEC958",
.codec_dai = &wm9712_dai[WM9712_DAI_AC97_AUX],
.cpu_dai = &psc_ac97_dai[MPC5200_AC97_SPDIF],
},
};
static __init int pcm030_fabric_init(void)
{
struct platform_device *pdev;
int rc;
if (!machine_is_compatible("phytec,pcm030"))
return -ENODEV;
card.platform = &mpc5200_audio_dma_platform;
card.name = "pcm030";
card.dai_link = pcm030_fabric_dai;
card.num_links = ARRAY_SIZE(pcm030_fabric_dai);
device.card = &card;
device.codec_dev = &soc_codec_dev_wm9712;
pdev = platform_device_alloc("soc-audio", 1);
if (!pdev) {
pr_err("pcm030_fabric_init: platform_device_alloc() failed\n");
return -ENODEV;
}
platform_set_drvdata(pdev, &device);
device.dev = &pdev->dev;
rc = platform_device_add(pdev);
if (rc) {
pr_err("pcm030_fabric_init: platform_device_add() failed\n");
return -ENODEV;
}
return 0;
}
Advanced Linux Sound Architecture Driver Version 1.0.19.
No device for DAI stac9766 analog
No device for DAI stac9766 IEC958
No device for DAI tas5504
irq: irq 129 on host /soc5200@f0000000/interrupt-controller@500 mapped
to virtual irq 129
irq: irq 194 on host /soc5200@f0000000/interrupt-controller@500 mapped
to virtual irq 194
irq: irq 195 on host /soc5200@f0000000/interrupt-controller@500 mapped
to virtual irq 195
mpc5200-psc-ac97 f0002000.ac97: Codec ID is 574d 4c12
ALSA device list:
No soundcards found.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [alsa-devel] [PATCH V2 0/9] mpc5200 audio rework for AC97
From: Jon Smirl @ 2009-05-24 15:21 UTC (permalink / raw)
To: Mark Brown; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20090524110854.GB4933@sirena.org.uk>
On Sun, May 24, 2009 at 7:08 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> I'm not aware of any CODEC drivers which can't currently be built and
> used as modules. =A0If you mean "load via the normal device model" then
> yes, that'd be very good (and is in progress) but it's another issue and
> as I explained last time AC97 poses particular problems there.
>
I mean "load via the normal device model". For example the AC97
drivers need to be loadable by the codec id. There's no entry in
scripts/mod/file2alias.c for dynamically loading the modules. They
don't have an id_table.
My AC97 driver is detecting the codec id and printing it before trying
to access the codec driver. I can convert that to a load_module() call
when the drivers are ready.
The core needs to detect if a specific codec id can't be supported to
fall back to the generic AC97 driver.
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH V2 4/9] Add a few more mpc5200 PSC defines
From: Grant Likely @ 2009-05-24 14:13 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <20090523231303.17919.35877.stgit@terra>
On Sat, May 23, 2009 at 5:13 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> Add a few more mpc5200 PSC defines. More bit fields defines for mpc5200 P=
SC registers. This patch is going in via Grant's tree.
>
> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> =A00 files changed, 0 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mpc52xx_psc.h b/arch/powerpc/includ=
e/asm/mpc52xx_psc.h
> index a218da6..fb84120 100644
> --- a/arch/powerpc/include/asm/mpc52xx_psc.h
> +++ b/arch/powerpc/include/asm/mpc52xx_psc.h
> @@ -28,6 +28,10 @@
> =A0#define MPC52xx_PSC_MAXNUM =A0 =A0 6
>
> =A0/* Programmable Serial Controller (PSC) status register bits */
> +#define MPC52xx_PSC_SR_UNEX_RX 0x0001
> +#define MPC52xx_PSC_SR_DATA_VAL =A0 =A0 =A0 =A00x0002
> +#define MPC52xx_PSC_SR_DATA_OVR =A0 =A0 =A0 =A00x0004
> +#define MPC52xx_PSC_SR_CMDSEND 0x0008
> =A0#define MPC52xx_PSC_SR_CDE =A0 =A0 0x0080
> =A0#define MPC52xx_PSC_SR_RXRDY =A0 0x0100
> =A0#define MPC52xx_PSC_SR_RXFULL =A00x0200
> @@ -61,6 +65,12 @@
> =A0#define MPC52xx_PSC_RXTX_FIFO_EMPTY =A0 =A00x0001
>
> =A0/* PSC interrupt status/mask bits */
> +#define MPC52xx_PSC_IMR_UNEX_RX_SLOT 0x0001
> +#define MPC52xx_PSC_IMR_DATA_VALID =A0 =A0 0x0002
> +#define MPC52xx_PSC_IMR_DATA_OVR =A0 =A0 =A0 0x0004
> +#define MPC52xx_PSC_IMR_CMD_SEND =A0 =A0 =A0 0x0008
> +#define MPC52xx_PSC_IMR_ERROR =A0 =A0 =A0 =A0 =A00x0040
> +#define MPC52xx_PSC_IMR_DEOF =A0 =A0 =A0 =A0 =A0 0x0080
> =A0#define MPC52xx_PSC_IMR_TXRDY =A0 =A0 =A0 =A0 =A00x0100
> =A0#define MPC52xx_PSC_IMR_RXRDY =A0 =A0 =A0 =A0 =A00x0200
> =A0#define MPC52xx_PSC_IMR_DB =A0 =A0 =A0 =A0 =A0 =A0 0x0400
> @@ -117,6 +127,7 @@
> =A0#define MPC52xx_PSC_SICR_SIM_FIR =A0 =A0 =A0 =A0 =A0 =A0 =A0 (0x6 << 2=
4)
> =A0#define MPC52xx_PSC_SICR_SIM_CODEC_24 =A0 =A0 =A0 =A0 =A0(0x7 << 24)
> =A0#define MPC52xx_PSC_SICR_SIM_CODEC_32 =A0 =A0 =A0 =A0 =A0(0xf << 24)
> +#define MPC52xx_PSC_SICR_AWR =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (1 << 3=
0)
> =A0#define MPC52xx_PSC_SICR_GENCLK =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0(1 << 23)
> =A0#define MPC52xx_PSC_SICR_I2S =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (1 <<=
22)
> =A0#define MPC52xx_PSC_SICR_CLKPOL =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0(1 << 21)
>
>
--=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