Re: AMCC 405ex memory size issue
any ideas? konamo wrote: Hi all, we are using AMCC 405ex kilauea eval board as a demo, not use any pci/nand function, the board configuration is below: u-boot 2009.01, linux-2.6.25-rc2, 1GB DDR2 memory(2Gbit * 4, 1 rank), AMCC powerpc 405ex, both 1G and 512MB memory works fine under u-boot, but linux boot fails in 1G memory, if we limit mem=512M, linux could boot over nfs. Could anyone pls help us how to find the root cause? thanks -- View this message in context: http://www.nabble.com/AMCC-405ex-memory-size-issue-tp23631525p23701685.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
Re: [PATCH V3 2/4] AC97 driver for mpc5200
On Sun, May 24, 2009 at 7:38 PM, Jon Smirl jonsm...@gmail.com wrote:
AC97 driver for mpc5200
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.
Signed-off-by: Jon Smirl jonsm...@gmail.com
---
sound/soc/fsl/Kconfig | 11 +
sound/soc/fsl/Makefile | 1
sound/soc/fsl/mpc5200_psc_ac97.c | 392
++
sound/soc/fsl/mpc5200_psc_ac97.h | 15 +
4 files changed, 419 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.c
create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.h
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 1918c78..3bce952 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -29,3 +29,14 @@ config SND_SOC_MPC5200_I2S
select PPC_BESTCOMM_GEN_BD
help
Say Y here to support the MPC5200 PSCs in I2S mode.
+
+config SND_SOC_MPC5200_AC97
+ tristate Freescale MPC5200 PSC in AC97 mode driver
+ depends on PPC_MPC52xx PPC_BESTCOMM
+ select AC97_BUS
+ select SND_MPC52xx_DMA
+ select PPC_BESTCOMM_GEN_BD
+ help
+ Say Y here to support the MPC5200 PSCs in AC97 mode.
+
+
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 7731ef2..14631a1 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -13,4 +13,5 @@ obj-$(CONFIG_SND_SOC_MPC8610) += snd-soc-fsl-ssi.o
snd-soc-fsl-dma.o
# MPC5200 Platform Support
obj-$(CONFIG_SND_MPC52xx_DMA) += mpc5200_dma.o
obj-$(CONFIG_SND_SOC_MPC5200_I2S) += mpc5200_psc_i2s.o
+obj-$(CONFIG_SND_SOC_MPC5200_AC97) += mpc5200_psc_ac97.o
diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c
b/sound/soc/fsl/mpc5200_psc_ac97.c
new file mode 100644
index 000..480b677
--- /dev/null
+++ b/sound/soc/fsl/mpc5200_psc_ac97.c
@@ -0,0 +1,392 @@
+/*
+ * linux/sound/mpc5200-ac97.c -- AC97 support for the Freescale MPC52xx chip.
+ *
+ * Copyright (C) 2009 Jon Smirl, Digispeaker
+ * Author: Jon Smirl jonsm...@gmail.com
+ *
+ * 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/of_device.h
+#include linux/of_platform.h
+
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+
+#include asm/mpc52xx_psc.h
+
+#include mpc5200_dma.h
+#include mpc5200_psc_ac97.h
+
+#define DRV_NAME mpc5200-psc-ac97
+
+/* ALSA only supports a single AC97 device so static is recommend here */
+static struct psc_dma *psc_dma;
+
+static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short
reg)
+{
+ int timeout;
+ unsigned int val;
+
+ spin_lock(psc_dma-lock);
+
+ /* Wait for it to be ready */
+ timeout = 1000;
+ while ((--timeout) (in_be16(psc_dma-psc_regs-sr_csr.status)
+ MPC52xx_PSC_SR_CMDSEND))
+ udelay(10);
Holy unbounded latency Batman! This code waits up to 10ms for a register read!
I hate spinning, but if it must be done; I'd like to see it small.
What is the worst case latency? 125us for 8000Hz bus speed? If you
must spin; can a cpu_relax() be used instead of the udelay() while
watch the timebase? Timur recently posted a patch which makes this
easier.
http://patchwork.ozlabs.org/patch/27414/
They *should* be appearing in Ben's -next branch soon.
+
+ if (!timeout) {
+ pr_err(timeout on ac97 bus (rdy)\n);
+ return 0x;
+ }
+
+ /* Do the read */
+ out_be32(psc_dma-psc_regs-ac97_cmd, (131) | ((reg 0x7f)
24));
+
+ /* Wait for the answer */
+ timeout = 1000;
+ while ((--timeout) !(in_be16(psc_dma-psc_regs-sr_csr.status)
+ MPC52xx_PSC_SR_DATA_VAL))
+ udelay(10);
ditto.
+static int psc_ac97_cold_reset_check(struct snd_ac97 *ac97)
+{
+ int max_reset, timeout;
+ struct mpc52xx_psc __iomem *regs = psc_dma-psc_regs;
+
+ /* AC97 clock is generated by the codec.
+ * Ensure that it starts ticking after codec reset.
+ */
+ for (max_reset = 0; max_reset 5; max_reset++) {
+
+ /* Do a cold reset */
+ out_8(regs-op1, MPC52xx_PSC_OP_RES);
+ udelay(10);
+ out_8(regs-op0, MPC52xx_PSC_OP_RES);
+ udelay(50);
:-/ Don't like, but don't know if there is an alternative.
+
+ /* PSC recover from cold reset
+ * (cfr user
Re: [PATCH V3 1/4] Main rewite of the mpc5200 audio DMA code
On Sun, May 24, 2009 at 7:38 PM, Jon Smirl jonsm...@gmail.com wrote:
Rewrite the mpc5200 audio DMA code to support both I2S and AC97.
Signed-off-by: Jon Smirl jonsm...@gmail.com
---
sound/soc/fsl/Kconfig | 1
sound/soc/fsl/mpc5200_dma.c | 504
++-
sound/soc/fsl/mpc5200_dma.h | 33 +--
sound/soc/fsl/mpc5200_psc_i2s.c | 247 +++
sound/soc/fsl/mpc5200_psc_i2s.h | 12 +
5 files changed, 408 insertions(+), 389 deletions(-)
create mode 100644 sound/soc/fsl/mpc5200_psc_i2s.h
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index dc79bdf..1918c78 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -25,7 +25,6 @@ config SND_SOC_MPC8610_HPCD
config SND_SOC_MPC5200_I2S
tristate Freescale MPC5200 PSC in I2S mode driver
depends on PPC_MPC52xx PPC_BESTCOMM
- select SND_SOC_OF_SIMPLE
select SND_MPC52xx_DMA
select PPC_BESTCOMM_GEN_BD
help
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index 6850392..4e1f1f8 100644
--- a/sound/soc/fsl/mpc5200_dma.c
+++ b/sound/soc/fsl/mpc5200_dma.c
@@ -3,23 +3,13 @@
* ALSA SoC Platform driver
*
* Copyright (C) 2008 Secret Lab Technologies Ltd.
+ * Copyright (C) 2009 Jon Smirl, Digispeaker
*/
-#include linux/init.h
#include linux/module.h
-#include linux/interrupt.h
-#include linux/device.h
-#include linux/delay.h
#include linux/of_device.h
-#include linux/of_platform.h
-#include linux/dma-mapping.h
-#include sound/core.h
-#include sound/pcm.h
-#include sound/pcm_params.h
-#include sound/initval.h
#include sound/soc.h
-#include sound/soc-of-simple.h
#include sysdev/bestcomm/bestcomm.h
#include sysdev/bestcomm/gen_bd.h
@@ -27,10 +17,6 @@
#include mpc5200_dma.h
-MODULE_AUTHOR(Grant Likely grant.lik...@secretlab.ca);
-MODULE_DESCRIPTION(Freescale MPC5200 PSC in DMA mode ASoC Driver);
-MODULE_LICENSE(GPL);
-
/*
* Interrupt handlers
*/
@@ -50,7 +36,7 @@ static irqreturn_t psc_dma_status_irq(int irq, void
*_psc_dma)
if (psc_dma-capture.active (isr MPC52xx_PSC_IMR_ORERR))
psc_dma-stats.overrun_count++;
- out_8(regs-command, 4 4); /* reset the error status */
+ out_8(regs-command, MPC52xx_PSC_RST_ERR_STAT);
return IRQ_HANDLED;
}
@@ -81,8 +67,21 @@ static void psc_dma_bcom_enqueue_next_buffer(struct
psc_dma_stream *s)
s-period_next_pt = s-period_start;
}
+static void psc_dma_bcom_enqueue_tx(struct psc_dma_stream *s)
+{
+ while (s-appl_ptr s-runtime-control-appl_ptr) {
+
+ if (bcom_queue_full(s-bcom_task))
+ return;
+
+ s-appl_ptr += s-period_size;
+
+ psc_dma_bcom_enqueue_next_buffer(s);
+ }
+}
+
/* Bestcomm DMA irq handler */
-static irqreturn_t psc_dma_bcom_irq(int irq, void *_psc_dma_stream)
+static irqreturn_t psc_dma_bcom_irq_tx(int irq, void *_psc_dma_stream)
{
struct psc_dma_stream *s = _psc_dma_stream;
@@ -90,12 +89,12 @@ static irqreturn_t psc_dma_bcom_irq(int irq, void
*_psc_dma_stream)
* and enqueue a new one in it's place. */
while (bcom_buffer_done(s-bcom_task)) {
bcom_retrieve_buffer(s-bcom_task, NULL, NULL);
+
s-period_current_pt += s-period_bytes;
if (s-period_current_pt = s-period_end)
s-period_current_pt = s-period_start;
- psc_dma_bcom_enqueue_next_buffer(s);
- bcom_enable(s-bcom_task);
}
+ psc_dma_bcom_enqueue_tx(s);
/* If the stream is active, then also inform the PCM middle layer
* of the period finished event. */
@@ -105,49 +104,31 @@ static irqreturn_t psc_dma_bcom_irq(int irq, void
*_psc_dma_stream)
return IRQ_HANDLED;
}
-/**
- * psc_dma_startup: create a new substream
- *
- * This is the first function called when a stream is opened.
- *
- * If this is the first stream open, then grab the IRQ and program most of
- * the PSC registers.
- */
-int psc_dma_startup(struct snd_pcm_substream *substream,
- struct snd_soc_dai *dai)
+static irqreturn_t psc_dma_bcom_irq_rx(int irq, void *_psc_dma_stream)
{
- struct snd_soc_pcm_runtime *rtd = substream-private_data;
- struct psc_dma *psc_dma = rtd-dai-cpu_dai-private_data;
- int rc;
+ struct psc_dma_stream *s = _psc_dma_stream;
- dev_dbg(psc_dma-dev, psc_dma_startup(substream=%p)\n, substream);
+ /* For each finished period, dequeue the completed period buffer
+ * and enqueue a new one in it's place. */
+ while (bcom_buffer_done(s-bcom_task)) {
+ bcom_retrieve_buffer(s-bcom_task, NULL, NULL);
- if (!psc_dma-playback.active
- !psc_dma-capture.active) {
- /* Setup the IRQs */
- rc =
[PATCH] powerpc/pmac: Update PowerMac 32-bit defconfig
This mostly adds back AppleTouch support and adds CONFIG_HIGHMEM by default. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- arch/powerpc/configs/pmac32_defconfig | 278 +++--- 1 file changed, 195 insertions(+), 83 deletions(-) --- linux-work.orig/arch/powerpc/configs/pmac32_defconfig 2009-05-25 14:54:05.0 +1000 +++ linux-work/arch/powerpc/configs/pmac32_defconfig2009-05-25 14:54:08.0 +1000 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.28-rc3 -# Tue Nov 11 19:36:51 2008 +# Linux kernel version: 2.6.30-rc7 +# Mon May 25 14:53:25 2009 # # CONFIG_PPC64 is not set @@ -14,6 +14,7 @@ CONFIG_6xx=y # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set +CONFIG_PPC_BOOK3S=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y @@ -43,7 +44,7 @@ CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y -CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y @@ -52,12 +53,14 @@ CONFIG_OF=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_DTC=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_HIBERNATE_32=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set +CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # @@ -72,14 +75,24 @@ CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y +CONFIG_POSIX_MQUEUE_SYSCTL=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set + +# +# RCU Subsystem +# +CONFIG_CLASSIC_RCU=y +# CONFIG_TREE_RCU is not set +# CONFIG_PREEMPT_RCU is not set +# CONFIG_TREE_RCU_TRACE is not set +# CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 -# CONFIG_CGROUPS is not set # CONFIG_GROUP_SCHED is not set +# CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set @@ -88,23 +101,27 @@ CONFIG_NAMESPACES=y # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set +# CONFIG_NET_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= +CONFIG_RD_GZIP=y +CONFIG_RD_BZIP2=y +CONFIG_RD_LZMA=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set +# CONFIG_STRIP_ASM_SYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y -# CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y -CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y @@ -114,10 +131,12 @@ CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y +# CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y +CONFIG_TRACEPOINTS=y # CONFIG_MARKERS is not set CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y @@ -127,10 +146,10 @@ CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y +# CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y -# CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set @@ -138,11 +157,8 @@ CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set -CONFIG_KMOD=y CONFIG_BLOCK=y CONFIG_LBD=y -# CONFIG_BLK_DEV_IO_TRACE is not set -CONFIG_LSF=y CONFIG_BLK_DEV_BSG=y # CONFIG_BLK_DEV_INTEGRITY is not set @@ -158,14 +174,11 @@ CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory -CONFIG_CLASSIC_RCU=y CONFIG_FREEZER=y # # Platform support # -CONFIG_PPC_MULTIPLATFORM=y -CONFIG_CLASSIC32=y # CONFIG_PPC_CHRP is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set @@ -178,7 +191,9 @@ CONFIG_PPC_PMAC=y # CONFIG_PPC_83xx is not set # CONFIG_PPC_86xx is not set # CONFIG_EMBEDDED6xx is not set +# CONFIG_AMIGAONE is not set CONFIG_PPC_NATIVE=y +CONFIG_PPC_OF_BOOT_TRAMPOLINE=y # CONFIG_IPIC is not set CONFIG_MPIC=y # CONFIG_MPIC_WEIRD is not set @@ -212,11 +227,12 @@ CONFIG_CPU_FREQ_PMAC=y CONFIG_PPC601_SYNC_FIX=y # CONFIG_TAU is not set # CONFIG_FSL_ULI1575 is not set +# CONFIG_SIMPLE_GPIO is not set # # Kernel options # -# CONFIG_HIGHMEM is not set +CONFIG_HIGHMEM=y CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y @@ -239,6 +255,7 @@ CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ARCH_HAS_WALK_MEMORY=y
Re: [PATCH V3 3/4] Support for AC97 on Phytec pmc030 base board.
On Sun, May 24, 2009 at 7:38 PM, Jon Smirl jonsm...@gmail.com wrote:
Support for AC97 on Phytec pmc030 base board. A wm9712 AC97 codec is used.
Signed-off-by: Jon Smirl jonsm...@gmail.com
---
sound/soc/fsl/Kconfig | 7 +++
sound/soc/fsl/Makefile | 3 +
sound/soc/fsl/pcm030-audio-fabric.c | 95
+++
3 files changed, 105 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/fsl/pcm030-audio-fabric.c
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3bce952..79579ae 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -39,4 +39,11 @@ config SND_SOC_MPC5200_AC97
help
Say Y here to support the MPC5200 PSCs in AC97 mode.
+config SND_MPC52xx_SOC_PCM030
+ tristate SoC AC97 Audio support for Phytec pcm030 and WM9712
+ depends on PPC_MPC5200_SIMPLE
+ select SND_SOC_MPC5200_AC97
+ select SND_SOC_WM9712
+ help
+ Say Y if you want to add support for sound on the Phytec pcm030
baseboard.
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 14631a1..66d88c8 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -15,3 +15,6 @@ obj-$(CONFIG_SND_MPC52xx_DMA) += mpc5200_dma.o
obj-$(CONFIG_SND_SOC_MPC5200_I2S) += mpc5200_psc_i2s.o
obj-$(CONFIG_SND_SOC_MPC5200_AC97) += mpc5200_psc_ac97.o
+# MPC5200 Machine Support
+obj-$(CONFIG_SND_MPC52xx_SOC_PCM030) += pcm030-audio-fabric.o
+
diff --git a/sound/soc/fsl/pcm030-audio-fabric.c
b/sound/soc/fsl/pcm030-audio-fabric.c
new file mode 100644
index 000..2c426d5
--- /dev/null
+++ b/sound/soc/fsl/pcm030-audio-fabric.c
@@ -0,0 +1,95 @@
+/*
+ * Phytec pcm030 driver for the PSC of the Freescale MPC52xx
+ * configured as AC97 interface
+ *
+ * Copyright 2008 Jon Smirl, Digispeaker
+ * Author: Jon Smirl jonsm...@gmail.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/of_device.h
+#include linux/of_platform.h
+#include linux/dma-mapping.h
+
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/initval.h
+#include sound/soc.h
+#include sound/soc-of-simple.h
+
+#include mpc5200_dma.h
+#include mpc5200_psc_ac97.h
+#include ../codecs/wm9712.h
+
+static struct snd_soc_device device;
+static struct snd_soc_card card;
+
+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;
+}
This is ugly. I'd really rather have a generic mechanism for creating
a fabric driver based on the OF data. But failing that, it seems to
me that this platform device registration should be done in the
platform code (arch/powerpc/platforms/52xx). Doing it in a module
init looks wrong.
I was trying to do a sort of generic matching mechanism with the of
simple stuff; but admittedly it was hacky and half-assed. However, I
do still think it is viable to have OF hooks that kick in when codec
and machine drivers are registered. If linkage data is encoded in the
device tree, then generic code should be able to hook them up; pulling
additional data out of the device tree as needed to configure the
coded.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Initialize DBCR0 for PPC440 targets
On Mon, May 25, 2009 at 12:30 AM, srikanth krishnakar skrishna...@gmail.com wrote: Hello Grant, Is there any conclusion of the below discussion: http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html Xilinx target (virtex5) hangs (while running GDBServer KGDB) without the DBCR0 initialization. Can you please comment on this ? IIRC, John Linn was hacking on a patch. Search the mailing list archives for DBCR0. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE
On Sun, 2009-05-24 at 23:50 -0600, Grant Likely wrote: It would also be nice for comprehension if the file move and the modification were separate commits. As it is I had to generate the diff manually, but I'm not concerned. Right, I though about that... too late :-) might break it up tomorrow morning, I don't have time to fix that up right now. Hopefully Kumar and Ilya will manage to do the same you did to diff it :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Initialize DBCR0 for PPC440 targets
Hi John, I am not finding any conclusion of the plan to add DBCR0 initialization code to head_44x.S after this discussion : http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html#a23049044 Can you please comment ? Thanks, -Srikanth Krishnakar On Mon, May 25, 2009 at 12:09 PM, Grant Likely grant.lik...@secretlab.ca wrote: On Mon, May 25, 2009 at 12:30 AM, srikanth krishnakar skrishna...@gmail.com wrote: Hello Grant, Is there any conclusion of the below discussion: http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html Xilinx target (virtex5) hangs (while running GDBServer KGDB) without the DBCR0 initialization. Can you please comment on this ? IIRC, John Linn was hacking on a patch. Search the mailing list archives for DBCR0. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- The Good You Do, The Best You GET Regards Srikanth Krishnakar ** ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
On Sat, May 23, 2009 at 10:44 AM, Wolfgang Grandegger w...@grandegger.com wrote: Wolfgang Grandegger wrote: Grant Likely wrote: +- clock-frequency : CAN system clock frequency in Hz, which is normally + half of the oscillator clock frequency. If not specified, a + default value of 800 (8 MHz) is used. A clock-frequency property typically refers to the bus clock frequency. Something like can-frequency would be better. Ah, right, but I'm also not happy with can-frequency. The manual speaks about the internal clock, which is half of the external oscillator frequency. Maybe internal-clock-frequency might be better. Would it be better to specify the external clock frequency, and the driver know that internal freq is half that? I ask because external clock freq is a value the HW designer actually has control over. +- cdr-reg : value of the SJA1000 clock divider register according to + the SJA1000 data sheet. If not specified, a default value of + 0x48 is used. Ewh. The driver should be clueful enough to derive the clock divider value given both the bus and can frequencies. I don't like this property. The clock divider register controls the CLKOUT frequency for the microcontroller another CAN controller and allows to deactivate the CLKOUT pin. It's not used to configure the CAN bus frequency. +- ocr-reg : value of the SJA1000 output control register according to + the SJA1000 data sheet. If not specified, a default value of + 0x0a is used. Ditto here; the binding should describe the usage mode; not the register settings to get the usage mode. What sort of settings will the .dts author be writing here? Unfortunately, there are many: clkout-frequency bypass-comperator tx1-output-on-rx-irq #define OCR_MODE_BIPHASE 0x00 #define OCR_MODE_TEST 0x01 #define OCR_MODE_NORMAL 0x02 #define OCR_MODE_CLOCK 0x03 #define OCR_TX0_INVERT 0x04 #define OCR_TX0_PULLDOWN 0x08 #define OCR_TX0_PULLUP 0x10 #define OCR_TX0_PUSHPULL 0x18 #define OCR_TX1_INVERT 0x20 #define OCR_TX1_PULLDOWN 0x40 #define OCR_TX1_PULLUP 0x80 #define OCR_TX1_PUSHPULL 0xc0 I think implementing properties for each option is overkill. Ugh, I see what you mean. Would the following more descriptive properties be OK? clock-out-frequency = 0, // CLKOUT pin clock off = 400; // frequency on CLKOUT pin Or how about CLKOUT pin off if the property isn't present? Otherwise, this looks okay. BTW, I'd consider prefixing this with 'nxp,' or 'sja1000,' to protect the namespace. clock-out-frequency sounds like one of those names which could be commonly used in the future. I'd so the same for the other chip-specific properties too. Segher, what's your opinion on this? bypass-input-comparator; // allows to bypass the CAN input comparator. tx1-output-on-rx-irq; // allows the TX1 output to be used as a // dedicated RX interrupt output. output-control-mode = 0x0 // bi-phase output mode 0x1 // test output mode 0x2 // normal output mode (default) 0x3 // clock output mode output-pin-config = 0x01 // TX0 invert 0x02 // TX0 pull-down 0x04 // TX0 pull-up 0x06 // TX0 push-pull 0x08 // TX1 invert 0x10 // TX1 pull-down 0x20 // TX1 pull-up 0x30 // TX1 push-pull hmmm; It is very chip specific and it is a lot of mucking around. If you prefix the property with the manufacturer name, then perhaps the explicit register setting is okay. Are TX0 TX1 protocol pins or GPIOs? If gpio, then maybe it is worth the mucking about to then use the gpios binding to specify the pin mode. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
Arnd Bergmann wrote: 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. Is that common practice? If yes, I will add a member to store the virtual address to struct sja1000_priv. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Initialize DBCR0 for PPC440 targets
Hello Grant, Is there any conclusion of the below discussion: http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html Xilinx target (virtex5) hangs (while running GDBServer KGDB) without the DBCR0 initialization. Can you please comment on this ? Thanks, -Srikanth On Wed, May 20, 2009 at 11:20 AM, srikanth krishnakar skrishna...@gmail.com wrote: Hi David, I am not sure how the IDM behaves on few of PPC440 targets which don't have boot loaders. I have a reference for your question: http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html Without this fix (given patch) I am facing problems with GDB, and further target hangs while running gdbserver ! Thanks, Srikanth On Wed, May 20, 2009 at 5:23 AM, David Gibson da...@gibson.dropbear.id.au wrote: On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote: Hi, kernel- 2.6.29 Debug technique: KGDB The PowerPC kernel does not initialize the PPC440 DBCR0 register. This prevents the use of software breakpoints in case of internal debug mode. Looking into head_fsl_booke.S for initialization of DBCR0 is used by boot-loaders. It seems head_44x.S lacks this step of DBCR0 register initialization. So fixing this with initializing the DBCR0 register as shown below : Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not having bootloader The kernel does not initialize the PPC440 DBCR0 register. This prevents (among other things) the use of software breakpoints with GDB. The boot loaders probably do initialize this but few targets run without a boot loader Um.. how does this prevent the use of software breakpoints with gdb? The trap instructions still work with IDM==0. -- 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 -- The Good You Do, The Best You GET Regards Srikanth Krishnakar ** -- The Good You Do, The Best You GET Regards Srikanth Krishnakar ** ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Initialize DBCR0 for PPC440 targets
On Wed, 2009-05-20 at 16:00 +1000, David Gibson wrote: On Wed, May 20, 2009 at 11:20:46AM +0530, srikanth krishnakar wrote: Hi David, I am not sure how the IDM behaves on few of PPC440 targets which don't have boot loaders. I have a reference for your question: http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html Without this fix (given patch) I am facing problems with GDB, and further target hangs while running gdbserver ! That doesn't answer my question. It's not enough to say this fixes a problem you need to explain *how* it fixes the problem. And I don't see why IDM would have any effect on *software* breakpoints. No but gdb can use the DABR emulation and single step would be busted too. GDB internally heavily uses single step in places you wouldn't expect it to :-) Like I think when breaking on main, it sometimes single step the whole init process of the executable until it hits it. At least I've seen it do that when I was debugging the debug support for 64-bit Book3E. Cheers, Ben. On Wed, May 20, 2009 at 5:23 AM, David Gibson da...@gibson.dropbear.id.au wrote: On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote: Hi, kernel- 2.6.29 Debug technique: KGDB The PowerPC kernel does not initialize the PPC440 DBCR0 register. This prevents the use of software breakpoints in case of internal debug mode. Looking into head_fsl_booke.S for initialization of DBCR0 is used by boot-loaders. It seems head_44x.S lacks this step of DBCR0 register initialization. So fixing this with initializing the DBCR0 register as shown below : Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not having bootloader The kernel does not initialize the PPC440 DBCR0 register. This prevents (among other things) the use of software breakpoints with GDB. The boot loaders probably do initialize this but few targets run without a boot loader Um.. how does this prevent the use of software breakpoints with gdb? The trap instructions still work with IDM==0. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
Grant Likely wrote: On Sat, May 23, 2009 at 10:44 AM, Wolfgang Grandegger w...@grandegger.com wrote: Wolfgang Grandegger wrote: Grant Likely wrote: +- clock-frequency : CAN system clock frequency in Hz, which is normally + half of the oscillator clock frequency. If not specified, a + default value of 800 (8 MHz) is used. A clock-frequency property typically refers to the bus clock frequency. Something like can-frequency would be better. Ah, right, but I'm also not happy with can-frequency. The manual speaks about the internal clock, which is half of the external oscillator frequency. Maybe internal-clock-frequency might be better. Would it be better to specify the external clock frequency, and the driver know that internal freq is half that? I ask because external clock freq is a value the HW designer actually has control over. I'm sharing your arguments: external-clock-frequency. There is always some confusion about external and internal clock frequency but the name should make it clear. +- cdr-reg : value of the SJA1000 clock divider register according to + the SJA1000 data sheet. If not specified, a default value of + 0x48 is used. Ewh. The driver should be clueful enough to derive the clock divider value given both the bus and can frequencies. I don't like this property. The clock divider register controls the CLKOUT frequency for the microcontroller another CAN controller and allows to deactivate the CLKOUT pin. It's not used to configure the CAN bus frequency. +- ocr-reg : value of the SJA1000 output control register according to + the SJA1000 data sheet. If not specified, a default value of + 0x0a is used. Ditto here; the binding should describe the usage mode; not the register settings to get the usage mode. What sort of settings will the .dts author be writing here? Unfortunately, there are many: clkout-frequency bypass-comperator tx1-output-on-rx-irq #define OCR_MODE_BIPHASE 0x00 #define OCR_MODE_TEST 0x01 #define OCR_MODE_NORMAL 0x02 #define OCR_MODE_CLOCK0x03 #define OCR_TX0_INVERT0x04 #define OCR_TX0_PULLDOWN 0x08 #define OCR_TX0_PULLUP0x10 #define OCR_TX0_PUSHPULL 0x18 #define OCR_TX1_INVERT0x20 #define OCR_TX1_PULLDOWN 0x40 #define OCR_TX1_PULLUP0x80 #define OCR_TX1_PUSHPULL 0xc0 I think implementing properties for each option is overkill. Ugh, I see what you mean. Would the following more descriptive properties be OK? clock-out-frequency = 0, // CLKOUT pin clock off = 400; // frequency on CLKOUT pin Or how about CLKOUT pin off if the property isn't present? Otherwise, Yep, that will be the default anyhow. this looks okay. BTW, I'd consider prefixing this with 'nxp,' or 'sja1000,' to protect the namespace. clock-out-frequency sounds like one of those names which could be commonly used in the future. I'd so the same for the other chip-specific properties too. Segher, what's your opinion on this? I personally don't have a real preference. bypass-input-comparator; // allows to bypass the CAN input comparator. tx1-output-on-rx-irq;// allows the TX1 output to be used as a // dedicated RX interrupt output. output-control-mode = 0x0 // bi-phase output mode 0x1 // test output mode 0x2 // normal output mode (default) 0x3 // clock output mode output-pin-config = 0x01 // TX0 invert 0x02 // TX0 pull-down 0x04 // TX0 pull-up 0x06 // TX0 push-pull 0x08 // TX1 invert 0x10 // TX1 pull-down 0x20 // TX1 pull-up 0x30 // TX1 push-pull hmmm; It is very chip specific and it is a lot of mucking around. If you prefix the property with the manufacturer name, then perhaps the explicit register setting is okay. OK. Are TX0 TX1 protocol pins or GPIOs? If gpio, then maybe it is worth the mucking about to then use the gpios binding to specify the pin mode. These are the output from the CAN output driver 0 or 1 to the physical bus line. E.g., in normal output mode the CAN bit sequence is sent via TX0 or TX1. From a non-hardware expert point of view, they must be programmed properly to get the hardware to work. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V3 1/4] Main rewite of the mpc5200 audio DMA code
On Mon, May 25, 2009 at 12:26:27AM -0600, Grant Likely wrote: On Sun, May 24, 2009 at 7:38 PM, Jon Smirl jonsm...@gmail.com wrote: +/* - + * Sysfs attributes for error monitoring + */ All this sysfs stuff should be dropped from this patch. It is an abuse of sysfs and I never should have written it this way. Feel free to put it in a separate patch so others can use it if they really need it, but I'd like it to not be kept in mainline. If this is going to be kept it should be in debugfs like I said in response to the v2 posting. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V3 3/4] Support for AC97 on Phytec pmc030 base board.
On Mon, May 25, 2009 at 12:34:57AM -0600, Grant Likely wrote: This is ugly. I'd really rather have a generic mechanism for creating a fabric driver based on the OF data. But failing that, it seems to me that this platform device registration should be done in the platform code (arch/powerpc/platforms/52xx). Doing it in a module init looks wrong. It's ugly but it's idiomatic for ASoC until someone has time to implement multiple card support. I was trying to do a sort of generic matching mechanism with the of simple stuff; but admittedly it was hacky and half-assed. However, I It's adequate for the cases it tries to cover, it just needs to be merged into the core. The problem here is AC97 since it can't be probed until the platform comes up. do still think it is viable to have OF hooks that kick in when codec and machine drivers are registered. If linkage data is encoded in the device tree, then generic code should be able to hook them up; pulling additional data out of the device tree as needed to configure the coded. As I explained in response to Jon's original posting AC97 is a particular problem here since it can only be probed using the CPU DAI and may require machine-specific work to set it up prior to use. There's problems fixing this due to AC97 not having fully developed bus infrastructure in the kernel at the minute. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V3 3/4] Support for AC97 on Phytec pmc030 base board.
On Sun, May 24, 2009 at 09:38:51PM -0400, Jon Smirl wrote:
+static __exit void pcm030_fabric_exit(void)
+{
+}
Remove or implement, please.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V3 2/4] AC97 driver for mpc5200
On Sun, May 24, 2009 at 09:38:49PM -0400, Jon Smirl wrote:
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.
This smells like either a very broken board or some issue with starting
the master clock for the CODEC - if the CODEC is clocked by the AC97
controller you may need to do something to ensure that it has finished
starting up before initiating the reset.
+static int psc_ac97_cold_reset_check(struct snd_ac97 *ac97)
+{
+ int max_reset, timeout;
+ struct mpc52xx_psc __iomem *regs = psc_dma-psc_regs;
+
+ /* AC97 clock is generated by the codec.
+ * Ensure that it starts ticking after codec reset.
+ */
The AC97 standard allows CODECs to come out of cold reset with the link
disabled. With those CODECs this is going fail every time - they need a
warm reset to come on-line.
If this really is a general issue with the AC97 controller here you'll
need to do a warm reset in here. It's not ideal but extra warm resets
will cause less harm than completely failing to come on-line.
+static int psc_ac97_trigger(struct snd_pcm_substream *substream, int cmd,
+ struct snd_soc_dai *dai)
I keep mentioning the indentation issues with your code without seeing
any response from you. If you run checkpatch over your code you'll also
see a bunch of complaints about using spaces instead of tabs for
indentation. It looks for all the world like you're using 4 character
tabs instead of the 8 character tabs which are the kernel standard.
+
+ switch (cmd) {
+ case SNDRV_PCM_TRIGGER_STOP:
+ if (substream-pstr-stream == SNDRV_PCM_STREAM_CAPTURE)
+ psc_dma-slots = 0x;
+ else
+ psc_dma-slots = 0x;
+
+ spin_lock(psc_dma-lock);
+ out_be32(psc_dma-psc_regs-ac97_slots, psc_dma-slots);
+ spin_unlock(psc_dma-lock);
+ break;
This locking looks wrong - I'd expect it to also cover the modification
of psc_dma-slots? Otherwise it's hard to see what it buys you.
+ /* AC97 clock is generated by the codec.
+ * Ensure that it starts ticking after codec reset.
+ */
+ rc = psc_ac97_cold_reset_check(ac97);
+ if (rc != 0) {
+ dev_err(op-dev, AC97 codec failed to reset\n);
+ mpc5200_audio_dma_destroy(op);
+ return rc;
+ }
Your AC97 driver should not be doing this - leave it to the card and
CODEC driver to bring things on line.
+
+ /* Go */
+ out_8(regs-command, MPC52xx_PSC_TX_ENABLE | MPC52xx_PSC_RX_ENABLE);
As I said last time I'd expect this to be deferred to the ASoC device
probe.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V3 0/4] mpc5200 audio rework for AC97
On Sun, May 24, 2009 at 09:38:45PM -0400, Jon Smirl wrote: 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. Please also add the fixes for the reset code in the CODEC driver that I asked for. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH resend4 2/3] itimers: fix periodic tics precision
On Mon, 25 May 2009, Stanislaw Gruszka wrote: @@ -904,6 +905,7 @@ void __init time_init(void) tb_ticks_per_usec = ppc_tb_freq / 100; tb_to_us = mulhwu_scale_factor(ppc_tb_freq, 100); calc_cputime_factors(); + cputime_one = jiffies_to_cputime(1); 1) The variable name is misleading. 2) The patch breaks all powerpc platforms which have CONFIG_VIRT_CPU_ACCOUNTING=n and ia64 with CONFIG_VIRT_CPU_ACCOUNTING=y Thanks, tglx ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V3 1/4] Main rewite of the mpc5200 audio DMA code
On Mon, May 25, 2009 at 3:34 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Mon, May 25, 2009 at 12:26:27AM -0600, Grant Likely wrote: On Sun, May 24, 2009 at 7:38 PM, Jon Smirl jonsm...@gmail.com wrote: +/* - + * Sysfs attributes for error monitoring + */ All this sysfs stuff should be dropped from this patch. It is an abuse of sysfs and I never should have written it this way. Feel free to put it in a separate patch so others can use it if they really need it, but I'd like it to not be kept in mainline. If this is going to be kept it should be in debugfs like I said in response to the v2 posting. exactly. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 405ex memory size issue
Have you modified the hardware? The default hardware specs says there is only 256MB of ram. Regardless, if you upped the ram amount, you might need to modify u-boot itself to turn on more address lines or you might consider looking at your memory management allocation (slab, slub, etc). Hunter Cobbs On May 25, 2009, at 1:15 AM, konamo dai.mich...@gmail.com wrote: any ideas? konamo wrote: Hi all, we are using AMCC 405ex kilauea eval board as a demo, not use any pci/nand function, the board configuration is below: u-boot 2009.01, linux-2.6.25-rc2, 1GB DDR2 memory(2Gbit * 4, 1 rank), AMCC powerpc 405ex, both 1G and 512MB memory works fine under u-boot, but linux boot fails in 1G memory, if we limit mem=512M, linux could boot over nfs. Could anyone pls help us how to find the root cause? thanks -- View this message in context: http://www.nabble.com/AMCC-405ex-memory-size-issue-tp23631525p23701685.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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V3 3/4] Support for AC97 on Phytec pmc030 base board.
On Mon, May 25, 2009 at 2:34 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Sun, May 24, 2009 at 7:38 PM, Jon Smirl jonsm...@gmail.com wrote: This is ugly. I'd really rather have a generic mechanism for creating a fabric driver based on the OF data. But failing that, it seems to me that this platform device registration should be done in the platform code (arch/powerpc/platforms/52xx). Doing it in a module init looks wrong. I'm all for deleting it as soon as AC97 is capable of auto-loading. I thought it was better to leave it in the sound directories to keep it isolated since the intention is to remove it when possible. BTW, my binding files are quite simple compared to mpc8610_hpcd.c. I was trying to do a sort of generic matching mechanism with the of simple stuff; but admittedly it was hacky and half-assed. However, I do still think it is viable to have OF hooks that kick in when codec and machine drivers are registered. If linkage data is encoded in the device tree, then generic code should be able to hook them up; pulling additional data out of the device tree as needed to configure the coded. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- Jon Smirl jonsm...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v5 0/4] Series short description
Repost of ml510 series. This time against 2.6.30-rc7 and with the .dts file included. g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v5 3/4] powerpc/virtex: Add Xilinx ML510 reference design support
From: Roderick Colenbrander thunderbir...@gmail.com
Signed-off-by: Roderick Colenbrander thunderbir...@gmail.com
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/platforms/44x/Kconfig| 13 -
arch/powerpc/platforms/44x/Makefile |1 +
arch/powerpc/platforms/44x/virtex_ml510.c | 29 +
arch/powerpc/sysdev/xilinx_intc.c |5 +
4 files changed, 47 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index 0d83a6a..90e3192 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -156,7 +156,7 @@ config YOSEMITE
#This option enables support for the IBM PPC440GX evaluation board.
config XILINX_VIRTEX440_GENERIC_BOARD
- bool Generic Xilinx Virtex 440 board
+ bool Generic Xilinx Virtex 5 FXT board support
depends on 44x
default n
select XILINX_VIRTEX_5_FXT
@@ -171,6 +171,17 @@ config XILINX_VIRTEX440_GENERIC_BOARD
Most Virtex 5 designs should use this unless it needs to do some
special configuration at board probe time.
+config XILINX_ML510
+ bool Xilinx ML510 extra support
+ depends on XILINX_VIRTEX440_GENERIC_BOARD
+ select PPC_PCI_CHOICE
+ select XILINX_PCI if PCI
+ select PPC_INDIRECT_PCI if PCI
+ select PPC_I8259 if PCI
+ help
+ This option enables extra support for features on the Xilinx ML510
+ board. The ML510 has a PCI bus with ALI south bridge.
+
config PPC44x_SIMPLE
bool Simple PowerPC 44x board support
depends on 44x
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index 01f51da..ee6185a 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
+obj-$(CONFIG_XILINX_ML510) += virtex_ml510.o
diff --git a/arch/powerpc/platforms/44x/virtex_ml510.c
b/arch/powerpc/platforms/44x/virtex_ml510.c
new file mode 100644
index 000..ba4a6e3
--- /dev/null
+++ b/arch/powerpc/platforms/44x/virtex_ml510.c
@@ -0,0 +1,29 @@
+#include asm/i8259.h
+#include linux/pci.h
+#include 44x.h
+
+/**
+ * ml510_ail_quirk
+ */
+static void __devinit ml510_ali_quirk(struct pci_dev *dev)
+{
+ /* Enable the IDE controller */
+ pci_write_config_byte(dev, 0x58, 0x4c);
+ /* Assign irq 14 to the primary ide channel */
+ pci_write_config_byte(dev, 0x44, 0x0d);
+ /* Assign irq 15 to the secondary ide channel */
+ pci_write_config_byte(dev, 0x75, 0x0f);
+ /* Set the ide controller in native mode */
+ pci_write_config_byte(dev, 0x09, 0xff);
+
+ /* INTB = disabled, INTA = disabled */
+ pci_write_config_byte(dev, 0x48, 0x00);
+ /* INTD = disabled, INTC = disabled */
+ pci_write_config_byte(dev, 0x4a, 0x00);
+ /* Audio = INT7, Modem = disabled. */
+ pci_write_config_byte(dev, 0x4b, 0x60);
+ /* USB = INT7 */
+ pci_write_config_byte(dev, 0x74, 0x06);
+}
+DECLARE_PCI_FIXUP_EARLY(0x10b9, 0x1533, ml510_ali_quirk);
+
diff --git a/arch/powerpc/sysdev/xilinx_intc.c
b/arch/powerpc/sysdev/xilinx_intc.c
index 90b5772..3ee1fd3 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -257,6 +257,11 @@ static void __init xilinx_i8259_setup_cascade(void)
i8259_init(cascade_node, 0);
set_irq_chained_handler(cascade_irq, xilinx_i8259_cascade);
+ /* Program irq 7 (usb/audio), 14/15 (ide) to level sensitive */
+ /* This looks like a dirty hack to me --gcl */
+ outb(0xc0, 0x4d0);
+ outb(0xc0, 0x4d1);
+
out:
of_node_put(cascade_node);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v5 4/4] powerpc/virtex: Add ml510 reference design device tree
From: Roderick Colenbrander thunderbir...@gmail.com
As subject says, add dts files for Xilinx ML510 reference design with
the PCI host bridge device.
Signed-off-by: Roderick Colenbrander thunderbir...@gmail.com
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/boot/dts/virtex440-ml510.dts | 465 +
1 files changed, 465 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
diff --git a/arch/powerpc/boot/dts/virtex440-ml510.dts
b/arch/powerpc/boot/dts/virtex440-ml510.dts
new file mode 100644
index 000..81a8dc2
--- /dev/null
+++ b/arch/powerpc/boot/dts/virtex440-ml510.dts
@@ -0,0 +1,465 @@
+/*
+ * Xilinx ML510 Reference Design support
+ *
+ * This DTS file was created for the ml510_bsb1_pcores_ppc440 reference design.
+ * The reference design contains a bug which prevent PCI DMA from working
+ * properly. A description of the bug is given in the plbv46_pci section. It
+ * needs to be fixed by the user until Xilinx updates their reference design.
+ *
+ * Copyright 2009, Roderick Colenbrander
+ */
+
+/dts-v1/;
+/ {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = xlnx,ml510-ref-design, xlnx,virtex440;
+ dcr-parent = ppc440_0;
+ DDR2_SDRAM_DIMM0: mem...@0 {
+ device_type = memory;
+ reg = 0x0 0x2000 ;
+ } ;
+ alias {
+ ethernet0 = Hard_Ethernet_MAC;
+ serial0 = RS232_Uart_1;
+ } ;
+ chosen {
+ bootargs = console=ttyS0 root=/dev/ram;
+ linux,stdout-path = /p...@0/ser...@83e0;
+ } ;
+ cpus {
+ #address-cells = 1;
+ #cpus = 0x1;
+ #size-cells = 0;
+ ppc440_0: c...@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ clock-frequency = 3;
+ compatible = PowerPC,440, ibm,ppc440;
+ d-cache-line-size = 0x20;
+ d-cache-size = 0x8000;
+ dcr-access-method = native;
+ dcr-controller ;
+ device_type = cpu;
+ i-cache-line-size = 0x20;
+ i-cache-size = 0x8000;
+ model = PowerPC,440;
+ reg = 0;
+ timebase-frequency = 3;
+ xlnx,apu-control = 0x2000;
+ xlnx,apu-udi-0 = 0x0;
+ xlnx,apu-udi-1 = 0x0;
+ xlnx,apu-udi-10 = 0x0;
+ xlnx,apu-udi-11 = 0x0;
+ xlnx,apu-udi-12 = 0x0;
+ xlnx,apu-udi-13 = 0x0;
+ xlnx,apu-udi-14 = 0x0;
+ xlnx,apu-udi-15 = 0x0;
+ xlnx,apu-udi-2 = 0x0;
+ xlnx,apu-udi-3 = 0x0;
+ xlnx,apu-udi-4 = 0x0;
+ xlnx,apu-udi-5 = 0x0;
+ xlnx,apu-udi-6 = 0x0;
+ xlnx,apu-udi-7 = 0x0;
+ xlnx,apu-udi-8 = 0x0;
+ xlnx,apu-udi-9 = 0x0;
+ xlnx,dcr-autolock-enable = 0x1;
+ xlnx,dcu-rd-ld-cache-plb-prio = 0x0;
+ xlnx,dcu-rd-noncache-plb-prio = 0x0;
+ xlnx,dcu-rd-touch-plb-prio = 0x0;
+ xlnx,dcu-rd-urgent-plb-prio = 0x0;
+ xlnx,dcu-wr-flush-plb-prio = 0x0;
+ xlnx,dcu-wr-store-plb-prio = 0x0;
+ xlnx,dcu-wr-urgent-plb-prio = 0x0;
+ xlnx,dma0-control = 0x0;
+ xlnx,dma0-plb-prio = 0x0;
+ xlnx,dma0-rxchannelctrl = 0x101;
+ xlnx,dma0-rxirqtimer = 0x3ff;
+ xlnx,dma0-txchannelctrl = 0x101;
+ xlnx,dma0-txirqtimer = 0x3ff;
+ xlnx,dma1-control = 0x0;
+ xlnx,dma1-plb-prio = 0x0;
+ xlnx,dma1-rxchannelctrl = 0x101;
+ xlnx,dma1-rxirqtimer = 0x3ff;
+ xlnx,dma1-txchannelctrl = 0x101;
+ xlnx,dma1-txirqtimer = 0x3ff;
+ xlnx,dma2-control = 0x0;
+ xlnx,dma2-plb-prio = 0x0;
+ xlnx,dma2-rxchannelctrl = 0x101;
+ xlnx,dma2-rxirqtimer = 0x3ff;
+ xlnx,dma2-txchannelctrl = 0x101;
+ xlnx,dma2-txirqtimer = 0x3ff;
+ xlnx,dma3-control = 0x0;
+ xlnx,dma3-plb-prio = 0x0;
+ xlnx,dma3-rxchannelctrl = 0x101;
+ xlnx,dma3-rxirqtimer = 0x3ff;
+ xlnx,dma3-txchannelctrl = 0x101;
+
[PATCH v5 1/4] powerpc/virtex: Add support for Xilinx PCI host bridge
From: Roderick Colenbrander thunderbir...@gmail.com
This patch adds support for the Xilinx plbv46-pci-1.03.a PCI host
bridge IPcore.
Signed-off-by: Roderick Colenbrander thunderbir...@gmail.com
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/include/asm/xilinx_pci.h | 21 +
arch/powerpc/platforms/40x/virtex.c |2 +
arch/powerpc/platforms/44x/virtex.c |2 +
arch/powerpc/platforms/Kconfig|4 +
arch/powerpc/sysdev/Makefile |1
arch/powerpc/sysdev/xilinx_pci.c | 132 +
6 files changed, 162 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/xilinx_pci.h
create mode 100644 arch/powerpc/sysdev/xilinx_pci.c
diff --git a/arch/powerpc/include/asm/xilinx_pci.h
b/arch/powerpc/include/asm/xilinx_pci.h
new file mode 100644
index 000..7a8275c
--- /dev/null
+++ b/arch/powerpc/include/asm/xilinx_pci.h
@@ -0,0 +1,21 @@
+/*
+ * Xilinx pci external definitions
+ *
+ * Copyright 2009 Roderick Colenbrander
+ * Copyright 2009 Secret Lab Technologies Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#ifndef INCLUDE_XILINX_PCI
+#define INCLUDE_XILINX_PCI
+
+#ifdef CONFIG_XILINX_PCI
+extern void __init xilinx_pci_init(void);
+#else
+static inline void __init xilinx_pci_init(void) { return; }
+#endif
+
+#endif /* INCLUDE_XILINX_PCI */
diff --git a/arch/powerpc/platforms/40x/virtex.c
b/arch/powerpc/platforms/40x/virtex.c
index fc7fb00..d0fc686 100644
--- a/arch/powerpc/platforms/40x/virtex.c
+++ b/arch/powerpc/platforms/40x/virtex.c
@@ -14,6 +14,7 @@
#include asm/prom.h
#include asm/time.h
#include asm/xilinx_intc.h
+#include asm/xilinx_pci.h
#include asm/ppc4xx.h
static struct of_device_id xilinx_of_bus_ids[] __initdata = {
@@ -47,6 +48,7 @@ static int __init virtex_probe(void)
define_machine(virtex) {
.name = Xilinx Virtex,
.probe = virtex_probe,
+ .setup_arch = xilinx_pci_init,
.init_IRQ = xilinx_intc_init_tree,
.get_irq= xilinx_intc_get_irq,
.restart= ppc4xx_reset_system,
diff --git a/arch/powerpc/platforms/44x/virtex.c
b/arch/powerpc/platforms/44x/virtex.c
index 68637fa..cf96cca 100644
--- a/arch/powerpc/platforms/44x/virtex.c
+++ b/arch/powerpc/platforms/44x/virtex.c
@@ -16,6 +16,7 @@
#include asm/prom.h
#include asm/time.h
#include asm/xilinx_intc.h
+#include asm/xilinx_pci.h
#include asm/reg.h
#include asm/ppc4xx.h
#include 44x.h
@@ -53,6 +54,7 @@ static int __init virtex_probe(void)
define_machine(virtex) {
.name = Xilinx Virtex440,
.probe = virtex_probe,
+ .setup_arch = xilinx_pci_init,
.init_IRQ = xilinx_intc_init_tree,
.get_irq= xilinx_intc_get_irq,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index e3e8707..04a8061 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -329,4 +329,8 @@ config MCU_MPC8349EMITX
also register MCU GPIOs with the generic GPIO API, so you'll able
to use MCU pins as GPIOs.
+config XILINX_PCI
+ bool Xilinx PCI host bridge support
+ depends on PCI XILINX_VIRTEX
+
endmenu
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index b33b28a..2d1c87d 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_IPIC)+= ipic.o
obj-$(CONFIG_4xx) += uic.o
obj-$(CONFIG_4xx_SOC) += ppc4xx_soc.o
obj-$(CONFIG_XILINX_VIRTEX)+= xilinx_intc.o
+obj-$(CONFIG_XILINX_PCI) += xilinx_pci.o
obj-$(CONFIG_OF_RTC) += of_rtc.o
ifeq ($(CONFIG_PCI),y)
obj-$(CONFIG_4xx) += ppc4xx_pci.o
diff --git a/arch/powerpc/sysdev/xilinx_pci.c b/arch/powerpc/sysdev/xilinx_pci.c
new file mode 100644
index 000..1453b0e
--- /dev/null
+++ b/arch/powerpc/sysdev/xilinx_pci.c
@@ -0,0 +1,132 @@
+/*
+ * PCI support for Xilinx plbv46_pci soft-core which can be used on
+ * Xilinx Virtex ML410 / ML510 boards.
+ *
+ * Copyright 2009 Roderick Colenbrander
+ * Copyright 2009 Secret Lab Technologies Ltd.
+ *
+ * The pci bridge fixup code was copied from ppc4xx_pci.c and was written
+ * by Benjamin Herrenschmidt.
+ * Copyright 2007 Ben. Herrenschmidt b...@kernel.crashing.org, IBM Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include linux/ioport.h
+#include linux/of.h
+#include linux/pci.h
+#include mm/mmu_decl.h
+#include asm/io.h
+#include
[PATCH v5 2/4] powerpc/virtex: refactor intc driver and add support for i8259 cascading
From: Grant Likely grant.lik...@secretlab.ca
This patch refactors some of the xilinx_intc interrupt controller driver
and adds support for cascading an i8259 off one of the irq lines.
This patch was based on the ML510 support work done by Roderick
Colenbrander.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/sysdev/xilinx_intc.c | 76 -
1 files changed, 58 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/sysdev/xilinx_intc.c
b/arch/powerpc/sysdev/xilinx_intc.c
index c658b41..90b5772 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -25,6 +25,7 @@
#include linux/of.h
#include asm/io.h
#include asm/processor.h
+#include asm/i8259.h
#include asm/irq.h
/*
@@ -191,20 +192,14 @@ struct irq_host * __init
xilinx_intc_init(struct device_node *np)
{
struct irq_host * irq;
- struct resource res;
void * regs;
- int rc;
/* Find and map the intc registers */
- rc = of_address_to_resource(np, 0, res);
- if (rc) {
- printk(KERN_ERR __FILE__ : of_address_to_resource() failed\n);
+ regs = of_iomap(np, 0);
+ if (!regs) {
+ pr_err(xilinx_intc: could not map registers\n);
return NULL;
}
- regs = ioremap(res.start, 32);
-
- printk(KERN_INFO Xilinx intc at 0x%08llx mapped to 0x%p\n,
- (unsigned long long) res.start, regs);
/* Setup interrupt controller */
out_be32(regs + XINTC_IER, 0); /* disable all irqs */
@@ -217,6 +212,7 @@ xilinx_intc_init(struct device_node *np)
if (!irq)
panic(__FILE__ : Cannot allocate IRQ host\n);
irq-host_data = regs;
+
return irq;
}
@@ -227,23 +223,65 @@ int xilinx_intc_get_irq(void)
return irq_linear_revmap(master_irqhost, in_be32(regs + XINTC_IVR));
}
+#if defined(CONFIG_PPC_I8259)
+/*
+ * Support code for cascading to 8259 interrupt controllers
+ */
+static void xilinx_i8259_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned int cascade_irq = i8259_irq();
+ if (cascade_irq)
+ generic_handle_irq(cascade_irq);
+
+ /* Let xilinx_intc end the interrupt */
+ desc-chip-ack(irq);
+ desc-chip-unmask(irq);
+}
+
+static void __init xilinx_i8259_setup_cascade(void)
+{
+ struct device_node *cascade_node;
+ int cascade_irq;
+
+ /* Initialize i8259 controller */
+ cascade_node = of_find_compatible_node(NULL, NULL, chrp,iic);
+ if (!cascade_node)
+ return;
+
+ cascade_irq = irq_of_parse_and_map(cascade_node, 0);
+ if (!cascade_irq) {
+ pr_err(virtex_ml510: Failed to map cascade interrupt\n);
+ goto out;
+ }
+
+ i8259_init(cascade_node, 0);
+ set_irq_chained_handler(cascade_irq, xilinx_i8259_cascade);
+
+ out:
+ of_node_put(cascade_node);
+}
+#else
+static inline void xilinx_i8259_setup_cascade(void) { return; }
+#endif /* defined(CONFIG_PPC_I8259) */
+
+static struct of_device_id xilinx_intc_match[] __initconst = {
+ { .compatible = xlnx,opb-intc-1.00.c, },
+ { .compatible = xlnx,xps-intc-1.00.a, },
+ {}
+};
+
+/*
+ * Initialize master Xilinx interrupt controller
+ */
void __init xilinx_intc_init_tree(void)
{
struct device_node *np;
/* find top level interrupt controller */
- for_each_compatible_node(np, NULL, xlnx,opb-intc-1.00.c) {
+ for_each_matching_node(np, xilinx_intc_match) {
if (!of_get_property(np, interrupts, NULL))
break;
}
- if (!np) {
- for_each_compatible_node(np, NULL, xlnx,xps-intc-1.00.a) {
- if (!of_get_property(np, interrupts, NULL))
- break;
- }
- }
-
- /* xilinx interrupt controller needs to be top level */
BUG_ON(!np);
master_irqhost = xilinx_intc_init(np);
@@ -251,4 +289,6 @@ void __init xilinx_intc_init_tree(void)
irq_set_default_host(master_irqhost);
of_node_put(np);
+
+ xilinx_i8259_setup_cascade();
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH resend4 2/3] itimers: fix periodic tics precision
(linuxppc-dev CC added)
On Fri, 22 May 2009 16:27:40 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
if (cputime_ge(cur_time, it-expires)) {
- it-expires = it-incr;
- if (!cputime_eq(it-expires, cputime_zero))
- it-expires = cputime_add(it-expires, cur_time);
+ if (!cputime_eq(it-incr, cputime_zero)) {
+ it-expires = cputime_add(it-expires, it-incr);
+ it-error += it-incr_error;
+ if (it-error = onecputick) {
+ it-expires = cputime_sub(it-expires,
+ jiffies_to_cputime(1));
+ it-error -= onecputick;
+ }
Yep, that's a sane solution except for jiffies_to_cputime(), which
can be precomputed as well.
I think precomputed is only needed for PPC where jiffies_to_cputime(1) is not
compile time constant. To not affect other architectures, I wrote a patch with
cputime_one value, it is global variable for PPC and preprocessor definition
for others. This patch is against current Linus' tree. I send it as RFC, it
was only compile tested for x86.
diff --git a/arch/ia64/include/asm/cputime.h b/arch/ia64/include/asm/cputime.h
index d20b998..df88b07 100644
--- a/arch/ia64/include/asm/cputime.h
+++ b/arch/ia64/include/asm/cputime.h
@@ -30,6 +30,7 @@ typedef u64 cputime_t;
typedef u64 cputime64_t;
#define cputime_zero ((cputime_t)0)
+#define cputime_onejiffies_to_cputime(1)
#define cputime_max((~((cputime_t)0) 1) - 1)
#define cputime_add(__a, __b) ((__a) + (__b))
#define cputime_sub(__a, __b) ((__a) - (__b))
diff --git a/arch/powerpc/include/asm/cputime.h
b/arch/powerpc/include/asm/cputime.h
index f42e623..e57f951 100644
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
@@ -48,6 +48,8 @@ typedef u64 cputime64_t;
#ifdef __KERNEL__
+extern cputime_t cputime_one;
+
/*
* Convert cputime - jiffies
*/
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 48571ac..e46e210 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -498,6 +498,7 @@ static int __init iSeries_tb_recal(void)
tb_to_xs = divres.result_low;
vdso_data-tb_ticks_per_sec = tb_ticks_per_sec;
vdso_data-tb_to_xs = tb_to_xs;
+ cputime_one = jiffies_to_cputime(1);
}
else {
printk( Titan recalibrate: FAILED (difference
4 percent)\n
@@ -904,6 +905,7 @@ void __init time_init(void)
tb_ticks_per_usec = ppc_tb_freq / 100;
tb_to_us = mulhwu_scale_factor(ppc_tb_freq, 100);
calc_cputime_factors();
+ cputime_one = jiffies_to_cputime(1);
/*
* Calculate the length of each tick in ns. It will not be
diff --git a/arch/s390/include/asm/cputime.h b/arch/s390/include/asm/cputime.h
index 941384f..f7bbdc9 100644
--- a/arch/s390/include/asm/cputime.h
+++ b/arch/s390/include/asm/cputime.h
@@ -39,6 +39,7 @@ __div(unsigned long long n, unsigned int base)
#endif /* __s390x__ */
#define cputime_zero (0ULL)
+#define cputime_onejiffies_to_cputime(1)
#define cputime_max((~0UL 1) - 1)
#define cputime_add(__a, __b) ((__a) + (__b))
#define cputime_sub(__a, __b) ((__a) - (__b))
diff --git a/include/asm-generic/cputime.h b/include/asm-generic/cputime.h
index 1c1fa42..f2b18be 100644
--- a/include/asm-generic/cputime.h
+++ b/include/asm-generic/cputime.h
@@ -7,6 +7,7 @@
typedef unsigned long cputime_t;
#define cputime_zero (0UL)
+#define cputime_one(1UL)
#define cputime_max((~0UL 1) - 1)
#define cputime_add(__a, __b) ((__a) + (__b))
#define cputime_sub(__a, __b) ((__a) - (__b))
diff --git a/kernel/itimer.c b/kernel/itimer.c
index 58762f7..ba378c6 100644
--- a/kernel/itimer.c
+++ b/kernel/itimer.c
@@ -65,7 +65,7 @@ int do_getitimer(int which, struct itimerval *value)
thread_group_cputimer(tsk, cputime);
utime = cputime.utime;
if (cputime_le(cval, utime)) { /* about to fire */
- cval = jiffies_to_cputime(1);
+ cval = cputime_one;
} else {
cval = cputime_sub(cval, utime);
}
@@ -85,7 +85,7 @@ int do_getitimer(int which, struct itimerval *value)
thread_group_cputimer(tsk, times);
ptime = cputime_add(times.utime, times.stime);
if (cputime_le(cval, ptime)) { /* about to
Re: [PATCH resend4 2/3] itimers: fix periodic tics precision
On Mon, 25 May 2009 14:32:14 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: On Mon, 25 May 2009, Stanislaw Gruszka wrote: @@ -904,6 +905,7 @@ void __init time_init(void) tb_ticks_per_usec = ppc_tb_freq / 100; tb_to_us = mulhwu_scale_factor(ppc_tb_freq, 100); calc_cputime_factors(); + cputime_one = jiffies_to_cputime(1); 1) The variable name is misleading. What about cputime_one_jiffy ? 2) The patch breaks all powerpc platforms which have CONFIG_VIRT_CPU_ACCOUNTING=n and ia64 with CONFIG_VIRT_CPU_ACCOUNTING=y Stupid me, in asm-generic/cputime.h should be #define cputime_one jiffies_to_cputime(1) Thanks Stanislaw ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
82xx multiple soc support/initialization
Hi guys, I'm working on an derived muas3001 board (kernel version 2.6.30-rc5), and so far I did not find an example of multiple SOCs initialization. The board has 3 cpus (only one core activated). 1) Is there a special syntax to use in the device tree ? 2) Do the kernel provide an API to support multiple SOCs ? Best regards, Carl-Erwin Griffith ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V3 2/4] AC97 driver for mpc5200
On Mon, May 25, 2009 at 6:26 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: + spin_lock(psc_dma-lock); + out_be32(psc_dma-psc_regs-ac97_slots, psc_dma-slots); + spin_unlock(psc_dma-lock); + break; This locking looks wrong - I'd expect it to also cover the modification of psc_dma-slots? Otherwise it's hard to see what it buys you. Grant, why are you spin locking around register access? -- Jon Smirl jonsm...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V3 2/4] AC97 driver for mpc5200
On Mon, May 25, 2009 at 11:15:34AM -0400, Jon Smirl wrote: The link always runs at 12.288Mhz. Each frame is 256 bits. Worst case you wait for two frames, 42us. If it doesn't respond in 42us the codec Note that some embedded systems will choose to vary the AC97 link clock. The most common case is where there's a PLL on the CODEC - the CODEC will start up misclocked at whatever the input frequency it's got is and then be reclocked using register writes to configure the PLL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V3 2/4] AC97 driver for mpc5200
On Mon, May 25, 2009 at 9:15 AM, Jon Smirl jonsm...@gmail.com wrote:
On Mon, May 25, 2009 at 2:16 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
On Sun, May 24, 2009 at 7:38 PM, Jon Smirl jonsm...@gmail.com wrote:
+static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short
reg)
+{
+ int timeout;
+ unsigned int val;
+
+ spin_lock(psc_dma-lock);
+
+ /* Wait for it to be ready */
+ timeout = 1000;
+ while ((--timeout) (in_be16(psc_dma-psc_regs-sr_csr.status)
+ MPC52xx_PSC_SR_CMDSEND))
+ udelay(10);
Holy unbounded latency Batman! This code waits up to 10ms for a register
read!
I hate spinning, but if it must be done; I'd like to see it small.
What is the worst case latency? 125us for 8000Hz bus speed? If you
must spin; can a cpu_relax() be used instead of the udelay() while
watch the timebase? Timur recently posted a patch which makes this
easier.
http://patchwork.ozlabs.org/patch/27414/
They *should* be appearing in Ben's -next branch soon.
The link always runs at 12.288Mhz. Each frame is 256 bits. Worst case
you wait for two frames, 42us. If it doesn't respond in 42us the codec
clock is not ticking ( a recurring problem I am running into). These
codecs may be going into a sleep mode I don't understand, but this is
not the right place to try and wake them up. I'll lower the retry
counts to 10 instead of 1000.
That still leaves the problem of unecessarily burning time. udelay
shouldn't be passed any value larger than 1. In fact, I think udelay
itself is too coarse grained. Plus, I'd rather see the timebase used
as the exit condition (as mentioned in previous email).
I played around with implementing this on a kernel thread with
interrupts. It can be done but the code is a lot more complex.
A kernel thread is definitely the wrong approach. However, if this is
non-atomic context and IRQs are available, then a wait queue can be
used. 42us is about 16k processor clocks. I'm not sure what the IRQ
and scheduling overhead is so I don't know whether it would be a net
gain or loss in performance. However, it would be a net gain in worst
case latency.
BTW, 8000Hz is implemented by slot stuffing. The link always runs at
12.288Mhz. The DACs are double buffered. When a sample is transfered
between buffers it sets a bit on the link back to the host, and the
host sends the next sample in the appropriate slot.
ok.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V3 2/4] AC97 driver for mpc5200
On Mon, May 25, 2009 at 9:21 AM, Jon Smirl jonsm...@gmail.com wrote: On Mon, May 25, 2009 at 6:26 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: + spin_lock(psc_dma-lock); + out_be32(psc_dma-psc_regs-ac97_slots, psc_dma-slots); + spin_unlock(psc_dma-lock); + break; This locking looks wrong - I'd expect it to also cover the modification of psc_dma-slots? Otherwise it's hard to see what it buys you. Grant, why are you spin locking around register access? This lock/unlock is definitely bogus since a single register access is already atomic. Are there places in the code that I wrote where a spin_lock/unlock is done around a single register access? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Weird 5200/mtd-ram problem
Hi Gary Wolfram: Thanks for youre help, and sorry for the late reply - I've been on vacation... Am 20.05.09 21:59 schrieb(en) Gary Thomas: Try to access this without using the cache. Unfortunately, this is not cache related - I switched the dcache off completely - same results. Am 20.05.09 22:01 schrieb(en) Wolfram Sang: Does it work with byte, word and long accesses? A word or long copy of 0x0055aaff with U-Boot works fine, but a byte copy filled the whole ram with 0x. The reason is apparently that the chip is attached to the local bus in 16-bit mode, which is incompatible with byte accesses. However, the Local Bus doesn't provide low byte or high byte indicators in non-muxed mode. How is this supposed to work then? For the mtd driver, I tracked down the problem via mapram_write() (in drivers/mtd/chips/map_ram.c) down to the call of map_copy_to() which is actually inline_map_copy_to(), which in turn calls memcpy_toio(). I *think* this is _memcpy_toio() in arch/powerpc/kernel/io.c, which copies all data in long (4-byte) moves, except for the last 4 bytes. I guess I have to write my own copy function which respects the fact that byte writes actually must be a read word - modify - write word sequence, right? Thanks, Albrecht. pgpKH2lAYv2lA.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2 v8] powerpc: introduce macro spin_event_timeout()
On Tue, May 19, 2009 at 3:26 PM, Timur Tabi ti...@freescale.com wrote:
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns the result of the condition when the loop
was terminated.
This primary purpose of this macro is to poll on a hardware register until a
status bit changes. The timeout ensures that the loop still terminates if the
bit doesn't change as expected. This macro makes it easier for driver
developers to perform this kind of operation properly.
I just tried using this. The !rc has the effect of making the error
return be zero instead the normal not zero.
/* Wait for command send status zero = ready */
spin_event_timeout(!(in_be16(psc_dma-psc_regs-sr_csr.status)
MPC52xx_PSC_SR_CMDSEND), 100, 0, rc);
if (rc == 0) {
pr_err(timeout on ac97 bus (rdy)\n);
return -ENODEV;
}
I want the register to be zero, would this be more obvious?
/* Wait for command send status zero = ready */
spin_event_timeout((in_be16(psc_dma-psc_regs-sr_csr.status)
MPC52xx_PSC_SR_CMDSEND), 100, 0, rc);
if (rc != 0) {
pr_err(timeout on ac97 bus (rdy)\n);
return -ENODEV;
}
Signed-off-by: Timur Tabi ti...@freescale.com
---
v8: added a copyright notice
arch/powerpc/include/asm/delay.h | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/delay.h
b/arch/powerpc/include/asm/delay.h
index f9200a6..af4a270 100644
--- a/arch/powerpc/include/asm/delay.h
+++ b/arch/powerpc/include/asm/delay.h
@@ -2,8 +2,11 @@
#define _ASM_POWERPC_DELAY_H
#ifdef __KERNEL__
+#include asm/time.h
+
/*
* Copyright 1996, Paul Mackerras.
+ * Copyright (C) 2009 Freescale Semiconductor, Inc. All rights reserved.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -30,5 +33,35 @@ extern void udelay(unsigned long usecs);
#define mdelay(n) udelay((n) * 1000)
#endif
+/**
+ * spin_event_timeout - spin until a condition gets true or a timeout elapses
+ * @condition: a C expression to evalate
+ * @timeout: timeout, in microseconds
+ * @delay: the number of microseconds to delay between eache evaluation of
+ * @condition
+ * @rc: the last value of the condition
+ *
+ * The process spins until the condition evaluates to true (non-zero) or the
+ * timeout elapses. Upon exit, @rc contains the value of the condition. This
+ * allows you to test the condition without incurring any side effects.
+ *
+ * This primary purpose of this macro is to poll on a hardware register
+ * until a status bit changes. The timeout ensures that the loop still
+ * terminates even if the bit never changes. The delay is for devices that
+ * need a delay in between successive reads.
+ *
+ * gcc will optimize out the if-statement if @delay is a constant.
+ */
+#define spin_event_timeout(condition, timeout, delay, rc) \
+{ \
+ unsigned long __loops = tb_ticks_per_usec * timeout; \
+ unsigned long __start = get_tbl(); \
+ while (!(rc = (condition)) (tb_ticks_since(__start) = __loops)) \
+ if (delay) \
+ udelay(delay); \
+ else \
+ cpu_relax(); \
+}
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DELAY_H */
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Jon Smirl
jonsm...@gmail.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: U-boot and linux command line parameters
Dear Mirek23, In message 23703397.p...@talk.nabble.com you wrote: Thank you for your answer. When studying the u-boot source code I have found Will you please STOP posting the same questions on sevral mailing lists, especially without any form of cross-reference? Please read http://www.catb.org/~esr/faqs/smart-questions.html so you understand why you might not receive any further replies. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de How many NASA managers does it take to screw in a lightbulb? That's a known problem... don't worry about it. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Weird 5200/mtd-ram problem
Dear Albrecht =?iso-8859-1?b?RHJl3w==?=, In message 1243273283.332...@antares you wrote: Thanks for youre help, and sorry for the late reply - I've been on vacation... Hally you... For the mtd driver, I tracked down the problem via mapram_write() (in drivers/mtd/chips/map_ram.c) down to the call of map_copy_to() which is actually inline_map_copy_to(), which in turn calls memcpy_toio(). I *think* this is _memcpy_toio() in arch/powerpc/kernel/io.c, which copies all data in long (4-byte) moves, except for the last 4 bytes. I guess I have to write my own copy function which respects the fact that byte writes actually must be a read word - modify - write word sequence, right? I remember some nasty problems with memcpy*(), especially with un- aligned accesses over the LocalPlus Bus. I'm not sure if fixes ever made it into 2.6; the only commit that might be related is 6989f5122f fec: do not use memcpy on physical addresses, but this doesn't got into details about the casue. Please see here for an old (2.4.25) patch for this problem - maybe it's worth a try on your system: http://git.denx.de/?p=linuxppc_2_4_devel.git;a=commit;h=222bd702a59efb22bf66937f6ac844ed7327fd1a Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you're not part of the solution, you're part of the problem. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: U-boot and linux command line parameters
I have done some experiments with u-boot (version 1.2.0) and with linux kernel (version 2.6.23) and it seems to be that the limitation of 8MB is not anymore the problem. I have built u-boot and linux for ppc405 (virtex-4). I have set the CFG_BOOTMAPSZ to 16 MB: #define CFG_BOOTMAPSZ (8 21) /* 16 MB */ and Linux has picked up the command line parameters which were set in u-boot. /* * For booting Linux, the board info and command line data * have to be in the first 8 MB of memory, since this is * the maximum mapped by the Linux kernel during initialization. */ #define CFG_BOOTMAPSZ (8 20) /* Initial Memory map for Linux */ -- View this message in context: http://www.nabble.com/U-boot-and-linux-command-line-parameters-tp23698384p23712750.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
Re: [PATCH v5 0/4] Series short description
On Mon, May 25, 2009 at 4:41 PM, Grant Likely grant.lik...@secretlab.ca wrote: Repost of ml510 series. This time against 2.6.30-rc7 and with the .dts file included. g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. Thanks, I will check it out tomorrow. Roderick ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Weird 5200/mtd-ram problem
A word or long copy of 0x0055aaff with U-Boot works fine, but a byte copy filled the whole ram with 0x. The reason is apparently that the chip is attached to the local bus in 16-bit mode, which is incompatible with byte accesses. However, the Local Bus doesn't provide low byte or high byte indicators in non-muxed mode. How is this supposed to work then? Hmm, as I feared... we were bitten by this, too: http://thread.gmane.org/gmane.linux.drivers.mtd/21521 There is no generic solution yet :( -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc8315e-rdb: pci_enable_msi() fails (using today's galak/powerpc.git tree)
Hello, On Sun, May 24, 2009 at 8:38 AM, Michael Ellerman mich...@ellerman.id.au wrote: On Sun, 2009-05-24 at 00:12 +0200, Leon Woestenberg wrote: Hello, On Sat, May 23, 2009 at 10:58 PM, Leon Woestenberg leon.woestenb...@gmail.com wrote: using this tree: git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git pci_enable_msi() fails on my MPC8315E-RDB board with PCIe device in snip good bug report 'lspci -vvv' of the device in question is often useful too. Good point. Here's the full list, the last device is my target: :00:00.0 0b20: 1957:00b4 (rev 10) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 128, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 17 Region 2: Memory at unassigned (64-bit, prefetchable) Region 4: Memory at unassigned (64-bit, non-prefetchable) Capabilities: [48] CompactPCI hot-swap ? Capabilities: [80] Power Management version 3 Flags: PMEClk+ DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 0002:02:00.0 : 1957:00b4 (rev 10) !!! Invalid class for header type 01 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Bus: primary=02, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: -0fff Memory behind bridge: c000-cfff Prefetchable memory behind bridge: 0010-000f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [4c] Express (v1) Root Port (Slot-), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 2us, L1 unlimited ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID , PMEStatus- PMEPending- Capabilities: [100] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Capabilities: [138] Virtual Channel ? Capabilities: [3f8] Vendor Specific Information ? 0002:03:00.0 ff00: 1172:0004 (rev 01) Subsystem: 1172:0004 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 25 Region 0: Memory at c000 (32-bit, non-prefetchable) [size=32K] Capabilities: [50] MSI: Mask- 64bit+ Count=1/4 Enable+ Address: e7f8 Data: Capabilities: [78] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 256 bytes,
[PATCH V4 0/5] AC97 driver for mpc5200
Version 4. Changed timeouts to use relax_cpu() instead of udelay(). Fixed locking to lock bestcomm instead of registers. Code reorg as requested in the various comments. Removed sysfs over/underrun reporting. Removed reset retries. Removing the retries makes the driver fail to load about 5% of the time. An oscilliscope is needed to figure out what is going on with failed resets. Both pcm030 and Efika ocasionally fail to reset and they use different codec chips. --- Jon Smirl (5): 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 The macro spin_event_timeout() takes a condition and timeout value arch/powerpc/include/asm/delay.h| 33 +++ sound/soc/fsl/Kconfig | 27 ++ sound/soc/fsl/Makefile |5 sound/soc/fsl/efika-audio-fabric.c | 90 +++ sound/soc/fsl/mpc5200_dma.c | 442 ++- sound/soc/fsl/mpc5200_dma.h | 43 ++- sound/soc/fsl/mpc5200_psc_ac97.c| 331 ++ 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 | 90 +++ 11 files changed, 946 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 jonsm...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH V4 1/5] The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns the result of the condition when the loop
was terminated.
This primary purpose of this macro is to poll on a hardware register until a
status bit changes. The timeout ensures that the loop still terminates if the
bit doesn't change as expected. This macro makes it easier for driver
developers to perform this kind of operation properly.
Signed-off-by: Timur Tabi ti...@freescale.com
---
arch/powerpc/include/asm/delay.h | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/delay.h b/arch/powerpc/include/asm/delay.h
index f9200a6..fedf037 100644
--- a/arch/powerpc/include/asm/delay.h
+++ b/arch/powerpc/include/asm/delay.h
@@ -2,8 +2,11 @@
#define _ASM_POWERPC_DELAY_H
#ifdef __KERNEL__
+#include asm/time.h
+
/*
* Copyright 1996, Paul Mackerras.
+ * Copyright (C) 2009 Freescale Semiconductor, Inc. All rights reserved.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -30,5 +33,35 @@ extern void udelay(unsigned long usecs);
#define mdelay(n) udelay((n) * 1000)
#endif
+/**
+ * spin_event_timeout - spin until a condition gets true or a timeout elapses
+ * @condition: a C expression to evalate
+ * @timeout: timeout, in microseconds
+ * @delay: the number of microseconds to delay between eache evaluation of
+ * @condition
+ * @rc: the last value of the condition
+ *
+ * The process spins until the condition evaluates to true (non-zero) or the
+ * timeout elapses. Upon exit, @rc contains the value of the condition. This
+ * allows you to test the condition without incurring any side effects.
+ *
+ * This primary purpose of this macro is to poll on a hardware register
+ * until a status bit changes. The timeout ensures that the loop still
+ * terminates even if the bit never changes. The delay is for devices that
+ * need a delay in between successive reads.
+ *
+ * gcc will optimize out the if-statement if @delay is a constant.
+ */
+#define spin_event_timeout(condition, timeout, delay, rc) \
+{ \
+ unsigned long __loops = tb_ticks_per_usec * timeout;\
+ unsigned long __start = get_tbl(); \
+ while ((rc = (condition)) (tb_ticks_since(__start) = __loops)) \
+ if (delay) \
+ udelay(delay); \
+ else\
+ cpu_relax();\
+}
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DELAY_H */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH V4 2/5] Main rewite of the mpc5200 audio DMA code
Rewrite the mpc5200 audio DMA code to support both I2S and AC97.
Signed-off-by: Jon Smirl jonsm...@gmail.com
---
sound/soc/fsl/Kconfig |1
sound/soc/fsl/mpc5200_dma.c | 442 ---
sound/soc/fsl/mpc5200_dma.h | 43 ++--
sound/soc/fsl/mpc5200_psc_i2s.c | 247 --
sound/soc/fsl/mpc5200_psc_i2s.h | 12 +
5 files changed, 356 insertions(+), 389 deletions(-)
create mode 100644 sound/soc/fsl/mpc5200_psc_i2s.h
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index dc79bdf..1918c78 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -25,7 +25,6 @@ config SND_SOC_MPC8610_HPCD
config SND_SOC_MPC5200_I2S
tristate Freescale MPC5200 PSC in I2S mode driver
depends on PPC_MPC52xx PPC_BESTCOMM
- select SND_SOC_OF_SIMPLE
select SND_MPC52xx_DMA
select PPC_BESTCOMM_GEN_BD
help
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index 6850392..efec33a 100644
--- a/sound/soc/fsl/mpc5200_dma.c
+++ b/sound/soc/fsl/mpc5200_dma.c
@@ -3,23 +3,13 @@
* ALSA SoC Platform driver
*
* Copyright (C) 2008 Secret Lab Technologies Ltd.
+ * Copyright (C) 2009 Jon Smirl, Digispeaker
*/
-#include linux/init.h
#include linux/module.h
-#include linux/interrupt.h
-#include linux/device.h
-#include linux/delay.h
#include linux/of_device.h
-#include linux/of_platform.h
-#include linux/dma-mapping.h
-#include sound/core.h
-#include sound/pcm.h
-#include sound/pcm_params.h
-#include sound/initval.h
#include sound/soc.h
-#include sound/soc-of-simple.h
#include sysdev/bestcomm/bestcomm.h
#include sysdev/bestcomm/gen_bd.h
@@ -27,10 +17,6 @@
#include mpc5200_dma.h
-MODULE_AUTHOR(Grant Likely grant.lik...@secretlab.ca);
-MODULE_DESCRIPTION(Freescale MPC5200 PSC in DMA mode ASoC Driver);
-MODULE_LICENSE(GPL);
-
/*
* Interrupt handlers
*/
@@ -50,7 +36,7 @@ static irqreturn_t psc_dma_status_irq(int irq, void *_psc_dma)
if (psc_dma-capture.active (isr MPC52xx_PSC_IMR_ORERR))
psc_dma-stats.overrun_count++;
- out_8(regs-command, 4 4); /* reset the error status */
+ out_8(regs-command, MPC52xx_PSC_RST_ERR_STAT);
return IRQ_HANDLED;
}
@@ -81,21 +67,36 @@ static void psc_dma_bcom_enqueue_next_buffer(struct
psc_dma_stream *s)
s-period_next_pt = s-period_start;
}
+static void psc_dma_bcom_enqueue_tx(struct psc_dma_stream *s)
+{
+ while (s-appl_ptr s-runtime-control-appl_ptr) {
+
+ if (bcom_queue_full(s-bcom_task))
+ return;
+
+ s-appl_ptr += s-period_size;
+
+ psc_dma_bcom_enqueue_next_buffer(s);
+ }
+}
+
/* Bestcomm DMA irq handler */
-static irqreturn_t psc_dma_bcom_irq(int irq, void *_psc_dma_stream)
+static irqreturn_t psc_dma_bcom_irq_tx(int irq, void *_psc_dma_stream)
{
struct psc_dma_stream *s = _psc_dma_stream;
+ spin_lock(s-psc_dma-lock);
/* For each finished period, dequeue the completed period buffer
* and enqueue a new one in it's place. */
while (bcom_buffer_done(s-bcom_task)) {
bcom_retrieve_buffer(s-bcom_task, NULL, NULL);
+
s-period_current_pt += s-period_bytes;
if (s-period_current_pt = s-period_end)
s-period_current_pt = s-period_start;
- psc_dma_bcom_enqueue_next_buffer(s);
- bcom_enable(s-bcom_task);
}
+ psc_dma_bcom_enqueue_tx(s);
+ spin_unlock(s-psc_dma-lock);
/* If the stream is active, then also inform the PCM middle layer
* of the period finished event. */
@@ -105,49 +106,33 @@ static irqreturn_t psc_dma_bcom_irq(int irq, void
*_psc_dma_stream)
return IRQ_HANDLED;
}
-/**
- * psc_dma_startup: create a new substream
- *
- * This is the first function called when a stream is opened.
- *
- * If this is the first stream open, then grab the IRQ and program most of
- * the PSC registers.
- */
-int psc_dma_startup(struct snd_pcm_substream *substream,
- struct snd_soc_dai *dai)
+static irqreturn_t psc_dma_bcom_irq_rx(int irq, void *_psc_dma_stream)
{
- struct snd_soc_pcm_runtime *rtd = substream-private_data;
- struct psc_dma *psc_dma = rtd-dai-cpu_dai-private_data;
- int rc;
+ struct psc_dma_stream *s = _psc_dma_stream;
- dev_dbg(psc_dma-dev, psc_dma_startup(substream=%p)\n, substream);
+ spin_lock(s-psc_dma-lock);
+ /* For each finished period, dequeue the completed period buffer
+* and enqueue a new one in it's place. */
+ while (bcom_buffer_done(s-bcom_task)) {
+ bcom_retrieve_buffer(s-bcom_task, NULL, NULL);
- if (!psc_dma-playback.active
- !psc_dma-capture.active) {
- /* Setup the IRQs */
- rc = request_irq(psc_dma-irq, psc_dma_status_irq, IRQF_SHARED,
-
[PATCH V4 3/5] AC97 driver for mpc5200
AC97 driver for mpc5200
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.
Signed-off-by: Jon Smirl jonsm...@gmail.com
---
sound/soc/fsl/Kconfig| 11 +
sound/soc/fsl/Makefile |1
sound/soc/fsl/mpc5200_psc_ac97.c | 331 ++
sound/soc/fsl/mpc5200_psc_ac97.h | 15 ++
4 files changed, 358 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.c
create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.h
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 1918c78..3bce952 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -29,3 +29,14 @@ config SND_SOC_MPC5200_I2S
select PPC_BESTCOMM_GEN_BD
help
Say Y here to support the MPC5200 PSCs in I2S mode.
+
+config SND_SOC_MPC5200_AC97
+ tristate Freescale MPC5200 PSC in AC97 mode driver
+ depends on PPC_MPC52xx PPC_BESTCOMM
+ select AC97_BUS
+ select SND_MPC52xx_DMA
+ select PPC_BESTCOMM_GEN_BD
+ help
+ Say Y here to support the MPC5200 PSCs in AC97 mode.
+
+
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 7731ef2..14631a1 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -13,4 +13,5 @@ obj-$(CONFIG_SND_SOC_MPC8610) += snd-soc-fsl-ssi.o
snd-soc-fsl-dma.o
# MPC5200 Platform Support
obj-$(CONFIG_SND_MPC52xx_DMA) += mpc5200_dma.o
obj-$(CONFIG_SND_SOC_MPC5200_I2S) += mpc5200_psc_i2s.o
+obj-$(CONFIG_SND_SOC_MPC5200_AC97) += mpc5200_psc_ac97.o
diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c
new file mode 100644
index 000..3e6838c
--- /dev/null
+++ b/sound/soc/fsl/mpc5200_psc_ac97.c
@@ -0,0 +1,331 @@
+/*
+ * linux/sound/mpc5200-ac97.c -- AC97 support for the Freescale MPC52xx chip.
+ *
+ * Copyright (C) 2009 Jon Smirl, Digispeaker
+ * Author: Jon Smirl jonsm...@gmail.com
+ *
+ * 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/of_device.h
+#include linux/of_platform.h
+
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+
+#include asm/time.h
+#include asm/delay.h
+#include asm/mpc52xx_psc.h
+
+#include mpc5200_dma.h
+#include mpc5200_psc_ac97.h
+
+#define DRV_NAME mpc5200-psc-ac97
+
+/* ALSA only supports a single AC97 device so static is recommend here */
+static struct psc_dma *psc_dma;
+
+static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg)
+{
+ int rc;
+ unsigned int val;
+
+ /* Wait for command send status zero = ready */
+ spin_event_timeout((in_be16(psc_dma-psc_regs-sr_csr.status)
+ MPC52xx_PSC_SR_CMDSEND), 100, 0, rc);
+ if (rc != 0) {
+ pr_err(timeout on ac97 bus (rdy)\n);
+ return -ENODEV;
+ }
+ /* Send the read */
+ out_be32(psc_dma-psc_regs-ac97_cmd, (131) | ((reg 0x7f) 24));
+
+ /* Wait for the answer */
+ spin_event_timeout(!(in_be16(psc_dma-psc_regs-sr_csr.status)
+ MPC52xx_PSC_SR_DATA_VAL), 100, 0, rc);
+ if (rc != 0) {
+ pr_err(timeout on ac97 read (val) %x\n,
+ in_be16(psc_dma-psc_regs-sr_csr.status));
+ return -ENODEV;
+ }
+ /* Get the data */
+ val = in_be32(psc_dma-psc_regs-ac97_data);
+ if (((val 24) 0x7f) != reg) {
+ pr_err(reg echo error on ac97 read\n);
+ return -ENODEV;
+ }
+ val = (val 8) 0x;
+
+ return (unsigned short) val;
+}
+
+static void psc_ac97_write(struct snd_ac97 *ac97,
+ unsigned short reg, unsigned short val)
+{
+ int rc;
+
+ /* Wait for command status zero = ready */
+ spin_event_timeout((in_be16(psc_dma-psc_regs-sr_csr.status)
+ MPC52xx_PSC_SR_CMDSEND), 100, 0, rc);
+ if (rc != 0) {
+ pr_err(timeout on ac97 bus (write)\n);
+ return;
+ }
+ /* Write data */
+ out_be32(psc_dma-psc_regs-ac97_cmd,
+ ((reg 0x7f) 24) | (val 8));
+}
+
+static void psc_ac97_warm_reset(struct snd_ac97 *ac97)
+{
+ int rc;
+ struct mpc52xx_psc __iomem *regs = psc_dma-psc_regs;
+
+ out_be32(regs-sicr, psc_dma-sicr | MPC52xx_PSC_SICR_AWR);
+ spin_event_timeout(1, 3, 0, rc);
+ out_be32(regs-sicr, psc_dma-sicr);
+}
+
+static void psc_ac97_cold_reset(struct snd_ac97 *ac97)
+{
+ int rc;
+
[PATCH V4 4/5] Support for AC97 on Phytec pmc030 base board.
Support for AC97 on Phytec pmc030 base board. A wm9712 AC97 codec is used.
Signed-off-by: Jon Smirl jonsm...@gmail.com
---
sound/soc/fsl/Kconfig |7 +++
sound/soc/fsl/Makefile |3 +
sound/soc/fsl/pcm030-audio-fabric.c | 90 +++
3 files changed, 100 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/fsl/pcm030-audio-fabric.c
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3bce952..79579ae 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -39,4 +39,11 @@ config SND_SOC_MPC5200_AC97
help
Say Y here to support the MPC5200 PSCs in AC97 mode.
+config SND_MPC52xx_SOC_PCM030
+ tristate SoC AC97 Audio support for Phytec pcm030 and WM9712
+ depends on PPC_MPC5200_SIMPLE
+ select SND_SOC_MPC5200_AC97
+ select SND_SOC_WM9712
+ help
+ Say Y if you want to add support for sound on the Phytec pcm030
baseboard.
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 14631a1..66d88c8 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -15,3 +15,6 @@ obj-$(CONFIG_SND_MPC52xx_DMA) += mpc5200_dma.o
obj-$(CONFIG_SND_SOC_MPC5200_I2S) += mpc5200_psc_i2s.o
obj-$(CONFIG_SND_SOC_MPC5200_AC97) += mpc5200_psc_ac97.o
+# MPC5200 Machine Support
+obj-$(CONFIG_SND_MPC52xx_SOC_PCM030) += pcm030-audio-fabric.o
+
diff --git a/sound/soc/fsl/pcm030-audio-fabric.c
b/sound/soc/fsl/pcm030-audio-fabric.c
new file mode 100644
index 000..8766f7a
--- /dev/null
+++ b/sound/soc/fsl/pcm030-audio-fabric.c
@@ -0,0 +1,90 @@
+/*
+ * Phytec pcm030 driver for the PSC of the Freescale MPC52xx
+ * configured as AC97 interface
+ *
+ * Copyright 2008 Jon Smirl, Digispeaker
+ * Author: Jon Smirl jonsm...@gmail.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/of_device.h
+#include linux/of_platform.h
+#include linux/dma-mapping.h
+
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/initval.h
+#include sound/soc.h
+#include sound/soc-of-simple.h
+
+#include mpc5200_dma.h
+#include mpc5200_psc_ac97.h
+#include ../codecs/wm9712.h
+
+static struct snd_soc_device device;
+static struct snd_soc_card card;
+
+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;
+}
+
+module_init(pcm030_fabric_init);
+
+
+MODULE_AUTHOR(Jon Smirl jonsm...@gmail.com);
+MODULE_DESCRIPTION(DRV_NAME : mpc5200 pcm030 fabric driver);
+MODULE_LICENSE(GPL);
+
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH V4 5/5] Fabric bindings for STAC9766 on the Efika
Fabric bindings for STAC9766 AC97 codec on the Efika.
Signed-off-by: Jon Smirl jonsm...@gmail.com
---
sound/soc/fsl/Kconfig |8 +++
sound/soc/fsl/Makefile |1
sound/soc/fsl/efika-audio-fabric.c | 90
3 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/fsl/efika-audio-fabric.c
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 79579ae..f571c6e 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -47,3 +47,11 @@ config SND_MPC52xx_SOC_PCM030
help
Say Y if you want to add support for sound on the Phytec pcm030
baseboard.
+config SND_MPC52xx_SOC_EFIKA
+ tristate SoC AC97 Audio support for bbplan Efika and STAC9766
+ depends on PPC_EFIKA
+ select SND_SOC_MPC5200_AC97
+ select SND_SOC_STAC9766
+ help
+ Say Y if you want to add support for sound on the Efika.
+
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 66d88c8..a83a739 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -17,4 +17,5 @@ obj-$(CONFIG_SND_SOC_MPC5200_AC97) += mpc5200_psc_ac97.o
# MPC5200 Machine Support
obj-$(CONFIG_SND_MPC52xx_SOC_PCM030) += pcm030-audio-fabric.o
+obj-$(CONFIG_SND_MPC52xx_SOC_EFIKA) += efika-audio-fabric.o
diff --git a/sound/soc/fsl/efika-audio-fabric.c
b/sound/soc/fsl/efika-audio-fabric.c
new file mode 100644
index 000..85b0e75
--- /dev/null
+++ b/sound/soc/fsl/efika-audio-fabric.c
@@ -0,0 +1,90 @@
+/*
+ * Efika driver for the PSC of the Freescale MPC52xx
+ * configured as AC97 interface
+ *
+ * Copyright 2008 Jon Smirl, Digispeaker
+ * Author: Jon Smirl jonsm...@gmail.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/of_device.h
+#include linux/of_platform.h
+#include linux/dma-mapping.h
+
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/initval.h
+#include sound/soc.h
+#include sound/soc-of-simple.h
+
+#include mpc5200_dma.h
+#include mpc5200_psc_ac97.h
+#include ../codecs/stac9766.h
+
+static struct snd_soc_device device;
+static struct snd_soc_card card;
+
+static struct snd_soc_dai_link efika_fabric_dai[] = {
+{
+ .name = AC97,
+ .stream_name = AC97 Analog,
+ .codec_dai = stac9766_dai[STAC9766_DAI_AC97_ANALOG],
+ .cpu_dai = psc_ac97_dai[MPC5200_AC97_NORMAL],
+},
+{
+ .name = AC97,
+ .stream_name = AC97 IEC958,
+ .codec_dai = stac9766_dai[STAC9766_DAI_AC97_DIGITAL],
+ .cpu_dai = psc_ac97_dai[MPC5200_AC97_SPDIF],
+},
+};
+
+static __init int efika_fabric_init(void)
+{
+ struct platform_device *pdev;
+ int rc;
+
+ if (!machine_is_compatible(bplan,efika))
+ return -ENODEV;
+
+ card.platform = mpc5200_audio_dma_platform;
+ card.name = Efika;
+ card.dai_link = efika_fabric_dai;
+ card.num_links = ARRAY_SIZE(efika_fabric_dai);
+
+ device.card = card;
+ device.codec_dev = soc_codec_dev_stac9766;
+
+ pdev = platform_device_alloc(soc-audio, 1);
+ if (!pdev) {
+ pr_err(efika_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(efika_fabric_init: platform_device_add() failed\n);
+ return -ENODEV;
+ }
+ return 0;
+}
+
+module_init(efika_fabric_init);
+
+
+MODULE_AUTHOR(Jon Smirl jonsm...@gmail.com);
+MODULE_DESCRIPTION(DRV_NAME : mpc5200 Efika fabric driver);
+MODULE_LICENSE(GPL);
+
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Initialize DBCR0 for PPC440 targets
On Mon, May 25, 2009 at 05:04:35PM +1000, Benjamin Herrenschmidt wrote: On Wed, 2009-05-20 at 16:00 +1000, David Gibson wrote: On Wed, May 20, 2009 at 11:20:46AM +0530, srikanth krishnakar wrote: Hi David, I am not sure how the IDM behaves on few of PPC440 targets which don't have boot loaders. I have a reference for your question: http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html Without this fix (given patch) I am facing problems with GDB, and further target hangs while running gdbserver ! That doesn't answer my question. It's not enough to say this fixes a problem you need to explain *how* it fixes the problem. And I don't see why IDM would have any effect on *software* breakpoints. No but gdb can use the DABR emulation and single step would be busted too. GDB internally heavily uses single step in places you wouldn't expect it to :-) Like I think when breaking on main, it sometimes single step the whole init process of the executable until it hits it. At least I've seen it do that when I was debugging the debug support for 64-bit Book3E. Right, but I believe the kernel does turn on IDM when it turns on single step, or the DAC event bit. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2 v8] powerpc: introduce macro spin_event_timeout()
On Mon, May 25, 2009 at 12:46 PM, Jon Smirl jonsm...@gmail.com wrote: I just tried using this. The !rc has the effect of making the error return be zero instead the normal not zero. You're confused. It's not a return code, it's a return value. I guess I should have called the parameter ret instead of rc, but I didn't expect people to get confused. 'rc' is the value of the expression when the loop terminates. That's what makes the most sense, because the developer will want to know what that value is. If you're expression happens to rely on negative logic (e.g. wait until a bit is cleared), then of course it's going to appear backwards when you test it. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH V4 3/5] AC97 driver for mpc5200
On Mon, May 25, 2009 at 5:15 PM, Jon Smirl jonsm...@gmail.com wrote: + spin_event_timeout(1, 3, 0, rc); Ugh, don't do this. Just use udelay! -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH V4 3/5] AC97 driver for mpc5200
On Mon, May 25, 2009 at 9:41 PM, Timur Tabi ti...@freescale.com wrote: On Mon, May 25, 2009 at 5:15 PM, Jon Smirl jonsm...@gmail.com wrote: + spin_event_timeout(1, 3, 0, rc); Ugh, don't do this. Just use udelay! heh; indeed. My objection to udelay is that it burns cycles it the test loop that could be used to decide whether or not the loop is complete. Not an issue when the explicit goal is to burn a fixed number of cycles. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here's the first of two fixes for nasty brown paper bag bugs that went in recently and are both my fault (I need to start buying those bags in bulk I reckon...) It's 2.6.30 material. I'll send the second one tomorrow or so after a bit more review and testing happened as it's unfortunately more invasive. The following changes since commit b18f1e21993f73f072b1e0859f942fb11afddcb1: Linus Torvalds (1): Merge branch 'kvm-updates/2.6.30' of git://git.kernel.org/pub/scm/virt/kvm/kvm are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Hideo Saito (1): powerpc/mm: Fix broken MMU PID stealing on !SMP arch/powerpc/mm/mmu_context_nohash.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
