May 2009 - Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] [PATCH] TXx9: Add ACLC support
by Atsushi Nemoto 15 May '09

15 May '09

On Fri, 15 May 2009 15:45:36 +0200 (CEST), Geert Uytterhoeven <Geert.Uytterhoeven(a)sonycom.com> wrote: > > Add platform support for ACLC of TXx9 SoCs. > > I gave it a try on my RBTX4927, and after some fight^H^H^H^H^Hplaying with the > alsa tools, I could play sound using `speaker-test --test wav --channels 2'! Good news! Thanks for your trial. --- Atsushi Nemoto

1 0

[alsa-devel] Should snd_pcm_drop() interrupt snd_pcm_writei() call?
by Marek Peca 15 May '09

15 May '09

Hello, I would like to know, how should snd_pcm_drop() call influence snd_pcm_writei() being simultaneously executed. I expected, that after issuing snd_pcm_drop() (from another thread), the snd_pcm_write*() in progress should be terminated almost immediately with some return value (error or short write). According to my observation, this seem to work on ALSA lib & driver 1.0.14rc3, snd_ali5451. However, it never or almost never works on another machine with ALSA lib 1.0.16 (Debian package libasound2 [1.0.16-2], driver unknown, sorry). There, the snd_pcm_write*() _never_returns_ after snd_pcm_drop(), and remain stuck forever. I would like to ask you, which behaviour of snd_pcm_drop/snd_pcm_write* is the correct one. I suppose the snd_pcm_write*() should be interrupted, otherwise, an extra thread would be needed in many applications. However, I don't know, why does not it work in the later version of ALSA. I have not found the answer in Doxygen, and since I am real ALSA newbie, I gave up reading ALSA source, especially because I have seen different behaviour among two different versions. Excuse my impatience. Thank you for a clarification. Best regards, Marek.

2 5

[alsa-devel] [PATCH] parisc/harmony: fix printk format warning
by Alexander Beregalov 15 May '09

15 May '09

Fix this warning: sound/parisc/harmony.c:938: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'resource_size_t' Signed-off-by: Alexander Beregalov <a.beregalov(a)gmail.com> --- sound/parisc/harmony.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/parisc/harmony.c b/sound/parisc/harmony.c index 6055fd6..63ae0f9 100644 --- a/sound/parisc/harmony.c +++ b/sound/parisc/harmony.c @@ -935,7 +935,7 @@ snd_harmony_create(struct snd_card *card, h->iobase = ioremap_nocache(padev->hpa.start, HARMONY_SIZE); if (h->iobase == NULL) { printk(KERN_ERR PFX "unable to remap hpa 0x%lx\n", - padev->hpa.start); + (unsigned long)padev->hpa.start); err = -EBUSY; goto free_and_ret; } -- 1.6.2.5

2 1

[alsa-devel] [PATCH] TXx9: Add ACLC support
by Atsushi Nemoto 15 May '09

15 May '09

Add platform support for ACLC of TXx9 SoCs. Signed-off-by: Atsushi Nemoto <anemo(a)mba.ocn.ne.jp> --- This patch depends on txx9dmac patch (platform) in linux-mips queue tree or linux-next tree. arch/mips/include/asm/txx9/generic.h | 5 ++++ arch/mips/include/asm/txx9/tx4927.h | 2 + arch/mips/include/asm/txx9/tx4938.h | 1 + arch/mips/include/asm/txx9/tx4939.h | 1 + arch/mips/txx9/Kconfig | 3 ++ arch/mips/txx9/generic/setup.c | 36 +++++++++++++++++++++++++++ arch/mips/txx9/generic/setup_tx4927.c | 43 +++++++++++++++++++++++++++++++++ arch/mips/txx9/generic/setup_tx4938.c | 11 ++++++++ arch/mips/txx9/generic/setup_tx4939.c | 9 +++++++ arch/mips/txx9/rbtx4927/setup.c | 7 ++++- arch/mips/txx9/rbtx4938/setup.c | 1 + arch/mips/txx9/rbtx4939/setup.c | 1 + 12 files changed, 118 insertions(+), 2 deletions(-) diff --git a/arch/mips/include/asm/txx9/generic.h b/arch/mips/include/asm/txx9/generic.h index 9cde009..8169477 100644 --- a/arch/mips/include/asm/txx9/generic.h +++ b/arch/mips/include/asm/txx9/generic.h @@ -91,4 +91,9 @@ void txx9_7segled_init(unsigned int num, void (*putc)(unsigned int pos, unsigned char val)); int txx9_7segled_putc(unsigned int pos, char c); +void __init txx9_aclc_init(unsigned long baseaddr, int irq, + unsigned int dmac_id, + unsigned int dma_chan_out, + unsigned int dma_chan_in); + #endif /* __ASM_TXX9_GENERIC_H */ diff --git a/arch/mips/include/asm/txx9/tx4927.h b/arch/mips/include/asm/txx9/tx4927.h index d92ae07..18c98c5 100644 --- a/arch/mips/include/asm/txx9/tx4927.h +++ b/arch/mips/include/asm/txx9/tx4927.h @@ -50,6 +50,7 @@ #define TX4927_NR_SIO 2 #define TX4927_SIO_REG(ch) (TX4927_REG_BASE + 0xf300 + (ch) * 0x100) #define TX4927_PIO_REG (TX4927_REG_BASE + 0xf500) +#define TX4927_ACLC_REG (TX4927_REG_BASE + 0xf700) #define TX4927_IR_ECCERR 0 #define TX4927_IR_WTOERR 1 @@ -267,5 +268,6 @@ void tx4927_setup_pcierr_irq(void); void tx4927_irq_init(void); void tx4927_mtd_init(int ch); void tx4927_dmac_init(int memcpy_chan); +void tx4927_aclc_init(unsigned int dma_chan_out, unsigned int dma_chan_in); #endif /* __ASM_TXX9_TX4927_H */ diff --git a/arch/mips/include/asm/txx9/tx4938.h b/arch/mips/include/asm/txx9/tx4938.h index 0758a0c..54e4674 100644 --- a/arch/mips/include/asm/txx9/tx4938.h +++ b/arch/mips/include/asm/txx9/tx4938.h @@ -306,5 +306,6 @@ struct tx4938ide_platform_info { void tx4938_ata_init(unsigned int irq, unsigned int shift, int tune); void tx4938_dmac_init(int memcpy_chan0, int memcpy_chan1); +void tx4938_aclc_init(void); #endif diff --git a/arch/mips/include/asm/txx9/tx4939.h b/arch/mips/include/asm/txx9/tx4939.h index 1be9798..f13b708 100644 --- a/arch/mips/include/asm/txx9/tx4939.h +++ b/arch/mips/include/asm/txx9/tx4939.h @@ -545,5 +545,6 @@ void tx4939_rtc_init(void); void tx4939_ndfmc_init(unsigned int hold, unsigned int spw, unsigned char ch_mask, unsigned char wide_mask); void tx4939_dmac_init(int memcpy_chan0, int memcpy_chan1); +void tx4939_aclc_init(void); #endif /* __ASM_TXX9_TX4939_H */ diff --git a/arch/mips/txx9/Kconfig b/arch/mips/txx9/Kconfig index 0db7cf3..852ae4b 100644 --- a/arch/mips/txx9/Kconfig +++ b/arch/mips/txx9/Kconfig @@ -69,6 +69,7 @@ config SOC_TX4927 select IRQ_TXX9 select PCI_TX4927 select GPIO_TXX9 + select HAS_TXX9_ACLC config SOC_TX4938 bool @@ -78,6 +79,7 @@ config SOC_TX4938 select IRQ_TXX9 select PCI_TX4927 select GPIO_TXX9 + select HAS_TXX9_ACLC config SOC_TX4939 bool @@ -85,6 +87,7 @@ config SOC_TX4939 select HAS_TXX9_SERIAL select HW_HAS_PCI select PCI_TX4927 + select HAS_TXX9_ACLC config TXX9_7SEGLED bool diff --git a/arch/mips/txx9/generic/setup.c b/arch/mips/txx9/generic/setup.c index 369d863..bc358ab 100644 --- a/arch/mips/txx9/generic/setup.c +++ b/arch/mips/txx9/generic/setup.c @@ -876,3 +876,39 @@ void __init txx9_dmac_init(int id, unsigned long baseaddr, int irq, } #endif } + +void __init txx9_aclc_init(unsigned long baseaddr, int irq, + unsigned int dmac_id, + unsigned int dma_chan_out, + unsigned int dma_chan_in) +{ +#if defined(CONFIG_SND_SOC_TXX9ACLC_GENERIC) || \ + defined(CONFIG_SND_SOC_TXX9ACLC_GENERIC_MODULE) + unsigned int dma_base = dmac_id * TXX9_DMA_MAX_NR_CHANNELS; + struct resource res[] = { + { + .start = baseaddr, + .end = baseaddr + 0x100 - 1, + .flags = IORESOURCE_MEM, + }, { + .start = irq, + .flags = IORESOURCE_IRQ, + }, { + .name = "txx9dmac-chan", + .start = dma_base + dma_chan_out, + .flags = IORESOURCE_DMA, + }, { + .name = "txx9dmac-chan", + .start = dma_base + dma_chan_in, + .flags = IORESOURCE_DMA, + } + }; + struct platform_device *pdev = + platform_device_alloc("txx9aclc-generic", -1); + + if (!pdev || + platform_device_add_resources(pdev, res, ARRAY_SIZE(res)) || + platform_device_add(pdev)) + platform_device_put(pdev); +#endif +} diff --git a/arch/mips/txx9/generic/setup_tx4927.c b/arch/mips/txx9/generic/setup_tx4927.c index 6b681cd..3418b2a 100644 --- a/arch/mips/txx9/generic/setup_tx4927.c +++ b/arch/mips/txx9/generic/setup_tx4927.c @@ -265,6 +265,49 @@ void __init tx4927_dmac_init(int memcpy_chan) TXX9_IRQ_BASE + TX4927_IR_DMA(0), &plat_data); } +void __init tx4927_aclc_init(unsigned int dma_chan_out, + unsigned int dma_chan_in) +{ + u64 pcfg = __raw_readq(&tx4927_ccfgptr->pcfg); + __u64 dmasel_mask = 0, dmasel = 0; + unsigned long flags; + + if (!(pcfg & TX4927_PCFG_SEL2)) + return; + /* setup DMASEL (playback:ACLC ch0, capture:ACLC ch1) */ + switch (dma_chan_out) { + case 0: + dmasel_mask |= TX4927_PCFG_DMASEL0_MASK; + dmasel |= TX4927_PCFG_DMASEL0_ACL0; + break; + case 2: + dmasel_mask |= TX4927_PCFG_DMASEL2_MASK; + dmasel |= TX4927_PCFG_DMASEL2_ACL0; + break; + default: + return; + } + switch (dma_chan_in) { + case 1: + dmasel_mask |= TX4927_PCFG_DMASEL1_MASK; + dmasel |= TX4927_PCFG_DMASEL1_ACL1; + break; + case 3: + dmasel_mask |= TX4927_PCFG_DMASEL3_MASK; + dmasel |= TX4927_PCFG_DMASEL3_ACL1; + break; + default: + return; + } + local_irq_save(flags); + txx9_clear64(&tx4927_ccfgptr->pcfg, dmasel_mask); + txx9_set64(&tx4927_ccfgptr->pcfg, dmasel); + local_irq_restore(flags); + txx9_aclc_init(TX4927_ACLC_REG & 0xfffffffffULL, + TXX9_IRQ_BASE + TX4927_IR_ACLC, + 0, dma_chan_out, dma_chan_in); +} + static void __init tx4927_stop_unused_modules(void) { __u64 pcfg, rst = 0, ckd = 0; diff --git a/arch/mips/txx9/generic/setup_tx4938.c b/arch/mips/txx9/generic/setup_tx4938.c index b2b8529..4dfdb52 100644 --- a/arch/mips/txx9/generic/setup_tx4938.c +++ b/arch/mips/txx9/generic/setup_tx4938.c @@ -414,6 +414,17 @@ void __init tx4938_dmac_init(int memcpy_chan0, int memcpy_chan1) } } +void __init tx4938_aclc_init(void) +{ + u64 pcfg = __raw_readq(&tx4938_ccfgptr->pcfg); + + if ((pcfg & TX4938_PCFG_SEL2) && + !(pcfg & TX4938_PCFG_ETH0_SEL)) + txx9_aclc_init(TX4938_ACLC_REG & 0xfffffffffULL, + TXX9_IRQ_BASE + TX4938_IR_ACLC, + 1, 0, 1); +} + static void __init tx4938_stop_unused_modules(void) { __u64 pcfg, rst = 0, ckd = 0; diff --git a/arch/mips/txx9/generic/setup_tx4939.c b/arch/mips/txx9/generic/setup_tx4939.c index 98effef..7139686 100644 --- a/arch/mips/txx9/generic/setup_tx4939.c +++ b/arch/mips/txx9/generic/setup_tx4939.c @@ -485,6 +485,15 @@ void __init tx4939_dmac_init(int memcpy_chan0, int memcpy_chan1) } } +void __init tx4939_aclc_init(void) +{ + u64 pcfg = __raw_readq(&tx4939_ccfgptr->pcfg); + + if ((pcfg & TX4939_PCFG_I2SMODE_MASK) == TX4939_PCFG_I2SMODE_ACLC) + txx9_aclc_init(TX4939_ACLC_REG & 0xfffffffffULL, + TXX9_IRQ_BASE + TX4939_IR_ACLC, 1, 0, 1); +} + static void __init tx4939_stop_unused_modules(void) { __u64 pcfg, rst = 0, ckd = 0; diff --git a/arch/mips/txx9/rbtx4927/setup.c b/arch/mips/txx9/rbtx4927/setup.c index 332cdbc..ece43db 100644 --- a/arch/mips/txx9/rbtx4927/setup.c +++ b/arch/mips/txx9/rbtx4927/setup.c @@ -337,10 +337,13 @@ static void __init rbtx4927_device_init(void) rbtx4927_ne_init(); tx4927_wdt_init(); rbtx4927_mtd_init(); - if (TX4927_REV_PCODE() == 0x4927) + if (TX4927_REV_PCODE() == 0x4927) { tx4927_dmac_init(2); - else + tx4927_aclc_init(0, 1); + } else { tx4938_dmac_init(0, 2); + tx4938_aclc_init(); + } txx9_iocled_init(RBTX4927_LED_ADDR - IO_BASE, -1, 3, 1, "green", NULL); rbtx4927_gpioled_init(); } diff --git a/arch/mips/txx9/rbtx4938/setup.c b/arch/mips/txx9/rbtx4938/setup.c index 37c5e3d..c0aa889 100644 --- a/arch/mips/txx9/rbtx4938/setup.c +++ b/arch/mips/txx9/rbtx4938/setup.c @@ -356,6 +356,7 @@ static void __init rbtx4938_device_init(void) tx4938_ndfmc_init(10, 35); tx4938_ata_init(RBTX4938_IRQ_IOC_ATA, 0, 1); tx4938_dmac_init(0, 2); + tx4938_aclc_init(); txx9_iocled_init(RBTX4938_LED_ADDR - IO_BASE, -1, 8, 1, "green", NULL); } diff --git a/arch/mips/txx9/rbtx4939/setup.c b/arch/mips/txx9/rbtx4939/setup.c index 91f2ec8..1d01126 100644 --- a/arch/mips/txx9/rbtx4939/setup.c +++ b/arch/mips/txx9/rbtx4939/setup.c @@ -499,6 +499,7 @@ static void __init rbtx4939_device_init(void) tx4939_ata_init(); tx4939_rtc_init(); tx4939_dmac_init(0, 2); + tx4939_aclc_init(); } static void __init rbtx4939_setup(void) -- 1.5.6.5

3 3

[alsa-devel] ASoC updates for 2.6.30
by Mark Brown 15 May '09

15 May '09

The following changes since commit 1ffafeb556d50de8039e14f1cbbe58e9e4549915: Mike Rapoport (1): pxa2xx-ac97: fix reset gpio mode setting are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.30 David Brownell (3): ASoC: davinci-pcm buildfixes ASoC: DaVinci I2S updates ASoC: DaVinci EVM board support buildfixes arch/arm/mach-davinci/include/mach/asp.h | 25 ++++++++++ sound/soc/davinci/Kconfig | 7 ++- sound/soc/davinci/davinci-evm.c | 63 ++++++++++++++++++++++----- sound/soc/davinci/davinci-i2s.c | 26 ++++++++++- sound/soc/davinci/davinci-pcm.c | 71 +++++++++++++++++------------ 5 files changed, 146 insertions(+), 46 deletions(-) create mode 100644 arch/arm/mach-davinci/include/mach/asp.h

2 3

[alsa-devel] [PATCH 0/1] ALC889A chip identification
by Torben Schulz 15 May '09

15 May '09

Hi everyone, here is my first patch, with allows the intel-hda module to identify the Realtek ALC889A chip correctly. Everything else stands in the changelog of the mail with the patch. This some kind of test-run for my big MacBook 3,1 patch, so any feedback - especially in case of formal mistakes - is welcome. Bai Torben

1 0

[alsa-devel] [PATCH V1 00/13] mpc5200 audio rework for AC97
by Jon Smirl 14 May '09

14 May '09

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'm sure everyone will have some edits on this first version. --- Jon Smirl (13): 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 Have the WM9712 driver self register itself Add SNDRV_PCM_FMTBIT_S32_BE as a valid AC97 format Allow a custom ASOC fabric driver with soc-of-simple Add a few more mpc5200 PSC defines redo 2008f137e92220b98120c4803499cdddb2b0fb06 Rename the PSC functions to DMA Basic split of mpc5200 DMA code out from mpc5200_psc_i2s Temporarily undo 2008f137e92220b98120c4803499cdddb2b0fb06 arch/powerpc/boot/dts/pcm030.dts | 8 arch/powerpc/include/asm/mpc52xx_psc.h | 10 arch/powerpc/platforms/52xx/efika.c | 8 include/sound/soc-dai.h | 3 include/sound/soc-of-simple.h | 16 + sound/last.c | 6 sound/soc/codecs/Kconfig | 4 sound/soc/codecs/Makefile | 2 sound/soc/codecs/stac9766.c | 491 ++++++++++++++++++++++ sound/soc/codecs/stac9766.h | 21 + sound/soc/codecs/tlv320aic26.c | 2 sound/soc/codecs/wm9712.c | 34 ++ sound/soc/fsl/Kconfig | 30 + sound/soc/fsl/Makefile | 6 sound/soc/fsl/efika-audio-fabric.c | 95 ++++ sound/soc/fsl/mpc5200_dma.c | 693 +++++++++++++++++++++++++++++++ sound/soc/fsl/mpc5200_dma.h | 83 ++++ sound/soc/fsl/mpc5200_psc_ac97.c | 379 +++++++++++++++++ sound/soc/fsl/mpc5200_psc_ac97.h | 13 + sound/soc/fsl/mpc5200_psc_i2s.c | 707 +------------------------------- sound/soc/fsl/soc-of-simple.c | 160 ++++++- 21 files changed, 2053 insertions(+), 718 deletions(-) create mode 100644 sound/soc/codecs/stac9766.c create mode 100644 sound/soc/codecs/stac9766.h 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 -- Jon Smirl jonsmirl(a)gmail.com

3 30

[alsa-devel] [PATCH 1/4 v3] pxa2xx-i2s: Proper hw initialization
by Karl Beldan 14 May '09

14 May '09

Make sure we are in a know good state at end of probe : Reset FIFO logic and registers, and make sure REC and RPL functions along with FIFO service are disabled (SACR0_RST enables REC and RPL). Resetting loses current settings so remove reset from stream startup. Now reset occurs only at probe. Signed-off-by: Karl Beldan <karl.beldan(a)mobile-devices.fr> --- sound/soc/pxa/pxa2xx-i2s.c | 17 ++++++++++++++--- 1 files changed, 14 insertions(+), 3 deletions(-) diff --git a/sound/soc/pxa/pxa2xx-i2s.c b/sound/soc/pxa/pxa2xx-i2s.c index 2f4b6e4..59cc4f5 100644 --- a/sound/soc/pxa/pxa2xx-i2s.c +++ b/sound/soc/pxa/pxa2xx-i2s.c @@ -106,10 +106,8 @@ static int pxa2xx_i2s_startup(struct snd_pcm_substream *substream, if (IS_ERR(clk_i2s)) return PTR_ERR(clk_i2s); - if (!cpu_dai->active) { - SACR0 |= SACR0_RST; + if (!cpu_dai->active) SACR0 = 0; - } return 0; } @@ -346,6 +344,19 @@ static int pxa2xx_i2s_probe(struct platform_device *dev) if (ret != 0) clk_put(clk_i2s); + /* + * PXA Developer's Manual: + * If SACR0[ENB] is toggled in the middle of a normal operation, + * the SACR0[RST] bit must also be set and cleared to reset all + * I2S controller registers. + */ + SACR0 = SACR0_RST; + SACR0 = 0; + /* Make sure RPL and REC are disabled */ + SACR1 = SACR1_DRPL | SACR1_DREC; + /* Along with FIFO servicing */ + SAIMR &= ~(SAIMR_RFS | SAIMR_TFS); + return ret; } -- 1.6.3.rc1.34.g0be9b -- Karl

2 4

[alsa-devel] Dynamically registering a codec
by Jon Smirl 14 May '09

14 May '09

On PowerPC the device tree is used to dynamically load the correct codec module. How am I supposed to get this dynamically loaded module registered? The WM8580 codec registers itself. Modifying the WM9712 codec to register itself on device load works for me. If I don't do this how am I supposed to dynamically find the DAI pointer so that I can call snd_soc_register_dais()? diff --git a/sound/soc/codecs/wm9712.c b/sound/soc/codecs/wm9712.c index 550c903..cb0e679 100644 --- a/sound/soc/codecs/wm9712.c +++ b/sound/soc/codecs/wm9712.c @@ -20,6 +20,7 @@ #include <sound/initval.h> #include <sound/soc.h> #include <sound/soc-dapm.h> +#include <sound/soc-of-simple.h> #include "wm9712.h" #define WM9712_VERSION "0.4" @@ -740,6 +741,39 @@ struct snd_soc_codec_device soc_codec_dev_wm9712 = { }; EXPORT_SYMBOL_GPL(soc_codec_dev_wm9712); +static int __init wm9712_probe(struct platform_device *pdev) +{ + snd_soc_register_dais(wm9712_dai, ARRAY_SIZE(wm9712_dai)); +#if defined(CONFIG_SND_SOC_OF_SIMPLE) + /* Tell the of_soc helper about this codec */ + of_snd_soc_register_codec(&soc_codec_dev_wm9712, pdev->dev.archdata.of_node, + wm9712_dai, ARRAY_SIZE(wm9712_dai), + pdev->dev.archdata.of_node); +#endif + return 0; +} + +static struct platform_driver wm9712_driver = +{ + .probe = wm9712_probe, + .driver = { + .name = "wm9712", + }, +}; + +static __init int wm9712_driver_init(void) +{ + return platform_driver_register(&wm9712_driver); +} + +static __exit void wm9712_driver_exit(void) +{ +} + +module_init(wm9712_driver_init); +module_exit(wm9712_driver_exit); + + MODULE_DESCRIPTION("ASoC WM9711/WM9712 driver"); MODULE_AUTHOR("Liam Girdwood"); MODULE_LICENSE("GPL"); -- Jon Smirl jonsmirl(a)gmail.com

2 11

[alsa-devel] Intel HDA fix for Macbook 3,1 and newer
by Le Torbi 14 May '09

14 May '09

Hi guys, I'm new to this list and never contributed anything to such a big open-source project like ALSA, so please forgive me if I make some newbie mistakes. But back the the important stuff: I own a MacBook 3,1 and experienced some sound issues with this. I didn't have no sound, but the sound was quite low in quality and volume. After some research and a lot of wrong ways I stumbled upon bug 0004086 "MacBook 4,1 sounds tinny or not at all " in the ALSA bug tracking system (https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4086) and managed to fix it. Any details can be found in the bug report as well as a link to my patch. My questions now are: 1. Could an exprineced ALSA-Coder check my patch for bugs or "newbie code glitches"? 2. What do I have to do, to get my patch in the official code repository? Thanks in advance for any help. Bai Le Torbi

3 8

[alsa-devel] [PATCH] ASoC: Added OMAP3 EVM support in ASoC.
by Anuj Aggarwal 14 May '09

14 May '09

Resending the patch after fixing the minor issues. Signed-off-by: Anuj Aggarwal <anuj.aggarwal(a)ti.com> --- sound/soc/omap/Kconfig | 8 +++ sound/soc/omap/Makefile | 2 + sound/soc/omap/omap3evm.c | 147 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 157 insertions(+), 0 deletions(-) create mode 100644 sound/soc/omap/omap3evm.c diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 675732e..b771238 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -39,6 +39,14 @@ config SND_OMAP_SOC_OMAP2EVM help Say Y if you want to add support for SoC audio on the omap2evm board. +config SND_OMAP_SOC_OMAP3EVM + tristate "SoC Audio support for OMAP3EVM board" + depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP3EVM + select SND_OMAP_SOC_MCBSP + select SND_SOC_TWL4030 + help + Say Y if you want to add support for SoC audio on the omap3evm board. + config SND_OMAP_SOC_SDP3430 tristate "SoC Audio support for Texas Instruments SDP3430" depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP_3430SDP diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index 0c9e4ac..a37f498 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -10,6 +10,7 @@ snd-soc-n810-objs := n810.o snd-soc-osk5912-objs := osk5912.o snd-soc-overo-objs := overo.o snd-soc-omap2evm-objs := omap2evm.o +snd-soc-omap3evm-objs := omap3evm.o snd-soc-sdp3430-objs := sdp3430.o snd-soc-omap3pandora-objs := omap3pandora.o snd-soc-omap3beagle-objs := omap3beagle.o @@ -18,6 +19,7 @@ obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o obj-$(CONFIG_SND_OMAP_SOC_OSK5912) += snd-soc-osk5912.o obj-$(CONFIG_SND_OMAP_SOC_OVERO) += snd-soc-overo.o obj-$(CONFIG_MACH_OMAP2EVM) += snd-soc-omap2evm.o +obj-$(CONFIG_MACH_OMAP3EVM) += snd-soc-omap3evm.o obj-$(CONFIG_SND_OMAP_SOC_SDP3430) += snd-soc-sdp3430.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o diff --git a/sound/soc/omap/omap3evm.c b/sound/soc/omap/omap3evm.c new file mode 100644 index 0000000..9114c26 --- /dev/null +++ b/sound/soc/omap/omap3evm.c @@ -0,0 +1,147 @@ +/* + * omap3evm.c -- ALSA SoC support for OMAP3 EVM + * + * Author: Anuj Aggarwal <anuj.aggarwal(a)ti.com> + * + * Based on sound/soc/omap/beagle.c by Steve Sakoman + * + * Copyright (C) 2008 Texas Instruments, Incorporated + * + * 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 version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any kind, + * whether express or implied; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + */ + +#include <linux/clk.h> +#include <linux/platform_device.h> +#include <sound/core.h> +#include <sound/pcm.h> +#include <sound/soc.h> +#include <sound/soc-dapm.h> + +#include <asm/mach-types.h> +#include <mach/hardware.h> +#include <mach/gpio.h> +#include <mach/mcbsp.h> + +#include "omap-mcbsp.h" +#include "omap-pcm.h" +#include "../codecs/twl4030.h" + +static int omap3evm_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct snd_soc_dai *codec_dai = rtd->dai->codec_dai; + struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai; + int ret; + + /* Set codec DAI configuration */ + ret = snd_soc_dai_set_fmt(codec_dai, + SND_SOC_DAIFMT_I2S | + SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM); + if (ret < 0) { + printk(KERN_ERR "Can't set codec DAI configuration\n"); + return ret; + } + + /* Set cpu DAI configuration */ + ret = snd_soc_dai_set_fmt(cpu_dai, + SND_SOC_DAIFMT_I2S | + SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM); + if (ret < 0) { + printk(KERN_ERR "Can't set cpu DAI configuration\n"); + return ret; + } + + /* Set the codec system clock for DAC and ADC */ + ret = snd_soc_dai_set_sysclk(codec_dai, 0, 26000000, + SND_SOC_CLOCK_IN); + if (ret < 0) { + printk(KERN_ERR "Can't set codec system clock\n"); + return ret; + } + + return 0; +} + +static struct snd_soc_ops omap3evm_ops = { + .hw_params = omap3evm_hw_params, +}; + +/* Digital audio interface glue - connects codec <--> CPU */ +static struct snd_soc_dai_link omap3evm_dai = { + .name = "TWL4030", + .stream_name = "TWL4030", + .cpu_dai = &omap_mcbsp_dai[0], + .codec_dai = &twl4030_dai[TWL4030_DAI_HIFI], + .ops = &omap3evm_ops, +}; + +/* Audio machine driver */ +static struct snd_soc_card snd_soc_omap3evm = { + .name = "omap3evm", + .platform = &omap_soc_platform, + .dai_link = &omap3evm_dai, + .num_links = 1, +}; + +/* Audio subsystem */ +static struct snd_soc_device omap3evm_snd_devdata = { + .card = &snd_soc_omap3evm, + .codec_dev = &soc_codec_dev_twl4030, +}; + +static struct platform_device *omap3evm_snd_device; + +static int __init omap3evm_soc_init(void) +{ + int ret; + + if (!machine_is_omap3evm()) { + pr_err("Not OMAP3 EVM!\n"); + return -ENODEV; + } + pr_info("OMAP3 EVM SoC init\n"); + + omap3evm_snd_device = platform_device_alloc("soc-audio", -1); + if (!omap3evm_snd_device) { + printk(KERN_ERR "Platform device allocation failed\n"); + return -ENOMEM; + } + + platform_set_drvdata(omap3evm_snd_device, &omap3evm_snd_devdata); + omap3evm_snd_devdata.dev = &omap3evm_snd_device->dev; + *(unsigned int *)omap3evm_dai.cpu_dai->private_data = 1; + + ret = platform_device_add(omap3evm_snd_device); + if (ret) + goto err1; + + return 0; + +err1: + printk(KERN_ERR "Unable to add platform device\n"); + platform_device_put(omap3evm_snd_device); + + return ret; +} + +static void __exit omap3evm_soc_exit(void) +{ + platform_device_unregister(omap3evm_snd_device); +} + +module_init(omap3evm_soc_init); +module_exit(omap3evm_soc_exit); + +MODULE_AUTHOR("Anuj Aggarwal <anuj.aggarwal(a)ti.com>"); +MODULE_DESCRIPTION("ALSA SoC OMAP3 EVM"); +MODULE_LICENSE("GPLv2"); -- 1.6.2.4

3 3

[alsa-devel] mute and unmute
by Deweirdt Peter-Jan 14 May '09

14 May '09

Hi, I have written a small (proof of concept) program that is providing audio on all my channels on the audio. What I have noticed is that the "Speaker" channel gets muted every time. I don't know how or by who? When I change with alsamixer the mute then after less then 5 sec it get muted. How can I debug who is muting my 'Speaker' channel. Here is some output. [root@localhost ~]# amixer -c 0 Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 75 [59%] [-20.00dB] [on] Front Right: Playback 75 [59%] [-20.00dB] [on] Simple mixer control 'Headphone SZCMode',0 Capabilities: penum Items: 'Immediate' 'Zero Cross' 'Soft Ramp' 'Soft Ramp on Zero Cross' Item0: 'Soft Ramp' Simple mixer control 'Line',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 63 Front Left: Capture 51 [81%] [0.00dB] [off] Front Right: Capture 51 [81%] [0.00dB] [off] Simple mixer control 'Line Input',0 Capabilities: cvolume Capture channels: Front Left - Front Right Limits: Capture 0 - 3 Front Left: Capture 0 [0%] [0.00dB] Front Right: Capture 0 [0%] [0.00dB] Simple mixer control 'Line-In PGA Mode',0 Capabilities: cenum Items: 'Differential' 'Single-ended' Item0: 'Differential' Simple mixer control 'Line-Out',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 115 [91%] [0.00dB] [on] Front Right: Playback 115 [91%] [0.00dB] [on] Simple mixer control 'Line-In SZCMode',0 Capabilities: cenum Items: 'Immediate' 'Digital Immediate, Analog Zero Cross' 'Digital and Analog Soft Ramp' 'Digital Soft Ramp, Analog Zero Cross' Item0: 'Digital and Analog Soft Ramp' Simple mixer control 'Line-Out SZCMode',0 Capabilities: penum Items: 'Immediate' 'Zero Cross' 'Soft Ramp' 'Soft Ramp on Zero Cross' Item0: 'Soft Ramp' Simple mixer control 'Mic',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 63 Front Left: Capture 51 [81%] [0.00dB] [off] Front Right: Capture 51 [81%] [0.00dB] [off] Simple mixer control 'Mic Input',0 Capabilities: cvolume Capture channels: Front Left - Front Right Limits: Capture 0 - 3 Front Left: Capture 0 [0%] [0.00dB] Front Right: Capture 0 [0%] [0.00dB] Simple mixer control 'Mic PGA Mode',0 Capabilities: cenum Items: 'Differential' 'Single-ended' Item0: 'Differential' Simple mixer control 'Mic SZCMode',0 Capabilities: cenum Items: 'Immediate' 'Digital Immediate, Analog Zero Cross' 'Digital and Analog Soft Ramp' 'Digital Soft Ramp, Analog Zero Cross' Item0: 'Digital and Analog Soft Ramp' Simple mixer control 'IEC958',0 Capabilities: pswitch pswitch-joined cswitch cswitch-joined Playback channels: Mono Capture channels: Mono Mono: Playback [off] Capture [off] Simple mixer control 'IEC958 Default PCM',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'Analog In',0 Capabilities: cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Capture channels: Mono Mono: Capture [on] Simple mixer control 'Analog In',1 Capabilities: cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Capture channels: Mono Mono: Capture [on] Simple mixer control 'Digital Input 1',0 Capabilities: cvolume Capture channels: Front Left - Front Right Limits: Capture 0 - 2 Front Left: Capture 0 [0%] [0.00dB] Front Right: Capture 0 [0%] [0.00dB] Simple mixer control 'Digital Input 2',0 Capabilities: cvolume Capture channels: Front Left - Front Right Limits: Capture 0 - 2 Front Left: Capture 0 [0%] [0.00dB] Front Right: Capture 0 [0%] [0.00dB] Simple mixer control 'Digital Mic',0 Capabilities: cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Capture channels: Mono Mono: Capture [off] Simple mixer control 'Digital Mic',1 Capabilities: cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Capture channels: Mono Mono: Capture [off] Simple mixer control 'Speakers',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 100 [79%] [-7.50dB] [off] Front Right: Playback 100 [79%] [-7.50dB] [off] Simple mixer control 'Speakers SZCMode',0 Capabilities: penum Items: 'Immediate' 'Zero Cross' 'Soft Ramp' 'Soft Ramp on Zero Cross' Item0: 'Soft Ramp' [root@localhost ~]# No I unmute the "Speaker" channel: [root@localhost ~]# amixer set -c 0 Speakers unmute; date Simple mixer control 'Speakers',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 100 [79%] [-7.50dB] [on] Front Right: Playback 100 [79%] [-7.50dB] [on] Thu May 14 16:20:57 EDT 2009 [root@localhost ~]# amixer get -c 0 Speakers; date Simple mixer control 'Speakers',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 100 [79%] [-7.50dB] [on] Front Right: Playback 100 [79%] [-7.50dB] [on] Thu May 14 16:20:58 EDT 2009 [root@localhost ~]# amixer get -c 0 Speakers; date Simple mixer control 'Speakers',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 100 [79%] [-7.50dB] [off] Front Right: Playback 100 [79%] [-7.50dB] [off] Thu May 14 16:21:00 EDT 2009 [root@localhost ~]# amixer get -c 0 Speakers; date Simple mixer control 'Speakers',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 127 Mono: Front Left: Playback 100 [79%] [-7.50dB] [off] Front Right: Playback 100 [79%] [-7.50dB] [off] Thu May 14 16:21:01 EDT 2009 [root@localhost ~]#

1 0

[alsa-devel] appl_ptr and DMA overrun at end of stream
by Jon Smirl 14 May '09

14 May '09

I am having problem with DMA overrun at the end of the audio stream. Is there an official way to know the address of the last valid audio sample? mpc5200 ac97 is keeping a bunch of descriptors queued in a loop to continuously play music. I believe this is the way ALSA wants it. Now say the last period is half full. ALSA fills the other half with silence. When that period finishes playing it will generate an interrupt. ALSA comes back from that interrupt with trigger(STOP). But, our CPU is slow compared to a 3Ghz desktop, there is considerable latency from the period end interrupt to trigger(STOP) getting called. So the DMA hardware starts playing the next period before trigger(STOP) can get the DMA stopped. I turned off tried turning off BestComm, flushing the FIFO, and turning off the audio clocks. None can be done fast enough. That next period contains stale data from further back in the stream. When the front part of it plays it makes a burst of noise. What I need is the address of the end of valid data in the buffer. I need that address so that I can program the DMA automatically stop at end of stream and not overrun. Search around in the guys of ALSA I found appl_ptr. I can use appl_ptr to determine the location of end of stream and prevent DMA overrun. When there is no valid data I don't enqueue the descriptor. s->appl_ptr track the previous value of s->runtime->control->appl_ptr. The difference between these two is the amount of valid data in the buffer. When this difference goes to zero, I stop queue new buffers to ALSA. That fixes the DMA overrun. static void psc_dma_bcom_enqueue_next_buffer(struct psc_dma_stream *s) { struct bcom_bd *bd; while (s->appl_ptr < s->runtime->control->appl_ptr) { if (bcom_queue_full(s->bcom_task)) return; s->appl_ptr += s->period_size; /* 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; } } -- Jon Smirl jonsmirl(a)gmail.com

3 19

[alsa-devel] [RFC] ALSA vs. dedicated char device for a USB Audio Class gadget driver
by Laurent Pinchart 14 May '09

14 May '09

Hi everybody. Linux provides a USB Audio Class (UAC) driver on the USB host side, but a UAC gadget driver on the USB device side is currently missing. Considering plugging in this hole, I'm looking at userspace <-> kernelspace APIs. In a nutshell (let's consider recording, where the device appears to the host as a USB microphone), the kernel driver needs to be fed with audio data from a userspace application and stream those data on USB. Audio data can come from a real microphone (through an ALSA driver), a file, a network socket, ... the driver will not care. I need an API to transfer audio data from userspace to kernelspace. I initially thought about ALSA, but it turns out some assumptions made by ALSA are not fulfilled by my system. One of the most serious problems is that the UAC gadget driver doesn't have any audio clock. The only hardware clock available is the USB device controller interrupts generated at the USB transfer rate, and those are much faster than the audio sample rate. This will cause buffer underruns that I need to handle. I can thing of 3 solutions to solve this issue, and I'd like your opinion on them. 1. Get the userspace application to provide a clock to the driver. This could be done by writing to a /proc file, a special char device, or even by adding an ioctl to ALSA. Every time the driver receives a clock tick it would transfer one period of data. 2. Find out how much data is available in the ALSA ring buffer. I could then throttle USB interrupts when no data is available in the buffer and try again later. ALSA maintains a read and a write pointer (hw_ptr and appl_ptr) that can be accessed through the snd_pcm_*_avail() functions. However, I'm not sure how to handle proper locking, and I don't understand how runtime->boundary interacts with those functions. I've also heard that there's a free-running mode that will make those functions return bogus values. I'd appreciate help on this. 3. Use another API (dedicated character device, socket, ...) to transfer audio data from userspace to kernelspace. ALSA is way too big for my requirements (2 layers of abstraction, architectured around assumptions that make sense for real sound cards but not for my hardware, ...). On the other hand, it would be handy to use existing ALSA applications to driver the device. I'd appreciate comments regarding the API choice. How do you all expect to push data from a userspace application to a UAC driver on the device side ? If ALSA is *the* way, is one of the above solutions practical or is there a better way ? Best regards, Laurent Pinchart

1 0

[alsa-devel] [PATCH] keywest: Get rid of useless i2c_device_name() macro
by Jean Delvare 14 May '09

14 May '09

The i2c_device_name() macro is used only once and doesn't have much value, it hurts redability more than it helps. Get rid of it. Signed-off-by: Jean Delvare <khali(a)linux-fr.org> Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> --- sound/ppc/keywest.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) --- linux-2.6.30-rc1.orig/sound/ppc/keywest.c 2009-04-10 16:22:08.000000000 +0200 +++ linux-2.6.30-rc1/sound/ppc/keywest.c 2009-04-10 16:25:16.000000000 +0200 @@ -33,10 +33,6 @@ static struct pmac_keywest *keywest_ctx; -#ifndef i2c_device_name -#define i2c_device_name(x) ((x)->name) -#endif - static int keywest_probe(struct i2c_client *client, const struct i2c_device_id *id) { @@ -56,7 +52,7 @@ static int keywest_attach_adapter(struct if (! keywest_ctx) return -EINVAL; - if (strncmp(i2c_device_name(adapter), "mac-io", 6)) + if (strncmp(adapter->name, "mac-io", 6)) return 0; /* ignored */ memset(&info, 0, sizeof(struct i2c_board_info)); -- Jean Delvare

2 1

[alsa-devel] AC97 reset fail after suspend
by Tomas 'Sleep_Walker' Cech 14 May '09

14 May '09

Hi, I've got following error on Palm LifeDrive and PalmTX after suspend & resume: pxa2xx_ac97_try_warm_reset: warm reset timeout (GSR=0x0) pxa2xx_ac97_read: read error (ac97_reg=0 GSR=0x0) pxa2xx_ac97_try_cold_reset: cold reset timeout (GSR=0x44) pxa2xx_ac97_read: read error (ac97_reg=0 GSR=0x44) WM9712 AC97 reset failed could not reset AC97 codec That completely disable whole AC97 communication, so touchscreen, sound and battery doesn't work any longer. I also tried this with Treo680 (code will be sent soon). HW is very similar, only codec is different - LD/T5/TX use WM9712, Treo680 use WM9713. On Treo680 there is no problem with that. Thanks for any hint about that. Tomas 'Sleep_Walker' Cech Attaching config for LD/TX and dmesg output.

4 10

[alsa-devel] DMA over run on playback
by Jon Smirl 14 May '09

14 May '09

There's a long thread over on the pulse list about glitch free playback. The glitches they are encountering are caused by CPU scheduling latency. They are trying to fix this by setting HZ up to 1000 and constantly polling the audio DMA queue to keep it 99% full. This doesn't seem like the right solution to me. It is fixing the symptom not the cause. The cause is 200-300ms scheduling latency. The source of that needs to be tracked down and fixed in the kernel. But we have to live with the latencies until they are fixed. The strategy of checking the queue at 1000Hz works but it is very inefficient. The underlying problem is that the buffer ALSA is using is too small on systems with 300ms latency. The buffer is just big enough to cover 300ms so they rapidly check and fill it at 1000Hz to ensure that it is full if the 300ms latency strikes. On my hardware with period interrupts ALSA is only checking the buffer at 8Hz. Since I'm checking appl_ptr I know when DMA over runs the buffers. This allows me to insert silence and I could indicated this condition to ALSA if there was a mechanism for doing so. ALSA could use this over run knowledge to measure scheduling latency and adjust the buffering. But the DMA interface between ALSA and the driver has been fixed at stream creation time. There's no way to dynamically alter it (like window size changes in TCP/IP). With networking you get a list of buffers to send. As you send these buffers you mark them sent. The core is free to hand you buffers straight from user space or do copies and use internal ring buffers. The network driver just gets a list of physical addresses to send. This buffer bookkeeping could occur in snd_pcm_period_elapsed(). A dynamic chaining mechanism allows you to alter the buffering mid-stream. If the driver indication a DMA over run error this tells ALSA that it needs to insert another buffer. After a while these errors will stop and ALSA will have measured worst case CPU scheduling latency. From then on it will know the exact size of buffering needed for the kernel it it running on and it can use this knowledge at stream creation time. Now filling the buffer at 8Hz or lower will work and you don't have to spend the power associated with 1000Hz timer interrupts. -- Jon Smirl jonsmirl(a)gmail.com

4 10

[alsa-devel] [PATCH 1/4 v2] pxa2xx-i2s: Proper hw initialization
by Karl Beldan 14 May '09

14 May '09

Make sure we are in a know good state at end of probe : Reset FIFO logic and registers, and make sure REC and RPL functions along with FIFO service are disabled (SACR0_RST enables REC and RPL). Resetting loses current settings so remove reset from stream startup. Now reset occurs only at probe. Signed-off-by: Karl Beldan <karl.beldan(a)mobile-devices.fr> --- sound/soc/pxa/pxa2xx-i2s.c | 17 ++++++++++++++--- 1 files changed, 14 insertions(+), 3 deletions(-) diff --git a/sound/soc/pxa/pxa2xx-i2s.c b/sound/soc/pxa/pxa2xx-i2s.c index 2f4b6e4..59cc4f5 100644 --- a/sound/soc/pxa/pxa2xx-i2s.c +++ b/sound/soc/pxa/pxa2xx-i2s.c @@ -106,10 +106,8 @@ static int pxa2xx_i2s_startup(struct snd_pcm_substream *substream, if (IS_ERR(clk_i2s)) return PTR_ERR(clk_i2s); - if (!cpu_dai->active) { - SACR0 |= SACR0_RST; + if (!cpu_dai->active) SACR0 = 0; - } return 0; } @@ -346,6 +344,19 @@ static int pxa2xx_i2s_probe(struct platform_device *dev) if (ret != 0) clk_put(clk_i2s); + /* + * PXA Developer's Manual: + * If SACR0[ENB] is toggled in the middle of a normal operation, + * the SACR0[RST] bit must also be set and cleared to reset all + * I2S controller registers. + */ + SACR0 = SACR0_RST; + SACR0 = 0; + /* Make sure RPL and REC are disabled */ + SACR1 = SACR1_DRPL | SACR1_DREC; + /* Along with FIFO servicing */ + SAIMR &= ~(SAIMR_RFS | SAIMR_TFS); + return ret; } -- 1.6.3.rc1.34.g0be9b -- Karl

2 2

[alsa-devel] [PATCH] riptide: postfix increment and off by one
by Roel Kluin 14 May '09

14 May '09

With a postfix increment these variables are incremented beyond CMDIF_TIMEOUT / MAX_WRITE_RETRY. Signed-off-by: Roel Kluin <roel.kluin(a)gmail.com> --- diff --git a/sound/pci/riptide/riptide.c b/sound/pci/riptide/riptide.c index 6f10344..e51a5ef 100644 --- a/sound/pci/riptide/riptide.c +++ b/sound/pci/riptide/riptide.c @@ -889,7 +889,7 @@ static int sendcmd(struct cmdif *cif, u32 flags, u32 cmd, u32 parm, spin_lock_irqsave(&cif->lock, irqflags); while (i++ < CMDIF_TIMEOUT && !IS_READY(cif->hwport)) udelay(10); - if (i >= CMDIF_TIMEOUT) { + if (i > CMDIF_TIMEOUT) { err = -EBUSY; goto errout; } @@ -907,8 +907,10 @@ static int sendcmd(struct cmdif *cif, u32 flags, u32 cmd, u32 parm, WRITE_PORT_ULONG(cmdport->data1, cmd); /* write cmd */ if ((flags & RESP) && ret) { while (!IS_DATF(cmdport) && - time++ < CMDIF_TIMEOUT) + time < CMDIF_TIMEOUT) { udelay(10); + time++; + } if (time < CMDIF_TIMEOUT) { /* read response */ ret->retlongs[0] = READ_PORT_ULONG(cmdport->data1); @@ -1454,7 +1456,7 @@ static int snd_riptide_trigger(struct snd_pcm_substream *substream, int cmd) SEND_GPOS(cif, 0, data->id, &rptr); udelay(1); } while (i != rptr.retlongs[1] && j++ < MAX_WRITE_RETRY); - if (j >= MAX_WRITE_RETRY) + if (j > MAX_WRITE_RETRY) snd_printk(KERN_ERR "Riptide: Could not stop stream!"); break; case SNDRV_PCM_TRIGGER_PAUSE_PUSH: @@ -1783,7 +1785,7 @@ snd_riptide_codec_write(struct snd_ac97 *ac97, unsigned short reg, SEND_SACR(cif, val, reg); SEND_RACR(cif, reg, &rptr); } while (rptr.retwords[1] != val && i++ < MAX_WRITE_RETRY); - if (i == MAX_WRITE_RETRY) + if (i > MAX_WRITE_RETRY) snd_printdd("Write AC97 reg failed\n"); }

2 1

[alsa-devel] WM9712 - Big and little endian format conversion.
by Jon Smirl 13 May '09

13 May '09

I have three areas specifying audio formats. The WM9712 AC97 codec is S16_LE. My DMA hardware is S32_BE. All samples need to be in 32b words even if they are 8,16,24b. The cpu's AC97 system sends the first 20 big endian bits down the AC97 link in the proper order. How can I force the DMA engine setting to override what the codec is saying? Or should the codec be changed to specify all bit lengths and both endians? My DMA platform: static const struct snd_pcm_hardware psc_dma_hardware = { .info = SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_BATCH, .formats = SNDRV_PCM_FMTBIT_S32_BE, .rate_min = 8000, .rate_max = 48000, .channels_min = 1, .channels_max = 2, .period_bytes_max = 1024 * 1024, .period_bytes_min = 32, .periods_min = 2, .periods_max = 256, .buffer_bytes_max = 2 * 1024 * 1024, .fifo_size = 512, }; CPU DAI: static struct snd_soc_dai psc_ac97_dai_template[] = { { .name = "%s analog", .suspend = psc_ac97_suspend, .resume = psc_ac97_resume, .playback = { .channels_min = 1, .channels_max = 6, .rates = SNDRV_PCM_RATE_8000_48000, .formats = SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S32_BE, }, .capture = { .channels_min = 1, .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_48000, .formats = SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S32_BE, }, .ops = &psc_ac97_analog_ops, }, Codec: struct snd_soc_dai wm9712_dai[] = { { .name = "AC97 HiFi", .ac97_control = 1, .playback = { .stream_name = "HiFi Playback", .channels_min = 1, .channels_max = 2, .rates = WM9712_AC97_RATES, .formats = SNDRV_PCM_FMTBIT_S16_LE, }, .capture = { .stream_name = "HiFi Capture", .channels_min = 1, .channels_max = 2, .rates = WM9712_AC97_RATES, .formats = SNDRV_PCM_FMTBIT_S16_LE, }, .ops = &wm9712_dai_ops_hifi, }, { -- Jon Smirl jonsmirl(a)gmail.com

2 7

[alsa-devel] Avoiding buffer underruns in the hardware interrupt handler
by Laurent Pinchart 13 May '09

13 May '09

Hi everybody. Disclaimer: I'm new with ALSA development and I'm trying to digest the large amount of information I'm overflowed with, so please bear with possibly stupid help requests. I'm writing an ALSA driver for a playback device. Unlike most sound cards, this device uses private memory for its audio buffer. I thus need to manually copy data from the ALSA buffer to the device buffer in the driver. The device audio buffer is quite small, and for this reason I'd rather not use the copy/silence callbacks, but copy data from the ALSA buffer to the device in interrupt. The device might generate interrupts a bit faster than what would be expected from sampling rate, so I need to check in the interrupt handler how much data the ALSA buffer holds. To do so I need to maintain a "hardware pointer" in the driver and to access the "user pointer" on the other side of the buffer. I haven't found a clear API to access that second pointer. What is the best/preferred way to find out how much data the ALSA buffer holds ? I suppose I will need to perform some locking when accessing the "user pointer", I will also appreciate advices regarding which mutex/spinlock I should use for that purpose. Best regards, Laurent Pinchart

1 0

[alsa-devel] [PATCH 4/4 v2] pxa2xx-i2s: Fix suspend/resume
by Karl Beldan 13 May '09

13 May '09

pxa2xx_i2s_resume is : - unconditionnaly setting SACR0_ENB - unsetting SACR0_ENB in saved SACR0 pxa_i2s.sacr0 fix these. In pxa2xx_i2s_{resume,suspend}, save/restore registers even when !dai->active. Signed-off-by: Karl Beldan <karl.beldan(a)mobile-devices.fr> --- sound/soc/pxa/pxa2xx-i2s.c | 11 +++-------- 1 files changed, 3 insertions(+), 8 deletions(-) diff --git a/sound/soc/pxa/pxa2xx-i2s.c b/sound/soc/pxa/pxa2xx-i2s.c index a423637..efe499e 100644 --- a/sound/soc/pxa/pxa2xx-i2s.c +++ b/sound/soc/pxa/pxa2xx-i2s.c @@ -262,9 +262,6 @@ static void pxa2xx_i2s_shutdown(struct snd_pcm_substream *substream, #ifdef CONFIG_PM static int pxa2xx_i2s_suspend(struct snd_soc_dai *dai) { - if (!dai->active) - return 0; - /* store registers */ pxa_i2s.sacr0 = SACR0; pxa_i2s.sacr1 = SACR1; @@ -279,16 +276,14 @@ static int pxa2xx_i2s_suspend(struct snd_soc_dai *dai) static int pxa2xx_i2s_resume(struct snd_soc_dai *dai) { - if (!dai->active) - return 0; - pxa_i2s_wait(); - SACR0 = pxa_i2s.sacr0 &= ~SACR0_ENB; + SACR0 = pxa_i2s.sacr0 & ~SACR0_ENB; SACR1 = pxa_i2s.sacr1; SAIMR = pxa_i2s.saimr; SADIV = pxa_i2s.sadiv; - SACR0 |= SACR0_ENB; + + SACR0 = pxa_i2s.sacr0; return 0; } -- 1.6.3.rc1.34.g0be9b -- Karl

1 0

[alsa-devel] [PATCH 3/4 v2] pxa2xx-i2s: Fix inappropriate release of i2s clock
by Karl Beldan 13 May '09

13 May '09

i2s_clk is 'put' for no reason in pxa2xx_i2s_shutdown. Now we 'get' i2s_clk at probe and 'put' it at driver removal or when probe fails. Signed-off-by: Karl Beldan <karl.beldan(a)mobile-devices.fr> --- sound/soc/pxa/pxa2xx-i2s.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/sound/soc/pxa/pxa2xx-i2s.c b/sound/soc/pxa/pxa2xx-i2s.c index a461c8d..a423637 100644 --- a/sound/soc/pxa/pxa2xx-i2s.c +++ b/sound/soc/pxa/pxa2xx-i2s.c @@ -257,8 +257,6 @@ static void pxa2xx_i2s_shutdown(struct snd_pcm_substream *substream, pxa_i2s_wait(); clk_disable(clk_i2s); } - - clk_put(clk_i2s); } #ifdef CONFIG_PM -- 1.6.3.rc1.34.g0be9b -- Karl

1 0

[alsa-devel] [PATCH 2/4 v2] pxa2xx-i2s: Handle SACR1_DRPL and SACR1_DREC separately
by Karl Beldan 13 May '09

13 May '09

- hw_params enables both RPL and REC functions each time : Enable the appropriate function in pxa2xx_i2s_trigger. - pxa2xx_i2s_shutdown disables i2s anytime one of RPL or REC function is off : Turn it off only when both functions are off. Signed-off-by: Karl Beldan <karl.beldan(a)mobile-devices.fr> --- sound/soc/pxa/pxa2xx-i2s.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/sound/soc/pxa/pxa2xx-i2s.c b/sound/soc/pxa/pxa2xx-i2s.c index 59cc4f5..a461c8d 100644 --- a/sound/soc/pxa/pxa2xx-i2s.c +++ b/sound/soc/pxa/pxa2xx-i2s.c @@ -176,9 +176,7 @@ static int pxa2xx_i2s_hw_params(struct snd_pcm_substream *substream, /* is port used by another stream */ if (!(SACR0 & SACR0_ENB)) { - SACR0 = 0; - SACR1 = 0; if (pxa_i2s.master) SACR0 |= SACR0_BCKD; @@ -224,6 +222,10 @@ static int pxa2xx_i2s_trigger(struct snd_pcm_substream *substream, int cmd, switch (cmd) { case SNDRV_PCM_TRIGGER_START: + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + SACR1 &= ~SACR1_DRPL; + else + SACR1 &= ~SACR1_DREC; SACR0 |= SACR0_ENB; break; case SNDRV_PCM_TRIGGER_RESUME: @@ -250,7 +252,7 @@ static void pxa2xx_i2s_shutdown(struct snd_pcm_substream *substream, SAIMR &= ~SAIMR_RFS; } - if (SACR1 & (SACR1_DREC | SACR1_DRPL)) { + if ((SACR1 & (SACR1_DREC | SACR1_DRPL)) == (SACR1_DREC | SACR1_DRPL)) { SACR0 &= ~SACR0_ENB; pxa_i2s_wait(); clk_disable(clk_i2s); -- 1.6.3.rc1.34.g0be9b -- Karl

1 0

[alsa-devel] [PATCH 0/4 v2] pxa2xx-i2s: Rework
by Karl Beldan 13 May '09

13 May '09

Following is a rework of the i2s code for the pxa. I tested it with the ac97 clock as the master clock. Feedbacks are welcome. Diff with initial version: - hw init from 1/4 is moved from pxa2xx_i2s_init to pxa2xx_i2s_probe - moved 'removal of hw reset from pxa2xx_i2s_startup' from 3/4 to 1/4v2 - moved 'clk_put(clk_i2s) removal' from 2/4 to 3/4v2 - 3/4 was also removing FIFOs flushes, 3/4v2 consists of 'clk_put(clk_i2s) removal' only, -- Karl

1 1