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

[alsa-devel] aplay -l vs. aplay -L: Missing PCMs?
by Stephen Warren 23 Aug '10

23 Aug '10

The Azalia controller on NVIDIA GPUs gives 4 ALSA hw devices: (on card 1): [swarren@swarren-lx2 ~]$ sudo aplay -l **** List of PLAYBACK Hardware Devices **** card 0: NVidia [HDA NVidia], device 0: ALC1200 Analog [ALC1200 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: NVidia [HDA NVidia], device 3: ALC1200 Digital [ALC1200 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia_1 [HDA NVidia], device 3: NVIDIA HDMI [NVIDIA HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia_1 [HDA NVidia], device 7: NVIDIA HDMI [NVIDIA HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia_1 [HDA NVidia], device 8: NVIDIA HDMI [NVIDIA HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia_1 [HDA NVidia], device 9: NVIDIA HDMI [NVIDIA HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 ... all of which appear to work OK. However, the list of available "PCMs" from aplay -L doesn't expose them all: [swarren@swarren-lx2 ~]$ sudo aplay -L front:CARD=NVidia,DEV=0 HDA NVidia, ALC1200 Analog Front speakers surround40:CARD=NVidia,DEV=0 HDA NVidia, ALC1200 Analog 4.0 Surround output to Front and Rear speakers surround41:CARD=NVidia,DEV=0 HDA NVidia, ALC1200 Analog 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=NVidia,DEV=0 HDA NVidia, ALC1200 Analog 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=NVidia,DEV=0 HDA NVidia, ALC1200 Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers surround71:CARD=NVidia,DEV=0 HDA NVidia, ALC1200 Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers hdmi:CARD=NVidia,DEV=0 HDA NVidia, ALC1200 Digital HDMI Audio Output null Discard all samples (playback) or generate zero samples (capture) pulse Playback/recording through the PulseAudio sound server hdmi:CARD=NVidia_1 HDA NVidia, NVIDIA HDMI HDMI Audio Output Similarly, pulseaudio only shows one output for the GPU; I assume it uses the same enumeration mechanism for ALSA sinks as "aplay -L". Instead, I imagined that I'd see 4 PCMs listed by "aplay -L"; one for each converter. Is this an incorrect assumption? How would I make that happen? I imagine that's why Google shows up so many hits on probe_mask for NVIDIA GPUs, so that the one that does show up is the one users want? Thanks. -- nvpublic

3 7

[alsa-devel] HDMI hot-plug/ELD issues
by pl bossart 23 Aug '10

23 Aug '10

Hi, I was testing my pulseaudio AC3 passthrough patch on my new laptop (all Intel hw, Corei5/IbexPeak, 2.6.35) and noticed a set of issues with the HDMI output: 1. Playback can happen even if there's no HDMI cable plugged. Or when I remove the cable, the player isn't notified and keeps sending data to the driver. This is fine for PCM but I noticed that the receiver can handle some trouble synchronizing with in AC3-passthrough mode if the cable is inserted after the playback starts. It would be much cleaner to allow playback only when there's an actual cable connected, and to return -ENODEV or something to apps when this happens. 2. It looks like the ELD info is invalid in /proc/asound/cards/. Tried both with my TV and AV receiver, no luck, all zeroes except for 'monitor_present' monitor_present 1 eld_valid 0 monitor_name connection_type HDMI eld_version [0x0] reserved edid_version [0x0] no CEA EDID Timing Extension block present manufacture_id 0x0 product_id 0x0 port_id 0x0 support_hdcp 0 support_ai 0 audio_sync_delay 0 speakers [0xffff] FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC FLW/FRW FLH/FRH TC FCH sad_count 0 Is there a missing link with the display driver so that this info would make sense? I remember having a conversation with Fengguang Wu on this, but I can't remember what the outcome was. Or is this a case of back luck with broken hardware not sending the legal EDID info? Thanks for your help on this. -Pierre

2 2

[alsa-devel] Problem to init AD1938 on i.MX25
by Sven Zeisberg 23 Aug '10

23 Aug '10

Hello, we're working on an ALSA driver for AD1938 for i.MX25 based system. On the I²S the CODEC is Master. On the SPI, the MCU is Master. SSI seems to work (when we set the CODEC as Master by Hardware). We have problems to get the communication via SPI working. The CODEC requires 24Bit words and we can set SPI according to this in the board-file and verify this also with a logic analyzer. However, we can send only one word to the CODEC! This first word is transferred correctly, but all subsequent transfers show no activity on the SPI lines. We do not get any error messages from the SPI drivers! All SPI writes after the first word seem to be executed in software but show not effect in hardware. All reads return 0xff. We assume that something with the set-up of the platform device is wrong: if we do not set the 24 Bit word size for each message, the SPI transfer is only 8 bit long - only when we set 24 bit in the spi_transfer struct for a transmission, the correct signals appear on the logic analyzer. Could anybody point us to an example of platform device set-up for a similar CODEC on this MCU? Are there known limitations of SPI transfers on the i.MX24 (like it can do only 8-Bit transfers)? Any idea for further investigations would be highly appreciated...! We have the following SPI / SSI set-up in the board file: static struct pad_desc stk5_ad1938_pads[] = { MX25_PAD_RW__AUD4_TXFS, MX25_PAD_EB0__AUD4_TXD, MX25_PAD_EB1__AUD4_RXD, MX25_PAD_OE__AUD4_TXC, }; static int stk5_ad1938_plat_init(void) { int ret; DBG(0, "%s: \n", __FUNCTION__); ret = mxc_iomux_v3_setup_multiple_pads(stk5_ad1938_pads, ARRAY_SIZE(stk5_ad1938_pads)); return ret; } static void stk5_ad1938_plat_finit(void) { DBG(0, "%s: \n", __FUNCTION__); mxc_iomux_v3_release_multiple_pads(stk5_ad1938_pads, ARRAY_SIZE(stk5_ad1938_pads)); } static struct mxc_audio_platform_data stk5_ad1938_data = { .ssi_num = 0, .src_port = 1, .ext_port = 4, .sysclk = 11289600, .init = stk5_ad1938_plat_init, .finit = stk5_ad1938_plat_finit, }; static struct platform_device stk5_ad1938_device = { .name = "imx-ad1938", .dev = { .platform_data =&stk5_ad1938_data, }, }; static int __init stk5_ad1938_init(void) { DBG(0, "%s: Registering device %s\n", __FUNCTION__, stk5_ad1938_device.name); return platform_device_register(&stk5_ad1938_device); } arch_initcall(stk5_ad1938_init); static int stk5_spi_chipselect[] = { MXC_SPI_CS(0), }; static struct pad_desc stk5_cspi1_pads[] = { MX25_PAD_CSPI1_MOSI__CSPI1_MOSI, MX25_PAD_CSPI1_MISO__CSPI1_MISO, MX25_PAD_CSPI1_SS0__CSPI1_SS0, MX25_PAD_CSPI1_SS1__CSPI1_SS1, MX25_PAD_CSPI1_SCLK__CSPI1_SCLK, MX25_PAD_CSPI1_RDY__CSPI1_RDY, }; static struct spi_device ad1938_spi_chip_info = { .bits_per_word = 24, }; static struct spi_board_info stk5_spi_info[] = { { .modalias = "ad1938", .max_speed_hz = 10000000, .bus_num = 0, .chip_select = 0, .controller_data =&ad1938_spi_chip_info, .mode = SPI_MODE_0, }, }; static struct spi_imx_master stk5_spi1_data = { .chipselect = stk5_spi_chipselect, .num_chipselect = ARRAY_SIZE(stk5_spi_chipselect), }; static int __init stk5_spi_register(void) { int ret; ret = mxc_iomux_v3_setup_multiple_pads(stk5_cspi1_pads, ARRAY_SIZE(stk5_cspi1_pads)); if (ret) { printk(KERN_ERR "Failed to configure CSPI1 pads\n"); return ret; } ret = spi_register_board_info(stk5_spi_info, ARRAY_SIZE(stk5_spi_info)); if (ret) { printk(KERN_ERR "%s: Failed to register SPI board_info: %d\n", __FUNCTION__, ret); goto err; } ret = mxc_register_device(&mxc_spi_device0,&stk5_spi1_data); DBG(0, "%s: mxc_register_device() returned: %d\n", __FUNCTION__, ret); return 0; err: mxc_iomux_v3_release_multiple_pads(stk5_cspi1_pads, ARRAY_SIZE(stk5_cspi1_pads)); return ret; } device_initcall(stk5_spi_register); And the following functino to write to the CODEC Registers: static int ad1938_write_reg(struct snd_soc_codec *codec, unsigned int reg, unsigned int value) { u8 *reg_cache = codec->reg_cache; int ret = 0; if (value != reg_cache[reg]) { uint8_t buf[AD1938_SPI_BUFLEN]; struct spi_transfer t = { .tx_buf = buf, .len = AD1938_SPI_BUFLEN, .bits_per_word = 24, .cs_change = 0, }; struct spi_message m; buf[2] = AD1938_SPI_ADDR<< 1; buf[1] = reg; buf[0] = value; spi_message_init(&m); spi_message_add_tail(&t,&m); m.is_dma_mapped =0; printk(KERN_ERR "SPI-WRITE->Reg= %x, value=%x\n",reg,buf[2]); ret = spi_sync(codec->control_data,&m); printk(KERN_ERR "SPI-WRITE->Return %i\n",ret); if (ret == 0) reg_cache[reg] = value; } return ret; } BR, Sven Zeisberg

3 4

[alsa-devel] ASoC update for 2.6.36
by Mark Brown 23 Aug '10

23 Aug '10

The following changes since commit b2c1e07b81a126e5846dfc3d36f559d861df59f4: ASoC: Remove DSP mode support for WM8776 (2010-08-16 11:46:57 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.36 Sascha Hauer (1): ASoC: i.MX ssi: use SSI_STCCR in synchronous mode Simple, non-invasive bug fix. sound/soc/imx/imx-ssi.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)

2 1

[alsa-devel] [PATCH 1/3] ASoC: pxa2xx-i2s is the proper name of the I2S DAI, not pxa-i2s.
by Ian Lartey 23 Aug '10

23 Aug '10

Signed-off-by: Ian Lartey <ian(a)opensource.wolfsonmicro.com> --- sound/soc/pxa/imote2.c | 2 +- sound/soc/pxa/magician.c | 2 +- sound/soc/pxa/poodle.c | 2 +- sound/soc/pxa/z2.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/pxa/imote2.c b/sound/soc/pxa/imote2.c index 03765fc..154fc6f 100644 --- a/sound/soc/pxa/imote2.c +++ b/sound/soc/pxa/imote2.c @@ -63,7 +63,7 @@ static struct snd_soc_ops imote2_asoc_ops = { static struct snd_soc_dai_link imote2_dai = { .name = "WM8940", .stream_name = "WM8940", - .cpu_dai_name = "pxa-i2s", + .cpu_dai_name = "pxa2xx-i2s", .codec_dai_name = "wm8940-hifi", .platform_name = "pxa-pcm-audio", .codec_name = "wm8940-codec.0-0034", diff --git a/sound/soc/pxa/magician.c b/sound/soc/pxa/magician.c index 608bc3d..b8207ce 100644 --- a/sound/soc/pxa/magician.c +++ b/sound/soc/pxa/magician.c @@ -437,7 +437,7 @@ static struct snd_soc_dai_link magician_dai[] = { { .name = "uda1380", .stream_name = "UDA1380 Capture", - .cpu_dai_name = "pxa-i2s", + .cpu_dai_name = "pxa2xx-i2s", .codec_dai_name = "uda1380-hifi-capture", .platform_name = "pxa-pcm-audio", .codec_name = "uda1380-codec.0-0018", diff --git a/sound/soc/pxa/poodle.c b/sound/soc/pxa/poodle.c index fa752f6..af84ee9 100644 --- a/sound/soc/pxa/poodle.c +++ b/sound/soc/pxa/poodle.c @@ -266,7 +266,7 @@ static int poodle_wm8731_init(struct snd_soc_pcm_runtime *rtd) static struct snd_soc_dai_link poodle_dai = { .name = "WM8731", .stream_name = "WM8731", - .cpu_dai_name = "pxa-i2s", + .cpu_dai_name = "pxa2xx-i2s", .codec_dai_name = "wm8731-hifi", .platform_name = "pxa-pcm-audio", .codec_name = "wm8731-codec.0-001a", diff --git a/sound/soc/pxa/z2.c b/sound/soc/pxa/z2.c index 704f74b..4cc841b 100644 --- a/sound/soc/pxa/z2.c +++ b/sound/soc/pxa/z2.c @@ -189,7 +189,7 @@ static struct snd_soc_ops z2_ops = { static struct snd_soc_dai_link z2_dai = { .name = "wm8750", .stream_name = "WM8750", - .cpu_dai_name = "pxa-i2s", + .cpu_dai_name = "pxa2xx-i2s", .codec_dai_name = "wm8750-hifi", .platform_name = "pxa-pcm-audio", .codec_name = "wm8750-codec.0-001a", -- 1.7.0.4

3 4

[alsa-devel] ASoC i.MX ssi: use SSI_STCCR in synchronous mode
by Sascha Hauer 23 Aug '10

23 Aug '10

Hi, This time with cc list. Please consider applying for -rc. Sascha In synchronous mode the SSI_SRCCR values are ignored. Instead SSI_STCCR must be used for both receiving and transmitting. Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de> --- sound/soc/imx/imx-ssi.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/soc/imx/imx-ssi.c b/sound/soc/imx/imx-ssi.c index a11daa1..c81da05 100644 --- a/sound/soc/imx/imx-ssi.c +++ b/sound/soc/imx/imx-ssi.c @@ -254,6 +254,9 @@ static int imx_ssi_hw_params(struct snd_pcm_substream *substream, dma_data = &ssi->dma_params_rx; } + if (ssi->flags & IMX_SSI_SYN) + reg = SSI_STCCR; + snd_soc_dai_set_dma_data(cpu_dai, substream, dma_data); sccr = readl(ssi->base + reg) & ~SSI_STCCR_WL_MASK; -- 1.7.1 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

3 2

[alsa-devel] [PATCH] ASoC: Add build infrastructure for WL1273
by Mark Brown 23 Aug '10

23 Aug '10

The Makefile and Kconfig updates for WL1273 appear to have been mising from the patch posted, add them. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/Kconfig | 4 ++++ sound/soc/codecs/Makefile | 2 ++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index a3cfc18..155c127 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -41,6 +41,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_TWL6040 if TWL4030_CORE select SND_SOC_UDA134X select SND_SOC_UDA1380 if I2C + select SND_SOC_WL1273 if WL1273_CORE select SND_SOC_WM2000 if I2C select SND_SOC_WM8350 if MFD_WM8350 select SND_SOC_WM8400 if MFD_WM8400 @@ -193,6 +194,9 @@ config SND_SOC_UDA134X config SND_SOC_UDA1380 tristate +config SND_SOC_WL1273 + tristate + config SND_SOC_WM8350 tristate diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index b9c4358..10d468e 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -27,6 +27,7 @@ snd-soc-twl4030-objs := twl4030.o snd-soc-twl6040-objs := twl6040.o snd-soc-uda134x-objs := uda134x.o snd-soc-uda1380-objs := uda1380.o +snd-soc-wl1273-objs := wl1273.o snd-soc-wm8350-objs := wm8350.o snd-soc-wm8400-objs := wm8400.o snd-soc-wm8510-objs := wm8510.o @@ -98,6 +99,7 @@ obj-$(CONFIG_SND_SOC_TWL4030) += snd-soc-twl4030.o obj-$(CONFIG_SND_SOC_TWL6040) += snd-soc-twl6040.o obj-$(CONFIG_SND_SOC_UDA134X) += snd-soc-uda134x.o obj-$(CONFIG_SND_SOC_UDA1380) += snd-soc-uda1380.o +obj-$(CONFIG_SND_SOC_WL1273) += snd-soc-wl1273.o obj-$(CONFIG_SND_SOC_WM8350) += snd-soc-wm8350.o obj-$(CONFIG_SND_SOC_WM8400) += snd-soc-wm8400.o obj-$(CONFIG_SND_SOC_WM8510) += snd-soc-wm8510.o -- 1.7.1

2 1

[alsa-devel] [PATCH] ASoC: omap: rx51: Use gpio_set_value_cansleep for speaker amp control
by Jarkko Nikula 23 Aug '10

23 Aug '10

Speaker amplifier is controlled by TWL4030 GPIO which may sleep. Therefore use gpio_set_value_cansleep to get rid of runtime warning that is introduced after the commit 9c4ba94 and to get a stack trace if ever executing this code in atomic context. Signed-off-by: Jarkko Nikula <jhnikula(a)gmail.com> --- sound/soc/omap/rx51.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/omap/rx51.c b/sound/soc/omap/rx51.c index d1d8098..04b5723 100644 --- a/sound/soc/omap/rx51.c +++ b/sound/soc/omap/rx51.c @@ -146,9 +146,9 @@ static int rx51_spk_event(struct snd_soc_dapm_widget *w, struct snd_kcontrol *k, int event) { if (SND_SOC_DAPM_EVENT_ON(event)) - gpio_set_value(RX51_SPEAKER_AMP_TWL_GPIO, 1); + gpio_set_value_cansleep(RX51_SPEAKER_AMP_TWL_GPIO, 1); else - gpio_set_value(RX51_SPEAKER_AMP_TWL_GPIO, 0); + gpio_set_value_cansleep(RX51_SPEAKER_AMP_TWL_GPIO, 0); return 0; } -- 1.7.1

3 2

[alsa-devel] [PATCH] ASoC: Log WM8994 separate ADC LRCLKs every time we configure
by Mark Brown 23 Aug '10

23 Aug '10

This makes it that little bit easier to spot the diagnostics in the logs. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8994.c | 12 ++++++++---- 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index 76a066e..e03072c 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -3316,20 +3316,24 @@ static int wm8994_hw_params(struct snd_pcm_substream *substream, bclk_reg = WM8994_AIF1_BCLK; rate_reg = WM8994_AIF1_RATE; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK || - wm8994->lrclk_shared[0]) + wm8994->lrclk_shared[0]) { lrclk_reg = WM8994_AIF1DAC_LRCLK; - else + } else { lrclk_reg = WM8994_AIF1ADC_LRCLK; + dev_dbg(codec->dev, "AIF1 using split LRCLK\n"); + } break; case 2: aif1_reg = WM8994_AIF2_CONTROL_1; bclk_reg = WM8994_AIF2_BCLK; rate_reg = WM8994_AIF2_RATE; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK || - wm8994->lrclk_shared[1]) + wm8994->lrclk_shared[1]) { lrclk_reg = WM8994_AIF2DAC_LRCLK; - else + } else { lrclk_reg = WM8994_AIF2ADC_LRCLK; + dev_dbg(codec->dev, "AIF2 using split LRCLK\n"); + } break; default: return -EINVAL; -- 1.7.1

2 1

[alsa-devel] [PATCH - HDA-Intel.conf 1/1] HDA-Intel: do not lock IEC958 Playback switch
by Pierre-Louis Bossart 23 Aug '10

23 Aug '10

As discussed with Takashi, removing the lock allows apps to mute the output using the mixer interface. Other AES controls remain locked. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)intel.com> diff --git a/src/conf/cards/HDA-Intel.conf b/src/conf/cards/HDA-Intel.conf index 726e8c9..f7eecb4 100644 --- a/src/conf/cards/HDA-Intel.conf +++ b/src/conf/cards/HDA-Intel.conf @@ -111,8 +111,6 @@ HDA-Intel.pcm.iec958.0 { } { name "IEC958 Playback Switch" - lock true - preserve true value true } ] @@ -184,8 +182,6 @@ HDA-Intel.pcm.hdmi.common { { name "IEC958 Playback Switch" index $CTLINDEX - lock true - preserve true value true } ] -- 1.7.2.1

2 1