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

[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