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

[alsa-devel] [snd-ctxfi] Test EMU20K2
by Sylvain Loulergue 25 May '09

25 May '09

Hi, Modules snd-ctxfi works fine for me (http://www.alsa-project.org/db/?f=e90356f82f257f499e8028d8a28c98775fd765e7). If you need some specific test just say it. thanks for this devel

1 0

[alsa-devel] Alsamixer isn't working properly with HDA VIA VT82xx with Realtek ALC888 Codec
by Stephan Jänecke 25 May '09

25 May '09

Dear developers, alsamixer doesn't work on my fedora machine. When I type in 'alsamixer -c 0', I get "hda_codec: num-steps=0 for NID=0xf (ctl=Side Playback Volume)" "alsamixer: function snd_mixer_load failed: Invalid argument" Although Pulseaudio and OSS Mixers seem to be present, I don't get any sound. Please have a look at http://www.alsa- project.org/db/?f=15c9f665eb141dee755a533d804456e81442f270 or check the attachment. I hope you can help me solving my problem. Regards, Stephan Jänecke PS: I had the same mixer problem with Mandriva 2009.0 before I installed Fedora 10 to check whether it's an distribution specific bug. Whereas alsamixer didn't work properly as well, I could enjoy working sound. -- Powered by openSUSE 11.1 and KMail 1.10.3

2 5

[alsa-devel] pb with AC'97 codec on atmel at91 boards
by Sedji Gaouaou 25 May '09

25 May '09

Hi all, I am currently working on an AC'97 driver for ATMEL boards(AT91), and I encounter some problems. On the board we have an AD1981b, and looking at the file ac97_patch.c I was wondering in the function patch_ad1881 why is there 3 codecs? I've got the AD1981b datasheet, but the registers description is not really clear to me(vendor id register). My problem is: when I try to read this registers(vendor id) during the probe(in snd_ac97_mixer), it will fail, and from time to time I will even not be able to recognize the codec... So my question is: is that normal that in the function patch_ad1881 the code fails to read these lines: codecs[1] = patch_ad1881_unchained(ac97, 1, (1<<14)); codecs[2] = patch_ad1881_unchained(ac97, 2, (1<<13)); Regards, Sedji

1 0

[alsa-devel] usb audio alsa driver
by wei zhang 25 May '09

25 May '09

hi I was for our devices under linux audio alsa driver, I encountered a lot of trouble now, please help me. My audio device is this: usb interface types, transmission of data through the INT endpoint, each 64 bytes, read out the PCM audio data stream, the sampling rate is 22,050, a single channel, I have the debugging information data crawlers , but I am under no voice in skype, you can tell me the possible reason? Or give me some recommendations, I am very anxious, I would like to thank.I sent my driver, please help me show you, thank you

1 0

Re: [alsa-devel] Help on writing an ALSA ASoC Driver for WM8985
by Leung Chi Tat 25 May '09

25 May '09

Dear Mark, Thank you so much! I right now have a more clear picture. I'm right now studying the driver code for wm8980 codec (from the main trunk of linux-2.6-asoc) as it seems to be more close to wm8985. I can't find any code for triggering those volume update bits after modified those volume registers. But, the wm8980 datasheet states that we have to do so to make those volume updates properly. Is there some black magic in the code? Chitat On Mon, May 25, 2009 at 11:31:48AM +0800, Leung Chi Tat wrote: > 1. describing those important structures, e.g. struct soc_enum, struct snd_kcontrol_new, struct snd_soc_dapm_widget; An enum is used to define an enumerated ALSA control. A kcontrol is a generic ALSA control - there's nothing ASoC specific about it - and a DAPM widget is a thing for which there is power control. > 2. what is/are the relationships among those important structures; > 3. what is the differences between those controls for struct snd_kcontrol_new and struct snd_soc_dapm_widget; It'd be easier to answer this if you had some more specific questions? In general the answer is that things only go into DAPM if they have some relevance to power - that is, if they're a thing for which there is power control or if they control the routing of audio through the chip (and therefore let the core decide which parts of the chip need to be powered on). As has already been suggested the easiest thing is probably to look at other CODEC drivers and compare what their drivers do with the datasheets. > 4. Should those sinks, sources, paths be defined in the arrays of struct snd_dapm_widget; Yes, all the things you have power control for should be there. > 5. How can I select those defined paths through ALSA user-mode library as I can't find any examples in those ALSA tutorials; The controls are all visible as normal ALSA controls - there's nothing ASoC specific in the userspace API. Look with an application such as amixer or alsamixer to see what's there. > Indeed, I'm right now trying to write a WM8985 driver for my s3c6400 based platform based on the kernel source v2.6.21 from Samsung. Note that this is rather old and there were a few issues in the example code with the way that the clocking was set up for the CPU - mostly due to direct access to the system clocking registers which could interfere with other drivers. It might be worth looking at the very latest linux-next tree where there's a mostly complete implementation of audio support.

2 1

[alsa-devel] ASoC updates for 2.6.31
by Mark Brown 25 May '09

25 May '09

The following changes since commit 86ed3669f068b514ab85ffd548456a342b3fb8d3: Mark Brown (1): ASoC: WM9081 mono DAC with integrated 2.6W class AB/D amplifier driver are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.31 Jon Smirl (4): ASoC: Codec for STAC9766 used on the Efika ASoC: Basic split of mpc5200 DMA code out of mpc5200_psc_i2s ASoC: Rename the PSC functions to DMA ASoC: Add a few more mpc5200 PSC defines Mark Brown (2): ASoC: Fix WM9081 PowerPC compiler issues ASoC: Fix minor issues in STAC9766 driver Peter Ujfalusi (3): ASoC: TWL4030: Handsfree pop removal redesign ASoC: TWL4030: Add shadow register ASoC: TWL4030: HandsfreeL/R mute DAPM switch arch/powerpc/include/asm/mpc52xx_psc.h | 11 + sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/stac9766.c | 463 +++++++++++++++++++++++ sound/soc/codecs/stac9766.h | 21 + sound/soc/codecs/twl4030.c | 99 ++++- sound/soc/codecs/twl4030.h | 7 +- sound/soc/codecs/wm9081.c | 6 +- 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 | 645 ++++---------------------------- 13 files changed, 1217 insertions(+), 586 deletions(-) create mode 100644 sound/soc/codecs/stac9766.c create mode 100644 sound/soc/codecs/stac9766.h create mode 100644 sound/soc/fsl/mpc5200_dma.c create mode 100644 sound/soc/fsl/mpc5200_dma.h

2 1

[alsa-devel] Help on writing an ALSA ASoC Driver for WM8985
by Leung Chi Tat 25 May '09

25 May '09

Hi all, I'm new to ALSA ASoC and ALSA. I'd like get some advice where I can get more information about writing an ASoC driver. I've browsed the internet couples of days and I can only find links on ALSA driver api's and writing an ALSA driver for PCI devices. It seems there is not much information on how to writing an ALSA ASoC driver. I'm stuck on the following questions: 1. describing those important structures, e.g. struct soc_enum, struct snd_kcontrol_new, struct snd_soc_dapm_widget; 2. what is/are the relationships among those important structures; 3. what is the differences between those controls for struct snd_kcontrol_new and struct snd_soc_dapm_widget; 4. Should those sinks, sources, paths be defined in the arrays of struct snd_dapm_widget; 5. How can I select those defined paths through ALSA user-mode library as I can't find any examples in those ALSA tutorials; Indeed, I'm right now trying to write a WM8985 driver for my s3c6400 based platform based on the kernel source v2.6.21 from Samsung. Thank you so much for your valuable advice and suggestions in advance. Best Regards, LEUNG, Chi Tat Senior Software Engineer CCT Tech Advanced Products Limited 18/F, CCT Telecom Building, 11 Wo Shing Street Fo Tan, Shatin, N.T., Hong Kong Tel: +852 26005276 Fax: +852 26948660 Email: ctleung(a)cct.com.hk Website: http://www.cct-tech.com.hk

3 2

[alsa-devel] [PATCH 0/3 take2] ASoC: TWL4030: Handsfree pop removal and mute
by Peter Ujfalusi 25 May '09

25 May '09

Hello, Changes: REG_SW_SHADOW = 0x4A (instead of 0x50) The following series fixes the HandsfreeL/R pop removal sequence: The pop removal is moved from the MUX_E to PGA_E DAPM control and also the sequence is modified to match with the sequence described in the TRM. Note, that the power-down sequence is not described in the TRM, it has been implemented in a way that it should make sense. HandsetL/R mute: Since all bits are needed for the pop removal and they have to modified in a strict order/timing: I have added SW_SHADOW non HW register. This register at the moment only handles the HandsfreeL/R mute. --- Peter Ujfalusi (3): ASoC: TWL4030: Handsfree pop removal redesign ASoC: TWL4030: Add shadow register ASoC: TWL4030: HandsfreeL/R mute DAPM switch sound/soc/codecs/twl4030.c | 99 +++++++++++++++++++++++++++++++++++--------- sound/soc/codecs/twl4030.h | 7 +++- 2 files changed, 85 insertions(+), 21 deletions(-)

2 4

[alsa-devel] [PATCH V2 0/9] mpc5200 audio rework for AC97
by Jon Smirl 25 May '09

25 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. 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 jonsmirl(a)gmail.com

5 34

[alsa-devel] [PATCH 1/2] pxa2xx-ac97-lib: move set_resetgpio to pxa27x.c
by Dmitry Eremin-Solenikov 25 May '09

25 May '09

The code related to set_resetgpio is pxa27x specific and should not be present in sound driver lib. Move it to appropriate place. The code is moved to arch/arm as it will be converted from (exported) pxa_gpio_mode() calls to use MFP which are unexported to modules. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov(a)gmail.com> Cc: Eric Miao <eric.miao(a)marvell.com> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- arch/arm/mach-pxa/include/mach/audio.h | 24 ++++++++++++++++ arch/arm/mach-pxa/pxa27x.c | 37 +++++++++++++++++++++++++ sound/arm/pxa2xx-ac97-lib.c | 47 +++----------------------------- 3 files changed, 65 insertions(+), 43 deletions(-) diff --git a/arch/arm/mach-pxa/include/mach/audio.h b/arch/arm/mach-pxa/include/mach/audio.h index 16eb025..517c868 100644 --- a/arch/arm/mach-pxa/include/mach/audio.h +++ b/arch/arm/mach-pxa/include/mach/audio.h @@ -24,4 +24,28 @@ typedef struct { extern void pxa_set_ac97_info(pxa2xx_audio_ops_t *ops); +/* + * Beware PXA27x bugs: + * + * o Slot 12 read from modem space will hang controller. + * o CDONE, SDONE interrupt fails after any slot 12 IO. + * + * We therefore have an hybrid approach for waiting on SDONE (interrupt or + * 1 jiffy timeout if interrupt never comes). + */ + +enum { + RESETGPIO_FORCE_HIGH, + RESETGPIO_FORCE_LOW, + RESETGPIO_NORMAL_ALTFUNC +}; + +#if defined(CONFIG_PXA27x) +extern void pxa27x_ac97_reset(int reset_gpio, int resetgpio_action); +#else +static inline void pxa27x_ac97_reset(int reset_gpio, int resetgpio_action) +{ +} +#endif + #endif diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c index a425ec7..a0e787e 100644 --- a/arch/arm/mach-pxa/pxa27x.c +++ b/arch/arm/mach-pxa/pxa27x.c @@ -28,6 +28,7 @@ #include <mach/pm.h> #include <mach/dma.h> #include <mach/i2c.h> +#include <mach/audio.h> #include "generic.h" #include "devices.h" @@ -345,6 +346,42 @@ void __init pxa27x_set_i2c_power_info(struct i2c_pxa_platform_data *info) pxa_register_device(&pxa27x_device_i2c_power, info); } +/** + * pxa27x_ac97_reset - computes and sets the AC97_RESET gpio mode on PXA + * @mode: chosen action + * + * As the PXA27x CPUs suffer from a AC97 bug, a manual control of the reset line + * must be done to insure proper work of AC97 reset line. This function + * computes the correct gpio_mode for further use by reset functions, and + * applied the change through pxa_gpio_mode. + */ +/* temporary include */ +#include <mach/pxa2xx-gpio.h> +void pxa27x_ac97_reset(int reset_gpio, int resetgpio_action) +{ + int mode = 0; + + if (reset_gpio) + switch (resetgpio_action) { + case RESETGPIO_NORMAL_ALTFUNC: + if (reset_gpio == 113) + mode = 113 | GPIO_ALT_FN_2_OUT; + if (reset_gpio == 95) + mode = 95 | GPIO_ALT_FN_1_OUT; + break; + case RESETGPIO_FORCE_LOW: + mode = reset_gpio | GPIO_OUT | GPIO_DFLT_LOW; + break; + case RESETGPIO_FORCE_HIGH: + mode = reset_gpio | GPIO_OUT | GPIO_DFLT_HIGH; + break; + }; + + if (mode) + pxa_gpio_mode(mode); +} +EXPORT_SYMBOL(pxa27x_ac97_reset); + static struct platform_device *devices[] __initdata = { &pxa27x_device_udc, &pxa_device_ffuart, diff --git a/sound/arm/pxa2xx-ac97-lib.c b/sound/arm/pxa2xx-ac97-lib.c index 6fdca97..2227314 100644 --- a/sound/arm/pxa2xx-ac97-lib.c +++ b/sound/arm/pxa2xx-ac97-lib.c @@ -42,45 +42,6 @@ static int reset_gpio; * 1 jiffy timeout if interrupt never comes). */ -enum { - RESETGPIO_FORCE_HIGH, - RESETGPIO_FORCE_LOW, - RESETGPIO_NORMAL_ALTFUNC -}; - -/** - * set_resetgpio_mode - computes and sets the AC97_RESET gpio mode on PXA - * @mode: chosen action - * - * As the PXA27x CPUs suffer from a AC97 bug, a manual control of the reset line - * must be done to insure proper work of AC97 reset line. This function - * computes the correct gpio_mode for further use by reset functions, and - * applied the change through pxa_gpio_mode. - */ -static void set_resetgpio_mode(int resetgpio_action) -{ - int mode = 0; - - if (reset_gpio) - switch (resetgpio_action) { - case RESETGPIO_NORMAL_ALTFUNC: - if (reset_gpio == 113) - mode = 113 | GPIO_ALT_FN_2_OUT; - if (reset_gpio == 95) - mode = 95 | GPIO_ALT_FN_1_OUT; - break; - case RESETGPIO_FORCE_LOW: - mode = reset_gpio | GPIO_OUT | GPIO_DFLT_LOW; - break; - case RESETGPIO_FORCE_HIGH: - mode = reset_gpio | GPIO_OUT | GPIO_DFLT_HIGH; - break; - }; - - if (mode) - pxa_gpio_mode(mode); -} - unsigned short pxa2xx_ac97_read(struct snd_ac97 *ac97, unsigned short reg) { unsigned short val = -1; @@ -176,10 +137,10 @@ static inline void pxa_ac97_warm_pxa27x(void) /* warm reset broken on Bulverde, so manually keep AC97 reset high */ - set_resetgpio_mode(RESETGPIO_FORCE_HIGH); + pxa27x_ac97_reset(reset_gpio, RESETGPIO_FORCE_HIGH); udelay(10); GCR |= GCR_WARM_RST; - set_resetgpio_mode(RESETGPIO_NORMAL_ALTFUNC); + pxa27x_ac97_reset(reset_gpio, RESETGPIO_NORMAL_ALTFUNC); udelay(500); } @@ -353,7 +314,7 @@ int pxa2xx_ac97_hw_resume(void) } if (cpu_is_pxa27x()) { /* Use GPIO 113 or 95 as AC97 Reset on Bulverde */ - set_resetgpio_mode(RESETGPIO_NORMAL_ALTFUNC); + pxa27x_ac97_reset(reset_gpio, RESETGPIO_NORMAL_ALTFUNC); } clk_enable(ac97_clk); return 0; @@ -395,7 +356,7 @@ int __devinit pxa2xx_ac97_hw_probe(struct platform_device *dev) if (cpu_is_pxa27x()) { /* Use GPIO 113 as AC97 Reset on Bulverde */ - set_resetgpio_mode(RESETGPIO_NORMAL_ALTFUNC); + pxa27x_ac97_reset(reset_gpio, RESETGPIO_NORMAL_ALTFUNC); ac97conf_clk = clk_get(&dev->dev, "AC97CONFCLK"); if (IS_ERR(ac97conf_clk)) { ret = PTR_ERR(ac97conf_clk); -- 1.6.2.4

3 3