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

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

[alsa-devel] Testers wanted: New SB X-Fi driver
by Mario Contreras 25 May '09

25 May '09

Hello, I have this card. Will the unstable version work with my card? I have read it has a different chipset. I installed it a few days ago, but there wasn't any sound. I have Ubuntu 9.04. When I test it in sound preferences it freezes. I would like to test it. If I can be helpful, I'd appreciate you help me. Than you.

3 11

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

25 May '09

Hello, 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 5

[alsa-devel] snd_pcm_writei() return value
by Cristian Morales Vega 25 May '09

25 May '09

Hi, I have an stupid doubt... The snd_pcm_writei() documentation says: "If the blocking behaviour is selected, then routine waits until all requested bytes are played or put to the playback ring buffer. The count of bytes can be less only if a signal or underrun occurred." and at the same time it says "-EPIPE an underrun occurred" is a possible return value. Then snd_pcm_recover() documentation says: "This functions handles -EINTR (interrupted system call), -EPIPE (overrun or underrun) and -ESTRPIPE (stream is suspended) error codes trying to prepare given stream for next I/O." So if I want to write the full content of a buffer, would this be valid?: while(buffer.length > 0) { snd_pcm_sframes_t written = snd_pcm_writei(device.handle, buffer.data, buffer.length); if(written < 0) snd_pcm_recover(device.handle, written, 1); else buffer.length = 0; } "The count of bytes can be less only if a signal ... occurred." makes me think that if a signal interrups snd_pcm_writei() it will return a value between 0 and buffer.length, but "This functions handles -EINTR (interrupted system call)" makes me think that it will always return -EINTR. "The count of bytes can be less only if a ... underrun occurred.", even if technically correct, also seems to be against the "-EPIPE an underrun occurred" return value. So, in the previous code, "if(written < 0)" should be changed by "if(written < buffer.length)"? Anyway, how snd_pcm_recover() handles an -EINTR? If only half the data has been written it can't modify buffer.data to point to the last sample written+1. Perhaps I need a full: uint32_t *buffer_ptr = buffer.data; while(buffer.length > 0) { snd_pcm_sframes_t written = snd_pcm_writei(device.handle, buffer_ptr, buffer.length); if(written < 0) { snd_pcm_recover(device.handle, written, 1); } else if(written <= buffer.length) { buffer.length -= written; buffer_ptr += written; } } ? And still, in this case an interrupt would be handled by snd_pcm_recover() (written < 0) or by the "else" code? Thanks.

3 3

[alsa-devel] [PATCH] ALSA: hda - Add forced codec-slots for ASUS W5Fm
by Ozan Çağlayan 25 May '09

25 May '09

ASUS W5Fm needs the fixed codec-slots to probe to override the BIOS problem like W5F. Tested-by: Alp Kılıç <kilic.alp(a)gmail.com> Signed-off-by: Ozan Çağlayan <ozan(a)pardus.org.tr> --- sound/pci/hda/hda_intel.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 21e99cf..4419e11 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2142,6 +2142,7 @@ static struct snd_pci_quirk probe_mask_list[] __devinitdata = { SND_PCI_QUIRK(0x17c0, 0x4085, "Medion MD96630", 0x01), /* forced codec slots */ SND_PCI_QUIRK(0x1046, 0x1262, "ASUS W5F", 0x103), + SND_PCI_QUIRK(0x1043, 0x1262, "ASUS W5Fm", 0x103), {} }; -- 1.6.2

2 7