Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE
Ilya, any comment on this? Can a fix be made quickly, or should this patch be reverted until a more robust version can be crafted? g. On Thu, May 21, 2009 at 10:50 AM, Albert Herranz wrote: > > Hello list, > > Commit 33f00dcedb0e22cdb156a23632814fc580fcfcf8 seems to have broken DMA > coherent allocations for CONFIG_NOT_COHERENT_CACHE platforms. > > The problems seem to be that the new __dma_alloc_coherent() and > __dma_free_coherent() implementations: > > - don't respect anymore the passed gfp flags (__dma_alloc_coherent() > unconditionally uses GFP_KERNEL within the function irrespective of the > caller flags) > - can't be used in interrupt context as they use get_vm_area_caller()/vfree() > which end up triggering BUG_ON(in_interrupt()) > > One victim happens to be the USB core subsystem which sometimes frees dma > coherent memory in interrupt context for drivers flagged HCD_LOCAL_MEM. > > This has been experienced while writing a new EHCI driver for the Nintendo > Wii platform. > > usb 1-1: new high speed USB device using ehci-mipc and address 2 > [ cut here ] > kernel BUG at mm/vmalloc.c:1328! > Oops: Exception in kernel mode, sig: 5 [#1] > PREEMPT wii > Modules linked in: > NIP: c008ea20 LR: c0015890 CTR: c00111d4 > REGS: d2c65b10 TRAP: 0700 Not tainted > (2.6.30-rc2-isobel-wii-00092-gcba94db-dirty) > MSR: 00021032 CR: 42482028 XER: > TASK = d2c600f0[28] 'kmmcd' THREAD: d2c64000 > GPR00: 0001 d2c65bc0 d2c600f0 d403 d403 d403 12da1000 0001 > GPR08: d2c64000 0020 22482022 94fdfb98 6e1979bc c6bbdbdd > GPR16: 0020 00200200 00100100 d4020060 0001 d401c0ec 0001 d401c0ec > GPR24: d2d9a6c0 d2f69de0 d2d9a600 d2f69e30 d2f69e2c d2da08e0 > NIP [c008ea20] vfree+0xc/0x18 > LR [c0015890] __dma_free_coherent+0x14/0x24 > Call Trace: > [d2c65bc0] [c0017af8] __mipc_recv_req+0x160/0x178 (unreliable) > [d2c65bd0] [c00111ec] dma_direct_free_coherent+0x18/0x28 > [d2c65be0] [c01cfca4] hcd_free_coherent+0x7c/0x12c > [d2c65c10] [c01d00b8] unmap_urb_for_dma+0x150/0x1cc > [d2c65c20] [c01d0174] usb_hcd_giveback_urb+0x40/0xe4 > [d2c65c30] [c01df474] ehci_urb_done+0xf0/0x114 > [d2c65c50] [c01e3870] qh_completions+0x41c/0x4dc > [d2c65ca0] [c01e44e0] scan_async+0x9c/0x1a0 > [d2c65cc0] [c01e49ec] ehci_work+0x58/0xc4 > [d2c65cd0] [c01e5424] ehci_irq+0x22c/0x230 > [d2c65d00] [c01cfa88] usb_hcd_irq+0x50/0xa8 > [d2c65d20] [c00597d8] handle_IRQ_event+0xdc/0x250 > [d2c65d60] [c005ba20] handle_level_irq+0x9c/0x138 > [d2c65d80] [c001cbc8] hollywood_pic_irq_cascade+0x7c/0xf8 > [d2c65da0] [c00064b4] do_IRQ+0x9c/0xc4 > [d2c65dc0] [c0011fb8] ret_from_except+0x0/0x14 > > Any comments on how to address this issue (other than reverting the above > mentioned commit, which fixes it) are welcome. > > Thanks, > Albert > > > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > -- 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: mpc8315e-rdb: pci_enable_msi() fails (using today's galak/powerpc.git tree)
On Sun, 2009-05-24 at 00:12 +0200, Leon Woestenberg wrote: > Hello, > > On Sat, May 23, 2009 at 10:58 PM, Leon Woestenberg > 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 'lspci -vvv' of the device in question is often useful too. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH V2 4/9] Add a few more mpc5200 PSC defines
Add a few more mpc5200 PSC defines. More bit fields defines for mpc5200 PSC registers. This patch is going in via Grant's tree. Signed-off-by: Jon Smirl --- 0 files changed, 0 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/mpc52xx_psc.h b/arch/powerpc/include/asm/mpc52xx_psc.h index a218da6..fb84120 100644 --- a/arch/powerpc/include/asm/mpc52xx_psc.h +++ b/arch/powerpc/include/asm/mpc52xx_psc.h @@ -28,6 +28,10 @@ #define MPC52xx_PSC_MAXNUM 6 /* Programmable Serial Controller (PSC) status register bits */ +#define MPC52xx_PSC_SR_UNEX_RX 0x0001 +#define MPC52xx_PSC_SR_DATA_VAL0x0002 +#define MPC52xx_PSC_SR_DATA_OVR0x0004 +#define MPC52xx_PSC_SR_CMDSEND 0x0008 #define MPC52xx_PSC_SR_CDE 0x0080 #define MPC52xx_PSC_SR_RXRDY 0x0100 #define MPC52xx_PSC_SR_RXFULL 0x0200 @@ -61,6 +65,12 @@ #define MPC52xx_PSC_RXTX_FIFO_EMPTY0x0001 /* PSC interrupt status/mask bits */ +#define MPC52xx_PSC_IMR_UNEX_RX_SLOT 0x0001 +#define MPC52xx_PSC_IMR_DATA_VALID 0x0002 +#define MPC52xx_PSC_IMR_DATA_OVR 0x0004 +#define MPC52xx_PSC_IMR_CMD_SEND 0x0008 +#define MPC52xx_PSC_IMR_ERROR 0x0040 +#define MPC52xx_PSC_IMR_DEOF 0x0080 #define MPC52xx_PSC_IMR_TXRDY 0x0100 #define MPC52xx_PSC_IMR_RXRDY 0x0200 #define MPC52xx_PSC_IMR_DB 0x0400 @@ -117,6 +127,7 @@ #define MPC52xx_PSC_SICR_SIM_FIR (0x6 << 24) #define MPC52xx_PSC_SICR_SIM_CODEC_24 (0x7 << 24) #define MPC52xx_PSC_SICR_SIM_CODEC_32 (0xf << 24) +#define MPC52xx_PSC_SICR_AWR (1 << 30) #define MPC52xx_PSC_SICR_GENCLK(1 << 23) #define MPC52xx_PSC_SICR_I2S (1 << 22) #define MPC52xx_PSC_SICR_CLKPOL(1 << 21) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2 0/9] mpc5200 audio rework for AC97
On Sat, May 23, 2009 at 7:12 PM, 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. Series is based on branch for-2.6.31 commit 0154724d487586241c1ad57cfd348ed2ff2274e2 at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git -- Jon Smirl jonsm...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH V2 9/9] 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
---
sound/soc/fsl/Kconfig |7 +++
sound/soc/fsl/Makefile |1
sound/soc/fsl/pcm030-audio-fabric.c | 94 +++
3 files changed, 102 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 edd8516..5080e3e 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -47,4 +47,11 @@ config SND_MPC52xx_SOC_EFIKA
help
Say Y if you want to add support for sound on the Efika.
+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 f406470..5806d11 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_EFIKA) += efika-audio-fabric.o
+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..4bd957a
--- /dev/null
+++ b/sound/soc/fsl/pcm030-audio-fabric.c
@@ -0,0 +1,94 @@
+/*
+ * Phytec pcm030 driver for the PSC of the Freescale MPC52xx configured as
AC97 interface
+ *
+ * Copyright 2008 Jon Smirl, Digispeaker
+ * Author: Jon Smirl
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#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;
+}
+
+static __exit void pcm030_fabric_exit(void)
+{
+}
+
+module_init(pcm030_fabric_init);
+module_exit(pcm030_fabric_exit);
+
+
+MODULE_AUTHOR("Jon Smirl ");
+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 V2 8/9] Fabric bindings for STAC9766 on the Efika
Fabric bindings for STAC9766 AC97 codec on the Efika.
Signed-off-by: Jon Smirl
---
sound/soc/fsl/Kconfig |8 +++
sound/soc/fsl/Makefile |3 +
sound/soc/fsl/efika-audio-fabric.c | 94
3 files changed, 105 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 3bce952..edd8516 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -39,4 +39,12 @@ config SND_SOC_MPC5200_AC97
help
Say Y here to support the MPC5200 PSCs in AC97 mode.
+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 14631a1..f406470 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_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..5126a81
--- /dev/null
+++ b/sound/soc/fsl/efika-audio-fabric.c
@@ -0,0 +1,94 @@
+/*
+ * Efika driver for the PSC of the Freescale MPC52xx configured as AC97
interface
+ *
+ * Copyright 2008 Jon Smirl, Digispeaker
+ * Author: Jon Smirl
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#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;
+}
+
+static __exit void efika_fabric_exit(void)
+{
+}
+
+module_init(efika_fabric_init);
+module_exit(efika_fabric_exit);
+
+
+MODULE_AUTHOR("Jon Smirl ");
+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
[PATCH V2 7/9] AC97 driver for mpc5200
AC97 driver for mpc5200
Signed-off-by: Jon Smirl
---
sound/soc/fsl/Kconfig| 11 +
sound/soc/fsl/Makefile |1
sound/soc/fsl/mpc5200_psc_ac97.c | 394 ++
sound/soc/fsl/mpc5200_psc_ac97.h | 15 +
4 files changed, 421 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..fa1bb9a
--- /dev/null
+++ b/sound/soc/fsl/mpc5200_psc_ac97.c
@@ -0,0 +1,394 @@
+/*
+ * linux/sound/mpc5200-ac97.c -- AC97 support for the Freescale MPC52xx chip.
+ *
+ * Copyright (C) 2009 Jon Smirl, Digispeaker
+ * Author: Jon Smirl
+ *
+ * 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
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+
+#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);
+
+ if (!timeout) {
+ pr_err("timeout on ac97 bus (rdy)\n");
+ return 0x;
+ }
+
+ /* Do the read */
+ out_be32(&psc_dma->psc_regs->ac97_cmd, (1<<31) | ((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);
+
+ if (!timeout) {
+ pr_err("timeout on ac97 read (val) %x\n",
in_be16(&psc_dma->psc_regs->sr_csr.status));
+ return 0x;
+ }
+
+ /* 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 0x;
+ }
+ val = (val >> 8) & 0x;
+
+ spin_unlock(&psc_dma->lock);
+ return (unsigned short) val;
+}
+
+static void psc_ac97_write(struct snd_ac97 *ac97, unsigned short reg, unsigned
short val)
+{
+ int timeout;
+
+ 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);
+
+ if (!timeout) {
+ pr_err("timeout on ac97 write\n");
+ return;
+ }
+
+ /* Write data */
+ out_be32(&psc_dma->psc_regs->ac97_cmd, ((reg & 0x7f) << 24) | (val <<
8));
+
+ spin_unlock(&psc_dma->lock);
+}
+
+static void psc_ac97_cold_reset(struct snd_ac97 *ac97)
+{
+ struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs;
+
+ /* Do a cold reset */
+ out_8(®s->op1, MPC52xx_PSC_OP_RES);
+ udelay(10);
+ out_8(®s->op0, MPC52xx_PSC_OP_RES);
+ udelay(50);
+
+ /* PSC recover from cold reset (cfr user manual, not sure if useful) */
+ out_be32(®s->sicr, in_be32(®s->sicr));
+}
+
+static void psc_ac97_warm_reset(struct snd_ac97 *ac97)
+{
+ struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs;
+
+ out_be32(®s->sicr, psc_dma->sicr | MPC52xx_PSC_SICR_AWR);
+ udelay(3);
+ out_be32(®s-
[PATCH V2 6/9] Codec for STAC9766 used on the Efika
AC97 codec for STAC9766 used on the Efika.
Datasheet: http://www.idt.com/products/getDoc.cfm?docID=13134007
Signed-off-by: Jon Smirl
---
0 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 7f78b65..cb07d9b 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -19,6 +19,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_CS4270 if I2C
select SND_SOC_PCM3008
select SND_SOC_SSM2602 if I2C
+ select SND_SOC_STAC9766 if SND_SOC_AC97_BUS
select SND_SOC_TLV320AIC23 if I2C
select SND_SOC_TLV320AIC26 if SPI_MASTER
select SND_SOC_TLV320AIC3X if I2C
@@ -93,6 +94,9 @@ config SND_SOC_PCM3008
config SND_SOC_SSM2602
tristate
+config SND_SOC_STAC9766
+ tristate
+
config SND_SOC_TLV320AIC23
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 70c55fa..46c007c 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -7,6 +7,7 @@ snd-soc-cs4270-objs := cs4270.o
snd-soc-l3-objs := l3.o
snd-soc-pcm3008-objs := pcm3008.o
snd-soc-ssm2602-objs := ssm2602.o
+snd-soc-stac9766-objs := stac9766.o
snd-soc-tlv320aic23-objs := tlv320aic23.o
snd-soc-tlv320aic26-objs := tlv320aic26.o
snd-soc-tlv320aic3x-objs := tlv320aic3x.o
@@ -42,6 +43,7 @@ obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o
obj-$(CONFIG_SND_SOC_L3) += snd-soc-l3.o
obj-$(CONFIG_SND_SOC_PCM3008) += snd-soc-pcm3008.o
obj-$(CONFIG_SND_SOC_SSM2602) += snd-soc-ssm2602.o
+obj-$(CONFIG_SND_SOC_STAC9766) += snd-soc-stac9766.o
obj-$(CONFIG_SND_SOC_TLV320AIC23) += snd-soc-tlv320aic23.o
obj-$(CONFIG_SND_SOC_TLV320AIC26) += snd-soc-tlv320aic26.o
obj-$(CONFIG_SND_SOC_TLV320AIC3X) += snd-soc-tlv320aic3x.o
diff --git a/sound/soc/codecs/stac9766.c b/sound/soc/codecs/stac9766.c
new file mode 100644
index 000..7740cd5
--- /dev/null
+++ b/sound/soc/codecs/stac9766.c
@@ -0,0 +1,470 @@
+/*
+ * stac9766.c -- ALSA SoC STAC9766 codec support
+ *
+ * Copyright 2009 Jon Smirl, Digispeaker
+ * Author: Jon Smirl
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * Features:-
+ *
+ * o Support for AC97 Codec, S/PDIF
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "stac9766.h"
+
+#define STAC9766_VERSION "0.10"
+
+/*
+ * STAC9766 register cache
+ */
+static const u16 stac9766_reg[] = {
+ 0x6A90, 0x8000, 0x8000, 0x8000, /* 6 */
+ 0x, 0x, 0x8008, 0x8008, /* e */
+ 0x8808, 0x8808, 0x8808, 0x8808, /* 16 */
+ 0x8808, 0x, 0x8000, 0x, /* 1e */
+ 0x, 0x, 0x, 0x000f, /* 26 */
+ 0x0a05, 0x0400, 0xbb80, 0x, /* 2e */
+ 0x, 0xbb80, 0x, 0x, /* 36 */
+ 0x, 0x2000, 0x, 0x0100, /* 3e */
+ 0x, 0x, 0x0080, 0x, /* 46 */
+ 0x, 0x, 0x0003, 0x, /* 4e */
+ 0x, 0x, 0x, 0x, /* 56 */
+ 0x4000, 0x, 0x, 0x, /* 5e */
+ 0x1201, 0x, 0x, 0x, /* 66 */
+ 0x, 0x, 0x, 0x, /* 6e */
+ 0x, 0x, 0x, 0x0006, /* 76 */
+ 0x, 0x, 0x, 0x, /* 7e */
+};
+
+static const char *stac9766_record_mux[] = {"Mic", "CD", "Video", "AUX",
"Line", "Stereo Mix", "Mono Mix", "Phone"};
+static const char *stac9766_mono_mux[] = {"Mix", "Mic"};
+static const char *stac9766_mic_mux[] = {"Mic1", "Mic2"};
+static const char *stac9766_SPDIF_mux[] = {"PCM", "ADC Record"};
+static const char *stac9766_popbypass_mux[] = {"Normal", "Bypass Mixer"};
+static const char *stac9766_record_all_mux[] = {"All analog", "Analog plus
DAC"};
+static const char *stac9766_boost1[] = {"0dB", "10dB"};
+static const char *stac9766_boost2[] = {"0dB", "20dB"};
+static const char *stac9766_stereo_mic[] = {"Off", "On"};
+
+static const struct soc_enum stac9766_record_enum =
+ SOC_ENUM_DOUBLE(AC97_REC_SEL, 8, 0, 8, stac9766_record_mux);
+static const struct soc_enum stac9766_mono_enum =
+ SOC_ENUM_SINGLE(AC97_GENERAL_PURPOSE, 9, 2, stac9766_mono_mux);
+static const struct soc_enum stac9766_mic_enum =
+ SOC_ENUM_SINGLE(AC97_GENERAL_PURPOSE, 8, 2, stac9766_mic_mux);
+static const struct soc_enum stac9766_SPDIF_enum =
+ SOC_ENUM_SINGLE(AC97_STAC_DA_CONTROL, 1, 2, stac9766_SPDIF_mux);
+static const struct soc_enum stac9766_popbypass_enum =
+ SOC_ENUM_SINGLE(AC97_GENERAL_PURPOSE, 15, 2, stac9766_popbypass_mux);
+static const struct soc_enum stac9766_record_all_enum =
+ SOC_ENUM_SINGLE(AC97_STAC_ANALOG_SPECIAL, 12, 2,
stac9766_record_all_mux);
+static const struct soc_enum stac9766_boost1_enum =
+ SOC_ENUM_SINGLE(AC97_MIC, 6, 2, stac9766_boost1
[PATCH V2 5/9] Main rewite of the mpc5200 audio DMA code
Rewrite the mpc5200 audio DMA code to support both I2S and AC97. Make it more
robust.
Signed-off-by: Jon Smirl
---
sound/soc/fsl/Kconfig |1
sound/soc/fsl/mpc5200_dma.c | 505 ++-
sound/soc/fsl/mpc5200_dma.h | 29 +-
sound/soc/fsl/mpc5200_psc_i2s.c | 243 +++
sound/soc/fsl/mpc5200_psc_i2s.h | 12 +
5 files changed, 407 insertions(+), 383 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..95df860 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
#include
-#include
-#include
-#include
#include
-#include
-#include
-#include
-#include
-#include
-#include
#include
-#include
#include
#include
@@ -27,10 +17,6 @@
#include "mpc5200_dma.h"
-MODULE_AUTHOR("Grant Likely ");
-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(®s->command, 4 << 4); /* reset the error status */
+ out_8(®s->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 = request_irq(psc_dma->irq, &psc_dma_status_irq, IRQF_SHARED,
-"psc-dma-status", psc_dma);
- rc |= request_irq(psc_dma->capture.irq,
- &psc_dma_bcom_irq, IRQF_SHARED,
- "psc-dma-capture", &psc_dma->capture);
- rc |= request_irq(psc_dma->playback.irq,
-
[PATCH V2 3/9] Rename the PSC functions to DMA
Rename the functions in the mpc5200 DMA file from i2s based names to dma ones
to reflect the file they are in.
Signed-off-by: Jon Smirl
---
sound/soc/fsl/mpc5200_dma.c | 194 ---
sound/soc/fsl/mpc5200_dma.h | 26 +++--
sound/soc/fsl/mpc5200_psc_i2s.c | 160
3 files changed, 190 insertions(+), 190 deletions(-)
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index 4bae8d6..6850392 100644
--- a/sound/soc/fsl/mpc5200_dma.c
+++ b/sound/soc/fsl/mpc5200_dma.c
@@ -34,21 +34,21 @@ MODULE_LICENSE("GPL");
/*
* Interrupt handlers
*/
-static irqreturn_t psc_i2s_status_irq(int irq, void *_psc_i2s)
+static irqreturn_t psc_dma_status_irq(int irq, void *_psc_dma)
{
- struct psc_i2s *psc_i2s = _psc_i2s;
- struct mpc52xx_psc __iomem *regs = psc_i2s->psc_regs;
+ struct psc_dma *psc_dma = _psc_dma;
+ struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs;
u16 isr;
isr = in_be16(®s->mpc52xx_psc_isr);
/* Playback underrun error */
- if (psc_i2s->playback.active && (isr & MPC52xx_PSC_IMR_TXEMP))
- psc_i2s->stats.underrun_count++;
+ if (psc_dma->playback.active && (isr & MPC52xx_PSC_IMR_TXEMP))
+ psc_dma->stats.underrun_count++;
/* Capture overrun error */
- if (psc_i2s->capture.active && (isr & MPC52xx_PSC_IMR_ORERR))
- psc_i2s->stats.overrun_count++;
+ if (psc_dma->capture.active && (isr & MPC52xx_PSC_IMR_ORERR))
+ psc_dma->stats.overrun_count++;
out_8(®s->command, 4 << 4); /* reset the error status */
@@ -56,7 +56,7 @@ static irqreturn_t psc_i2s_status_irq(int irq, void *_psc_i2s)
}
/**
- * psc_i2s_bcom_enqueue_next_buffer - Enqueue another audio buffer
+ * psc_dma_bcom_enqueue_next_buffer - Enqueue another audio buffer
* @s: pointer to stream private data structure
*
* Enqueues another audio period buffer into the bestcomm queue.
@@ -65,7 +65,7 @@ static irqreturn_t psc_i2s_status_irq(int irq, void *_psc_i2s)
* the queue. Otherwise the enqueue will fail and the audio ring buffer
* will get out of sync
*/
-static void psc_i2s_bcom_enqueue_next_buffer(struct psc_i2s_stream *s)
+static void psc_dma_bcom_enqueue_next_buffer(struct psc_dma_stream *s)
{
struct bcom_bd *bd;
@@ -82,9 +82,9 @@ static void psc_i2s_bcom_enqueue_next_buffer(struct
psc_i2s_stream *s)
}
/* Bestcomm DMA irq handler */
-static irqreturn_t psc_i2s_bcom_irq(int irq, void *_psc_i2s_stream)
+static irqreturn_t psc_dma_bcom_irq(int irq, void *_psc_dma_stream)
{
- struct psc_i2s_stream *s = _psc_i2s_stream;
+ struct psc_dma_stream *s = _psc_dma_stream;
/* For each finished period, dequeue the completed period buffer
* and enqueue a new one in it's place. */
@@ -93,7 +93,7 @@ static irqreturn_t psc_i2s_bcom_irq(int irq, void
*_psc_i2s_stream)
s->period_current_pt += s->period_bytes;
if (s->period_current_pt >= s->period_end)
s->period_current_pt = s->period_start;
- psc_i2s_bcom_enqueue_next_buffer(s);
+ psc_dma_bcom_enqueue_next_buffer(s);
bcom_enable(s->bcom_task);
}
@@ -106,39 +106,39 @@ static irqreturn_t psc_i2s_bcom_irq(int irq, void
*_psc_i2s_stream)
}
/**
- * psc_i2s_startup: create a new substream
+ * 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_i2s_startup(struct snd_pcm_substream *substream,
+int psc_dma_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
- struct psc_i2s *psc_i2s = rtd->dai->cpu_dai->private_data;
+ struct psc_dma *psc_dma = rtd->dai->cpu_dai->private_data;
int rc;
- dev_dbg(psc_i2s->dev, "psc_i2s_startup(substream=%p)\n", substream);
+ dev_dbg(psc_dma->dev, "psc_dma_startup(substream=%p)\n", substream);
- if (!psc_i2s->playback.active &&
- !psc_i2s->capture.active) {
+ if (!psc_dma->playback.active &&
+ !psc_dma->capture.active) {
/* Setup the IRQs */
- rc = request_irq(psc_i2s->irq, &psc_i2s_status_irq, IRQF_SHARED,
-"psc-i2s-status", psc_i2s);
- rc |= request_irq(psc_i2s->capture.irq,
- &psc_i2s_bcom_irq, IRQF_SHARED,
- "psc-i2s-capture", &psc_i2s->capture);
- rc |= request_irq(psc_i2s->playback.irq,
- &psc_i2s_bcom_irq, IRQF_SHARED,
- "psc-i2s-playback", &psc_i2s->playback);
+ rc = request_irq(psc_dma->irq, &ps
[PATCH V2 2/9] Basic split of mpc5200 DMA code out from mpc5200_psc_i2s
Basic split of mpc5200 DMA code out from i2s into a standalone file.
Signed-off-by: Jon Smirl
---
sound/soc/fsl/Kconfig |4
sound/soc/fsl/Makefile |2
sound/soc/fsl/mpc5200_dma.c | 458 +
sound/soc/fsl/mpc5200_dma.h | 81 +++
sound/soc/fsl/mpc5200_psc_i2s.c | 485 ---
5 files changed, 547 insertions(+), 483 deletions(-)
create mode 100644 sound/soc/fsl/mpc5200_dma.c
create mode 100644 sound/soc/fsl/mpc5200_dma.h
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 9fc9082..dc79bdf 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -1,5 +1,8 @@
config SND_SOC_OF_SIMPLE
tristate
+
+config SND_MPC52xx_DMA
+ tristate
# ASoC platform support for the Freescale MPC8610 SOC. This compiles drivers
# for the SSI and the Elo DMA controller. You will still need to select
@@ -23,6 +26,7 @@ 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
Say Y here to support the MPC5200 PSCs in I2S mode.
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index f85134c..7731ef2 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -10,5 +10,7 @@ snd-soc-fsl-ssi-objs := fsl_ssi.o
snd-soc-fsl-dma-objs := fsl_dma.o
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
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
new file mode 100644
index 000..4bae8d6
--- /dev/null
+++ b/sound/soc/fsl/mpc5200_dma.c
@@ -0,0 +1,458 @@
+/*
+ * Freescale MPC5200 PSC DMA
+ * ALSA SoC Platform driver
+ *
+ * Copyright (C) 2008 Secret Lab Technologies Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "mpc5200_dma.h"
+
+MODULE_AUTHOR("Grant Likely ");
+MODULE_DESCRIPTION("Freescale MPC5200 PSC in DMA mode ASoC Driver");
+MODULE_LICENSE("GPL");
+
+/*
+ * Interrupt handlers
+ */
+static irqreturn_t psc_i2s_status_irq(int irq, void *_psc_i2s)
+{
+ struct psc_i2s *psc_i2s = _psc_i2s;
+ struct mpc52xx_psc __iomem *regs = psc_i2s->psc_regs;
+ u16 isr;
+
+ isr = in_be16(®s->mpc52xx_psc_isr);
+
+ /* Playback underrun error */
+ if (psc_i2s->playback.active && (isr & MPC52xx_PSC_IMR_TXEMP))
+ psc_i2s->stats.underrun_count++;
+
+ /* Capture overrun error */
+ if (psc_i2s->capture.active && (isr & MPC52xx_PSC_IMR_ORERR))
+ psc_i2s->stats.overrun_count++;
+
+ out_8(®s->command, 4 << 4); /* reset the error status */
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * psc_i2s_bcom_enqueue_next_buffer - Enqueue another audio buffer
+ * @s: pointer to stream private data structure
+ *
+ * Enqueues another audio period buffer into the bestcomm queue.
+ *
+ * Note: The routine must only be called when there is space available in
+ * the queue. Otherwise the enqueue will fail and the audio ring buffer
+ * will get out of sync
+ */
+static void psc_i2s_bcom_enqueue_next_buffer(struct psc_i2s_stream *s)
+{
+ struct bcom_bd *bd;
+
+ /* Prepare and enqueue the next buffer descriptor */
+ bd = bcom_prepare_next_buffer(s->bcom_task);
+ bd->status = s->period_bytes;
+ bd->data[0] = s->period_next_pt;
+ bcom_submit_next_buffer(s->bcom_task, NULL);
+
+ /* Update for next period */
+ s->period_next_pt += s->period_bytes;
+ if (s->period_next_pt >= s->period_end)
+ s->period_next_pt = s->period_start;
+}
+
+/* Bestcomm DMA irq handler */
+static irqreturn_t psc_i2s_bcom_irq(int irq, void *_psc_i2s_stream)
+{
+ struct psc_i2s_stream *s = _psc_i2s_stream;
+
+ /* 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_i2s_bcom_enqueue_next_buffer(s);
+ bcom_enable(s->bcom_task);
+ }
+
+ /* If the stream is active, then also inform the PCM middle layer
+* of the period finished event. */
+ if (s->active)
+ snd_pcm_period_elapsed(s->stream);
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * psc_i2s_startup: create a new substream
+ *
+ * This is the first function called when a stream is open
[PATCH V2 1/9] Register the wm9712 DAIs on module load
Register the wm9712 DAIs on module load
Signed-off-by: Jon Smirl
---
0 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/wm9712.c b/sound/soc/codecs/wm9712.c
index 1fd4e88..49ad987 100644
--- a/sound/soc/codecs/wm9712.c
+++ b/sound/soc/codecs/wm9712.c
@@ -742,6 +742,18 @@ struct snd_soc_codec_device soc_codec_dev_wm9712 = {
};
EXPORT_SYMBOL_GPL(soc_codec_dev_wm9712);
+static int __init wm9712_modinit(void)
+{
+ return snd_soc_register_dais(wm9712_dai, ARRAY_SIZE(wm9712_dai));
+}
+module_init(wm9712_modinit);
+
+static void __exit wm9712_exit(void)
+{
+ snd_soc_unregister_dais(wm9712_dai, ARRAY_SIZE(wm9712_dai));
+}
+module_exit(wm9712_exit);
+
MODULE_DESCRIPTION("ASoC WM9711/WM9712 driver");
MODULE_AUTHOR("Liam Girdwood");
MODULE_LICENSE("GPL");
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH V2 0/9] mpc5200 audio rework for AC97
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. Mark is not enthused about soc-of-simple.c so rather than extend it for AC97 I altered the drivers to not use it. Instead they use the old way of manually binding everything. Mark would like to see OF binding more closely integrated to the core. Once a proper solution for OF binding is agreed upon it is easy to convert the existing drivers. A first step would be converting the existing codec drivers so that they can be dynamically loaded. Grant, please check over the spin locking on register access. I'm not clear on why and when the registers have to be protected. Once these basic drivers are in-kernel and more people are testing them, I can add more features like pause/resume, power management, etc based on feedback. I2S will get examined in more detail for the next kernel cycle. Our multi-channel prototype I2S hardware is just about working. Once I get the multi-channel hardware I will implement and heavily test a lot more I2S capability. --- Jon Smirl (9): Support for AC97 on Phytec pmc030 base board. Fabric bindings for STAC9766 on the Efika AC97 driver for mpc5200 Codec for STAC9766 used on the Efika Main rewite of the mpc5200 audio DMA code Add a few more mpc5200 PSC defines Rename the PSC functions to DMA Basic split of mpc5200 DMA code out from mpc5200_psc_i2s Register the wm9712 DAIs on module load sound/soc/fsl/Kconfig | 31 + sound/soc/fsl/Makefile |7 sound/soc/fsl/efika-audio-fabric.c | 94 sound/soc/fsl/mpc5200_dma.c | 635 ++ sound/soc/fsl/mpc5200_dma.h | 80 sound/soc/fsl/mpc5200_psc_ac97.c| 394 ++ sound/soc/fsl/mpc5200_psc_ac97.h| 15 + sound/soc/fsl/mpc5200_psc_i2s.c | 750 ++- sound/soc/fsl/mpc5200_psc_i2s.h | 12 + sound/soc/fsl/pcm030-audio-fabric.c | 94 10 files changed, 1414 insertions(+), 698 deletions(-) create mode 100644 sound/soc/fsl/efika-audio-fabric.c create mode 100644 sound/soc/fsl/mpc5200_dma.c create mode 100644 sound/soc/fsl/mpc5200_dma.h 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
Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
Hello, On Sat, May 23, 2009 at 1:55 AM, Jeremy Fitzhardinge wrote: > Ian Campbell wrote: >> >> On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote: >> >>> >>> I can work with that, but it's going to be a bit inefficient, as I >>> actually need the dma_addr_t, not the phys_addr_t, so I'll have to >>> convert. In every case, this is a conversion I've already done and that I >>> need in the calling code as well. >> >> Does >> >> dma_addr_t dma_map_range(struct device *hwdev, phys_addr_t addr, >> size_t size); >> >> work for you? >> >> If the range does not need mapping then it returns the dma address, if >> you needed to calculate the dma address anyway to figure out if mapping >> is required then this is fine. If the range does need mapping then it >> returns NULL. >> > > My only concern is whether dma_addr_t == 0 is actually equivalent to NULL. > That is, can we be sure that address 0 will never be used? > Indeed, I remember seeing 0 returned on pci_alloc_coherent() as an address (cookie). Regards, -- Leon ___ 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 Sat, May 23, 2009 at 10:58 PM, Leon Woestenberg
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
I found that the DTS for the MPC8315E-RDB is missing the msi bits. I
added these, converted from the BSP (in old non-hex format):
ipic-...@7c0 {
compatible = "fsl,ipic-msi";
reg = <0x7c0 0x40>;
msi-available-ranges = <0 0x100>;
interrupts = < 0x43 8
0x4 8
0x51 8
0x52 8
0x56 8
0x57 8
0x58 8
0x59 8 >;
interrupt-parent = < &ipic >;
};
Now the MSI stuff gets set-up, pci_enable_msi() does not fault. My
interrupt handler is still not called though.
Partial log below:
[ 246.907366] Setting up Freescale MSI support
[ 247.858192] irq: irq 67 on host
/i...@e000/interrupt-control...@700 mapped to virtual irq 67
[ 249.323654] irq: irq 4 on host
/i...@e000/interrupt-control...@700 mapped to virtual irq 21
[ 250.779210] irq: irq 81 on host
/i...@e000/interrupt-control...@700 mapped to virtual irq 81
[ 252.244662] irq: irq 82 on host
/i...@e000/interrupt-control...@700 mapped to virtual irq 82
[ 253.710192] irq: irq 86 on host
/i...@e000/interrupt-control...@700 mapped to virtual irq 86
[ 255.175651] irq: irq 87 on host
/i...@e000/interrupt-control...@700 mapped to virtual irq 87
[ 256.641100] irq: irq 88 on host
/i...@e000/interrupt-control...@700 mapped to virtual irq 88
[ 258.106549] irq: irq 89 on host
/i...@e000/interrupt-control...@700 mapped to virtual irq 89
[ 309.396138] pci_enable_msi()
[ 309.399735] irq: irq 0 on host /i...@e000/ipic-...@7c0 mapped
to virtual irq 24
[ 309.408030] fsl_compose_msi_msg: allocated srs: 0, ibs: 0
[ 309.414160] Enabled MSI interrupting.
[ 309.418449] pci_read_config_byte(..., PCI_REVISION_ID, ...)
[ 309.424754] Board revision: 0x01.
[ 309.428690] pci_request_regions()
[ 309.432654] pci_set_dma_mask()
[ 309.436337] Using a 64-bit DMA mask.
[ 309.455605] request_irq()
[ 309.458925] Succesfully requested IRQ #24 with dev_id 0xc71c5440
debugfs shows:
virq hwirqchip namehost name
17 0x9 IPIC/i...@e000/interrupt-control...@700
22 0x00010 IPIC/i...@e000/interrupt-control...@700
23 0xe IPIC/i...@e000/interrupt-control...@700
24 0x0 FSL-MSI /i...@e000/ipic-...@7c0
32 0x00020 IPIC/i...@e000/interrupt-control...@700
33 0x00021 IPIC/i...@e000/interrupt-control...@700
34 0x00022 IPIC/i...@e000/interrupt-control...@700
35 0x00023 IPIC/i...@e000/interrupt-control...@700
36 0x00024 IPIC/i...@e000/interrupt-control...@700
37 0x00025 IPIC/i...@e000/interrupt-control...@700
38 0x00026 IPIC/i...@e000/interrupt-control...@700
Regards, Leon.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC405EX based irq flooding with USB-OTG and usbserial device
On Sat, May 23, 2009 at 1:14 PM, Wolfgang Denk wrote: > Dear Hunter, > > In message > you wrote: > > > > This is my first post to the PPC dev list as my company has just started > > developing a new project based on Linux. The good news is, this post is > not > > debug-related as much as it is an introduction and query while I download > > the latest DENX kernel(only place I know that has the DWC_OTG driver). > > there is a strong reason why we decided not to try to push this > driver upstream: it is not in a state that would have a chance for > being accepted for mainline. The problems you are experiencing are > probably not the only one. Please consider this driver as > unsupported. > > 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 > "Ada is PL/I trying to be Smalltalk. - Codoso diBlini > Which leads me to another question. Since I should consider this unsupported, is there a better driver out there as my company is already well down the road with our design? Or would you recommend just creating our own driver for the USB-OTG? I'm developing with the Kilauea, and I guess I should ask how unstable is Linux support for this Processor. -- Hunter Cobbs ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC405EX based irq flooding with USB-OTG and usbserial device
Dear Hunter, In message you wrote: > > This is my first post to the PPC dev list as my company has just started > developing a new project based on Linux. The good news is, this post is not > debug-related as much as it is an introduction and query while I download > the latest DENX kernel(only place I know that has the DWC_OTG driver). there is a strong reason why we decided not to try to push this driver upstream: it is not in a state that would have a chance for being accepted for mainline. The problems you are experiencing are probably not the only one. Please consider this driver as unsupported. 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 "Ada is PL/I trying to be Smalltalk. - Codoso diBlini ___ 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 Friday 22 May 2009, Wolfgang Grandegger wrote:
>> This patch adds a generic driver for SJA1000 chips on the OpenFirmware
>> platform bus found on embedded PowerPC systems.
>
> Nice driver!
>
>> +static u8 sja1000_ofp_read_reg(const struct net_device *dev, int reg)
>> +{
>> +return in_8((void __iomem *)(dev->base_addr + reg));
>> +}
>> +
>> +static void sja1000_ofp_write_reg(const struct net_device *dev, int reg, u8
>> val)
>> +{
>> +out_8((void __iomem *)(dev->base_addr + reg), val);
>> +}
>
> 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.
Wolfgang.
___
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
Wolfgang Grandegger wrote: > Hi Grant, > > Grant Likely wrote: >> Hi Wolfgang, thanks for the quick response. Comments below... >> >> On Fri, May 22, 2009 at 8:46 AM, Wolfgang Grandegger >> wrote: >>> +++ net-next-2.6/Documentation/powerpc/dts-bindings/can/sja1000.txt >>> @@ -0,0 +1,37 @@ >>> +Memory mapped SJA1000 CAN controller from NXP (formerly Philips) >>> + >>> +Required properties: >>> + >>> +- compatible : should be "nxp,sja1000". >>> +- reg : should specify the chip select, address offset and size used >>> + for the chip depending on the bus it is connected to. >>> +- interrupts: property with a value describing the interrupt source >>> + (number and sensitivity) for that device. The encoding depends >>> + on the type of interrupt controller used. >> Hmmm, "reg", "interrupts", and "interrupt-parent" are well understood >> properties. I don't think we need to keep boilerplate defining the >> meaning every time a new binding is added. (general musing; not an >> ack or nack of this patch) > > OK. > >> However, what should be defined is *what* the register range is (ie. >> one tuple; location of device registers), and what the interrupts are >> (ie. single tuple for device's irq line). Granted this is a trivial >> case, but in the case of devices with more than one address range or >> irq line, the meaning of each tuple is critical information. I think >> it would be a good pattern to establish. > > Sounds reasonable. > >>> +Optional properties: >>> + >>> +- interrupt-parent : the phandle for the interrupt controller that >>> + services interrupts for that device. >> Thinking further; I wouldn't even mention "interrupt-parent" here. >> Anyone working with this stuff must already understand irq routing. > > OK, I will remove it. > >>> +- 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. > >>> +- 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. Would the following more descriptive properties be OK? clock-out-frequency = <0>, // CLKOUT pin clock off = <400>; // frequency on CLKOUT pin 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 Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC405EX based irq flooding with USB-OTG and usbserial device
OK, here are the patches... one for ppc4xx_dma.h and one for the Makefile --- ppc4xx_dma.h snip --- linux-2.6-denx/drivers/usb/gadget/dwc_otg/ppc4xx_dma.h2008-05-07 09:13:33.0 -0500 +++ linux-2.6-denx_patched/drivers/usb/gadget/dwc_otg/ppc4xx_dma.h 2009-05-23 08:33:26.17250 -0500 @@ -84,8 +84,13 @@ * DMA Channel Control Registers */ -#if defined(CONFIG_44x) || defined(CONFIG_405EX) || defined(CONFIG_405EXr) +/* The PPC44x series has a 64Bit DMA */ +#if defined(CONFIG_44x) #definePPC4xx_DMA_64BIT +#endif + +/* The PPC44x and PPC405EX/r have a reserved bit in DMA control register*/ +#if defined(CONFIG_44x) || defined(CONFIG_405EX) || defined(CONFIG_405EXr) #define DMA_CR_OFFSET 1 #else #define DMA_CR_OFFSET 0 - end snip --- - Makefile snip -- --- linux-2.6-denx/drivers/usb/gadget/dwc_otg/Makefile2008-05-07 09:13:33.0 -0500 +++ linux-2.6-denx_patched/drivers/usb/gadget/dwc_otg/Makefile2009-05-23 08:38:04.18250 -0500 @@ -22,7 +22,7 @@ #KBUILD_CPPFLAGS+= -DOTG_EXT_CHG_PUMP # PLB DMA mode -KBUILD_CPPFLAGS+= -Dlinux -DDWC_SLAVE -DOTG_PLB_DMA -DOTG_PLB_DMA_TASKLET #-DDWC_DEVICE_ONLY # -DDWC_HS_ELECT_TST -DDWC_SLAVE -DDWC_HOST_ONLY +KBUILD_CPPFLAGS+= -Dlinux -DOTG_PLB_DMA -DOTG_PLB_DMA_TASKLET endif ifeq ($(CONFIG_460EX),y) - end snip --- On Sat, May 23, 2009 at 7:44 AM, Hunter Cobbs wrote: > Egads! Forgot to respond to the list! > > My git checkout failed last night, so I'm downloading the resource cd, but > I can tell you what I did before I get the actual patch done, and you can > tell me if my logic is sound. > > First thing I thought when I saw this is WHY use IRQ based methods to > access a USB controller with internal DMA transfers? I tried in vain to > enable this with the driver module parameters(which I dug up how to specify > module parameters to built-in drivers from an old 2.2-series kernel > discussion). So, then I put on my boots and started slogging throught the > driver. > > Getting frustrated with that line of execution, I turned up the verbosity > on the kernel compile and noticed a warning in the dwc_otg compilation. > Specifically that a left and right shift go out of bounds of the variables > used. The only place this occurs is in a section of code that is wrapped > with DMA_64BIT. Which made absolutely no sense because the DMA controller > on the 405EX is only 32 bits wide. On tracking this define down, I come to > find out that someone made the assumption that the 44x and the 405EX/r all > have the same DMA controller. Which is incorrect, they both have the same > control register definitions(the offset of 1 due to the MSBit being reserved > and the register being in Big Endian mode); however, the 44x is 64bits and > the 405 is 32bits. So, I broke the DMA control down into two areas, > data-width and control register offsets. > > When this still didn't fix the problem, I found yet another section that > can force you to operate in slave(irq) mode only wrapped in yet another > define. When I search out that define (DWC_SLAVE I believe), I find it in > the dwc_otg Makefile. > > Correcting both of these has enabled full DMA access to the USB, and I'm > doing much better with my sierra wireless dev kit. > > On Sat, May 23, 2009 at 7:11 AM, Chuck Meade wrote: > >> Hunter Cobbs wrote: >> > Hello everyone, >> > >> > This is my first post to the PPC dev list as my company has just started >> > developing a new project based on Linux. The good news is, this post is >> > not debug-related as much as it is an introduction and query while I >> > download the latest DENX kernel(only place I know that has the DWC_OTG >> > driver). >> > >> > I've been working with a Kilauea dev board and have had lots of trouble >> > when I plug in a sierra-wireless modem dev kit on the USB. It goes fine >> > untill I actually try to communicate(pppd or minicom) with the little >> > bugger and then my IRQs go through the roof. And they only calm back >> > down after I shut down my communicaiton channel. >> > >> > I've solved this issue with our board, and was wondering if it has since >> > been fixed (I'm running 2.6.25-DENX). I don't want to waste the board's >> > time with a patch that is no longer necesarry. >> > >> > -- >> > Hunter Cobbs >> >> Hello Hunter, >> >> It would absolutely *not* be a waste of anyone's time. I for one would >> like >> to see how you solved this. I am dealing with the same problem, with the >> same >> setup. >> >> The underlying cause for this problem is the PPC405EX CPU's erratum >> USBO_9. >> The USB 2.0 PING protocol is supposed to handle a PING transaction in >> the hardware -- note that in USB 2.0, a PING is the method used by the >> sender to >> determine if it can send. If I remember correctly, erratum USBO_9 is >> caused when >> a NAK response from the PING transaction is handled not in hardware, but >> instead >> as an int
Re: PPC405EX based irq flooding with USB-OTG and usbserial device
Egads! Forgot to respond to the list! My git checkout failed last night, so I'm downloading the resource cd, but I can tell you what I did before I get the actual patch done, and you can tell me if my logic is sound. First thing I thought when I saw this is WHY use IRQ based methods to access a USB controller with internal DMA transfers? I tried in vain to enable this with the driver module parameters(which I dug up how to specify module parameters to built-in drivers from an old 2.2-series kernel discussion). So, then I put on my boots and started slogging throught the driver. Getting frustrated with that line of execution, I turned up the verbosity on the kernel compile and noticed a warning in the dwc_otg compilation. Specifically that a left and right shift go out of bounds of the variables used. The only place this occurs is in a section of code that is wrapped with DMA_64BIT. Which made absolutely no sense because the DMA controller on the 405EX is only 32 bits wide. On tracking this define down, I come to find out that someone made the assumption that the 44x and the 405EX/r all have the same DMA controller. Which is incorrect, they both have the same control register definitions(the offset of 1 due to the MSBit being reserved and the register being in Big Endian mode); however, the 44x is 64bits and the 405 is 32bits. So, I broke the DMA control down into two areas, data-width and control register offsets. When this still didn't fix the problem, I found yet another section that can force you to operate in slave(irq) mode only wrapped in yet another define. When I search out that define (DWC_SLAVE I believe), I find it in the dwc_otg Makefile. Correcting both of these has enabled full DMA access to the USB, and I'm doing much better with my sierra wireless dev kit. On Sat, May 23, 2009 at 7:11 AM, Chuck Meade wrote: > Hunter Cobbs wrote: > > Hello everyone, > > > > This is my first post to the PPC dev list as my company has just started > > developing a new project based on Linux. The good news is, this post is > > not debug-related as much as it is an introduction and query while I > > download the latest DENX kernel(only place I know that has the DWC_OTG > > driver). > > > > I've been working with a Kilauea dev board and have had lots of trouble > > when I plug in a sierra-wireless modem dev kit on the USB. It goes fine > > untill I actually try to communicate(pppd or minicom) with the little > > bugger and then my IRQs go through the roof. And they only calm back > > down after I shut down my communicaiton channel. > > > > I've solved this issue with our board, and was wondering if it has since > > been fixed (I'm running 2.6.25-DENX). I don't want to waste the board's > > time with a patch that is no longer necesarry. > > > > -- > > Hunter Cobbs > > Hello Hunter, > > It would absolutely *not* be a waste of anyone's time. I for one would > like > to see how you solved this. I am dealing with the same problem, with the > same > setup. > > The underlying cause for this problem is the PPC405EX CPU's erratum USBO_9. > The USB 2.0 PING protocol is supposed to handle a PING transaction in > the hardware -- note that in USB 2.0, a PING is the method used by the > sender to > determine if it can send. If I remember correctly, erratum USBO_9 is > caused when > a NAK response from the PING transaction is handled not in hardware, but > instead > as an interrupt in software, and that NAK leads to a lot of processing. In > the > 2.6.25 Denx Linux tree that I used, that processing ends up trying to > restart the > channel, restart the send, which leads to yet another PING/NAK sequence, > yet another > interrupt... > > The end result is that you get over 100,000 interrupts (with significant > interrupt > handling logic) per second, and the target can't do anything else. I was > able > to get this interrupt count by looking at /proc/interrupts, then causing > this problem > for 20 seconds, then pulling out the USB modem physically (mine is on a > Express card) > to stop the interrupt storm, then checking /proc/interrupts again. > Averaged over > 100,000 ints/sec. > > In contact with AMCC, they told us they are not respinning the CPU (at > least not > at this time) to fix this erratum. > > I have tried to solve the problem as suggested by the erratum, by not > allowing the > NAK interrupt handling to *directly* cause a retry of the send, but rather > to wait > until the next SOF interrupt (start of microframe, which happens 8,000 > times per sec) > to restart it. "Breaking the chain" like this does allow the board to > proceed, but > I think it is suboptimal, or at least unfortunate. > > One painful side effect of this workaround is that you cannot disable the > 8,000 SOF > interrupts/second, or at least some of them, since they are being used now > for another > purpose -- recovery from the erratum. > > The 8000 SOF ints being handled per second do cause a measurable drain on > the > CPU
Re: PPC405EX based irq flooding with USB-OTG and usbserial device
Hunter Cobbs wrote: > Hello everyone, > > This is my first post to the PPC dev list as my company has just started > developing a new project based on Linux. The good news is, this post is > not debug-related as much as it is an introduction and query while I > download the latest DENX kernel(only place I know that has the DWC_OTG > driver). > > I've been working with a Kilauea dev board and have had lots of trouble > when I plug in a sierra-wireless modem dev kit on the USB. It goes fine > untill I actually try to communicate(pppd or minicom) with the little > bugger and then my IRQs go through the roof. And they only calm back > down after I shut down my communicaiton channel. > > I've solved this issue with our board, and was wondering if it has since > been fixed (I'm running 2.6.25-DENX). I don't want to waste the board's > time with a patch that is no longer necesarry. > > -- > Hunter Cobbs Hello Hunter, It would absolutely *not* be a waste of anyone's time. I for one would like to see how you solved this. I am dealing with the same problem, with the same setup. The underlying cause for this problem is the PPC405EX CPU's erratum USBO_9. The USB 2.0 PING protocol is supposed to handle a PING transaction in the hardware -- note that in USB 2.0, a PING is the method used by the sender to determine if it can send. If I remember correctly, erratum USBO_9 is caused when a NAK response from the PING transaction is handled not in hardware, but instead as an interrupt in software, and that NAK leads to a lot of processing. In the 2.6.25 Denx Linux tree that I used, that processing ends up trying to restart the channel, restart the send, which leads to yet another PING/NAK sequence, yet another interrupt... The end result is that you get over 100,000 interrupts (with significant interrupt handling logic) per second, and the target can't do anything else. I was able to get this interrupt count by looking at /proc/interrupts, then causing this problem for 20 seconds, then pulling out the USB modem physically (mine is on a Express card) to stop the interrupt storm, then checking /proc/interrupts again. Averaged over 100,000 ints/sec. In contact with AMCC, they told us they are not respinning the CPU (at least not at this time) to fix this erratum. I have tried to solve the problem as suggested by the erratum, by not allowing the NAK interrupt handling to *directly* cause a retry of the send, but rather to wait until the next SOF interrupt (start of microframe, which happens 8,000 times per sec) to restart it. "Breaking the chain" like this does allow the board to proceed, but I think it is suboptimal, or at least unfortunate. One painful side effect of this workaround is that you cannot disable the 8,000 SOF interrupts/second, or at least some of them, since they are being used now for another purpose -- recovery from the erratum. The 8000 SOF ints being handled per second do cause a measurable drain on the CPU. In some cursory testing we see a 10% slowdown of certain transactions in lmbench. So please send me your patch for the dwc_otg driver. I am very interested in what you did, and if it perhaps is a better solution for the problem we both are seeing than what I implemented. Thanks in advance, Chuck ___ 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 Friday 22 May 2009, Wolfgang Grandegger wrote:
> This patch adds a generic driver for SJA1000 chips on the OpenFirmware
> platform bus found on embedded PowerPC systems.
Nice driver!
> +static u8 sja1000_ofp_read_reg(const struct net_device *dev, int reg)
> +{
> + return in_8((void __iomem *)(dev->base_addr + reg));
> +}
> +
> +static void sja1000_ofp_write_reg(const struct net_device *dev, int reg, u8
> val)
> +{
> + out_8((void __iomem *)(dev->base_addr + reg), val);
> +}
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.
Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
