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

[alsa-devel] snd-hda-intel+dmix: Disabling power save doesn't work
by Adam Nielsen 08 May '12

08 May '12

Hi all, I'm trying to hunt down a bug in either dmix or the snd-hda-intel module and I'm hoping someone can give me some pointers. When I am playing audio and I pause playback, the codec goes into power save and stops generating a SPDIF signal. My amplifier then displays a 'signal lost' message. This is quite annoying as it takes a few seconds to sync when the signal returns (during which time I can't hear the audio being played), so I set "powersave=0" to disable this behaviour. This works as expected when stopping playback, but if I only *pause* playback then the signal drops almost exactly one second later, no matter what "powersave" is set to. So of course then resuming playback means I lose a couple of seconds of audio while the amplifier re-syncs to the SPDIF signal. Setting powersave to other values only affects the time before going into powersave mode after playback has stopped. It has no effect on whether power saving is activated while paused. The problem happens with any audio program (e.g. mplayer and xmms2.) Setting "powersave=0" means the SPDIF signal keeps going when stopping playback, but it still drops after one second when pausing playback. It doesn't happen if I use hw:0,1 as the output device (the SPDIF signal keeps going, even when paused) but as soon as I change the output device to dmix then the signal drops whenever the audio is paused. Is there any way to stop this behaviour and make dmix honour the module setting? Thanks, Adam.

2 3

[alsa-devel] [PATCH] ASoC: lowland: Support digital link for WM9081
by Mark Brown 08 May '12

08 May '12

The WM9081 on Lowland is connected to AIF3 on the WM5100. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/samsung/lowland.c | 42 +++++++++++++++++++++++++++--------------- 1 file changed, 27 insertions(+), 15 deletions(-) diff --git a/sound/soc/samsung/lowland.c b/sound/soc/samsung/lowland.c index 6cac1e9..6abf341 100644 --- a/sound/soc/samsung/lowland.c +++ b/sound/soc/samsung/lowland.c @@ -74,6 +74,25 @@ static int lowland_wm5100_init(struct snd_soc_pcm_runtime *rtd) return 0; } +static int lowland_wm9081_init(struct snd_soc_pcm_runtime *rtd) +{ + struct snd_soc_codec *codec = rtd->codec; + + snd_soc_dapm_nc_pin(&codec->dapm, "LINEOUT"); + + /* At any time the WM9081 is active it will have this clock */ + return snd_soc_codec_set_sysclk(codec, WM9081_SYSCLK_MCLK, 0, + CLKOUT_RATE, 0); +} + +static const struct snd_soc_pcm_stream sub_params = { + .formats = SNDRV_PCM_FMTBIT_S32_LE, + .rate_min = 44100, + .rate_max = 44100, + .channels_min = 2, + .channels_max = 2, +}; + static struct snd_soc_dai_link lowland_dai[] = { { .name = "CPU", @@ -96,21 +115,16 @@ static struct snd_soc_dai_link lowland_dai[] = { SND_SOC_DAIFMT_CBM_CFM, .ignore_suspend = 1, }, -}; - -static int lowland_wm9081_init(struct snd_soc_dapm_context *dapm) -{ - snd_soc_dapm_nc_pin(dapm, "LINEOUT"); - - /* At any time the WM9081 is active it will have this clock */ - return snd_soc_codec_set_sysclk(dapm->codec, WM9081_SYSCLK_MCLK, 0, - CLKOUT_RATE, 0); -} - -static struct snd_soc_aux_dev lowland_aux_dev[] = { { - .name = "wm9081", + .name = "Sub Speaker", + .stream_name = "Sub Speaker", + .cpu_dai_name = "wm5100-aif3", + .codec_dai_name = "wm9081-hifi", .codec_name = "wm9081.1-006c", + .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM, + .ignore_suspend = 1, + .params = &sub_params, .init = lowland_wm9081_init, }, }; @@ -155,8 +169,6 @@ static struct snd_soc_card lowland = { .owner = THIS_MODULE, .dai_link = lowland_dai, .num_links = ARRAY_SIZE(lowland_dai), - .aux_dev = lowland_aux_dev, - .num_aux_devs = ARRAY_SIZE(lowland_aux_dev), .codec_conf = lowland_codec_conf, .num_configs = ARRAY_SIZE(lowland_codec_conf), -- 1.7.10

1 0

[alsa-devel] [PATCH] ASoC: lowland: Convert to dai_fmt
by Mark Brown 08 May '12

08 May '12

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/samsung/lowland.c | 33 ++++----------------------------- 1 file changed, 4 insertions(+), 29 deletions(-) diff --git a/sound/soc/samsung/lowland.c b/sound/soc/samsung/lowland.c index 4adff93..6cac1e9 100644 --- a/sound/soc/samsung/lowland.c +++ b/sound/soc/samsung/lowland.c @@ -21,33 +21,6 @@ #define MCLK1_RATE (44100 * 512) #define CLKOUT_RATE (44100 * 256) -static int lowland_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 *cpu_dai = rtd->cpu_dai; - struct snd_soc_dai *codec_dai = rtd->codec_dai; - int ret; - - 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) - return ret; - - 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) - return ret; - - return 0; -} - -static struct snd_soc_ops lowland_ops = { - .hw_params = lowland_hw_params, -}; - static struct snd_soc_jack lowland_headset; /* Headset jack detection DAPM pins */ @@ -109,7 +82,8 @@ static struct snd_soc_dai_link lowland_dai[] = { .codec_dai_name = "wm5100-aif1", .platform_name = "samsung-audio", .codec_name = "wm5100.1-001a", - .ops = &lowland_ops, + .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM, .init = lowland_wm5100_init, }, { @@ -118,7 +92,8 @@ static struct snd_soc_dai_link lowland_dai[] = { .cpu_dai_name = "wm5100-aif2", .codec_dai_name = "wm1250-ev1", .codec_name = "wm1250-ev1.1-0027", - .ops = &lowland_ops, + .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM, .ignore_suspend = 1, }, }; -- 1.7.10

1 0

[alsa-devel] Strange Problem with snd-hda-intel
by Frank Maik Kittelmann 08 May '12

08 May '12

We have some strange behavior in our audio application using the ALC 888 hardware in ubuntu 10.10 with the hda-intel driver . Basically the main problem seems to be a buffer or memory management issue. Once a playback is stopped the very last sample is repeated forever, independently from sampling rate or sound file format. This sample leads to a constant DC voltage after the DA converters. We already tried the following steps: 1.) we changed a line in hda_intel.c to reset the fifo --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1797,7 +1797,7 @@ static int azx_pcm_hw_free(struct snd_pcm_substream *substream) /* reset BDL address */ azx_sd_writel(azx_dev, SD_BDLPL, 0); azx_sd_writel(azx_dev, SD_BDLPU, 0); - azx_sd_writel(azx_dev, SD_CTL, 0); + azx_stream_reset(chip, azx_dev); azx_dev->bufsize = 0; azx_dev->period_bytes = 0; azx_dev->format_val = 0; 2.) we set 2 parameters in the .config file before kernel compiling CONFIG_SND_HDA_POWER_SAVE=y CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0 Both solutions didn´t work for us - still same problem. Has anyone another idea how to solve this? Would be great if we could fix this. Frank

1 0

[alsa-devel] [PATCH 0/1] hdsp - Provide ioctl_compat
by Andre Schramm 08 May '12

08 May '12

Hi, short patch to provide ioctl_compat for HDSP cards as well. Quick test with SNDRV_HDSPM_IOCTL_GET_PEAK_RMS worked. Please review and apply. Thanks! Cheers, Andre

3 4

[alsa-devel] Issue with RME HDSPe AIO latency
by jamesm 07 May '12

07 May '12

Hello all, I'm using the RME hdspm kernel module with a Hammerfall HDSPe AIO card. I'm on RHEL 5.5, with alsa 1.0.17, kernel 2.6.18-194.11.4. I have backported the latest alsa hdspm code to this kernel, as there were a number of bugs in the one that ships with the 2.6.18-194 kernel. I've also implemented support for copy() and silence() functions so that the hdspm driver can be used with applications via the RDWR interface instead of just MMAP (ie it just works with aplay without using plughw first.) The latest hdspm driver code from alsa and kernel.org indicates that the HDSPe AIO card has a fixed buffer size of 16384. I've chosen a period size of 1024, which gives me 16 periods. The issue I have is that whenever I play audio through the hdspm driver, the delay between the hw pointer and sw pointer is always close to the maximum buffer size (approx 16000). This leaves me with a large delay between writing data into the PCM and it coming out of the card. I'd like this to be between 1024 and 2048, I could probably crank the period down further to 512. My application sets the start_threshold to 0 and avail_min to one period (1024). It then runs a thread, constantly writing data to the PCM (silence or real data). Does anyone have any suggestions as to why the hdspm driver hw pointer is not following the application pointer more closely? Is it due to the number of periods? Unfortunately I can't change that as the AIO buffer size is fixed. Here are my pcm hwparams, swparams and status from /proc/asound when my app is running: $ cat /proc/asound/card0/pcm0p/info card: 0 device: 0 subdevice: 0 stream: PLAYBACK id: RME AIO name: RME AIO subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 0 $ cat /proc/asound/card0/pcm0p/sub0/hw_params access: RW_NONINTERLEAVED format: S32_LE subformat: STD channels: 16 rate: 48000 (48000/1) period_size: 1024 buffer_size: 16384 tick_time: 1000 $ cat /proc/asound/card0/pcm0p/sub0/sw_params tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 1024 xfer_align: 1 start_threshold: 0 stop_threshold: 18446744073709551615 silence_threshold: 0 silence_size: 0 boundary: 4611686018427387904 $ cat /proc/asound/card0/pcm0p/sub0/status state: RUNNING trigger_time: 1335799965.972782000 tstamp : 1335801526.687332000 delay : 15664 avail : 720 avail_max : 1056 ----- hw_ptr : 74911440 appl_ptr : 74927104 Regards James Milne FilmLight Ltd.

3 2

[alsa-devel] [PATCH] ALSA: jack: Update documention to reflect other userspace interfaces
by Mark Brown 07 May '12

07 May '12

Since this is a generic API which should support any userspace interface for reporting jacks update the documentation a little to make that a bit clearer. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/core/jack.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sound/core/jack.c b/sound/core/jack.c index 471e1e3..a06b165 100644 --- a/sound/core/jack.c +++ b/sound/core/jack.c @@ -155,7 +155,7 @@ EXPORT_SYMBOL(snd_jack_new); * @jack: The jack to configure * @parent: The device to set as parent for the jack. * - * Set the parent for the jack input device in the device tree. This + * Set the parent for the jack devices in the device tree. This * function is only valid prior to registration of the jack. If no * parent is configured then the parent device will be the sound card. */ @@ -179,6 +179,9 @@ EXPORT_SYMBOL(snd_jack_set_parent); * mapping is provided but keys are enabled in the jack type then * BTN_n numeric buttons will be reported. * + * If jacks are not reporting via the input API this call will have no + * effect. + * * Note that this is intended to be use by simple devices with small * numbers of keys that can be reported. It is also possible to * access the input device directly - devices with complex input -- 1.7.10

2 1

[alsa-devel] [PATCH RESEND 0/9] Enable pinctrl support for mach-mxs
by Shawn Guo 07 May '12

07 May '12

[Resend to have subsystem lists Cc-ed] With pinctrl-mxs driver (DT only) applied on pinctrl tree, the mxs device tree conversion can start basing on that support. This series adopts pinctrl support for mxs device drivers with a dummy pinctrl state provided for non-DT boot, so that the pinctrl call in the device drivers will be bypassed for non-DT probe while it starts working for DT probe. To ease the merge process, I would like to ask Arnd and Olof to pull pinctrl tree as a dependency in arm-soc and have this series go through arm-soc. Regards, Shawn Shawn Guo (9): ARM: mxs: enable pinctrl dummy states serial: amba-pl011: adopt pinctrl support serial: mxs-auart: adopt pinctrl support mmc: mxs-mmc: adopt pinctrl support mtd: nand: gpmi: adopt pinctrl support i2c: mxs: adopt pinctrl support ASoC: mxs-saif: adopt pinctrl support video: mxsfb: adopt pinctrl support ARM: mxs: enable pinctrl support arch/arm/Kconfig | 1 + arch/arm/mach-mxs/Kconfig | 2 ++ arch/arm/mach-mxs/include/mach/common.h | 2 ++ arch/arm/mach-mxs/mach-apx4devkit.c | 2 ++ arch/arm/mach-mxs/mach-m28evk.c | 2 ++ arch/arm/mach-mxs/mach-mx23evk.c | 2 ++ arch/arm/mach-mxs/mach-mx28evk.c | 2 ++ arch/arm/mach-mxs/mach-stmp378x_devb.c | 2 ++ arch/arm/mach-mxs/mach-tx28.c | 2 ++ arch/arm/mach-mxs/mm.c | 11 +++++++++++ drivers/i2c/busses/i2c-mxs.c | 6 ++++++ drivers/mmc/host/mxs-mmc.c | 8 ++++++++ drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 9 +++++++++ drivers/tty/serial/amba-pl011.c | 8 ++++++++ drivers/tty/serial/mxs-auart.c | 8 ++++++++ drivers/video/mxsfb.c | 9 +++++++++ sound/soc/mxs/mxs-saif.c | 8 ++++++++ 17 files changed, 84 insertions(+), 0 deletions(-) -- 1.7.5.4

3 5

Re: [alsa-devel] [BUG] Internal CD input missing since linux-3.4
by Takashi Iwai 07 May '12

07 May '12

At Tue, 1 May 2012 12:23:00 +0200, Philipp Matthias Hahn wrote: > > Hello, > > I upgraded my desktop to 3.3.4 last weekend and noticed that the > internal CD connector is no longer available for recording. Instead I > see some new controls about "headphone volume", "rear microphone" and > "auto-mute". But I need the CD input since it's connected to my Analog > TV card, which MythTV needs for recording. > > Using "git bisect" showed the following patch to be doing the switch: > > 31ef22579302ac42054bebecb528710f46580925 is the first bad commit > > commit 31ef22579302ac42054bebecb528710f46580925 > > Author: Takashi Iwai <tiwai(a)suse.de> > > Date: Thu Dec 1 17:41:36 2011 +0100 > > > > ALSA: hda - Integrate input-jack stuff into kctl-jack This looks pretty irrelevant, maybe the bisection went wrong. Basically the problem is that your BIOS doesn't expose the pin for the CD input as an available pin. In alsa-info.sh output, you can see the pin 0x1c is shown as N/A. We can override a pin config value manually in such a case. See HD-Audio.txt in Documentation/sound/alsa. In anyway, I'll try to prepare a test patch in the next week. thanks, Takashi

1 1

[alsa-devel] [PATCH] pci/echoaudio: Remove incorrect part of assertion
by Mark Hills 06 May '12

06 May '12

This assertion seems to imply that chip->dsp_code_to_load is a pointer. It's actually an integer handle on the actual firmware, and 0 has no special meaning. The assertion prevents initialisation of a Darla20 card, but would also affect other models. It seems it was introduced in commit dd7b254d. ALSA sound/pci/echoaudio/echoaudio.c:2061 Echoaudio driver starting... ALSA sound/pci/echoaudio/echoaudio.c:1969 chip=ebe4e000 ALSA sound/pci/echoaudio/echoaudio.c:2007 pci=ed568000 irq=19 subdev=0010 Init hardware... ALSA sound/pci/echoaudio/darla20_dsp.c:36 init_hw() - Darla20 ------------[ cut here ]------------ WARNING: at sound/pci/echoaudio/echoaudio_dsp.c:478 init_hw+0x1d1/0x86c [snd_darla20]() Hardware name: Dell DM051 BUG? (!chip->dsp_code_to_load || !chip->comm_page) Signed-off-by: Mark Hills <mark(a)pogo.org.uk> --- sound/pci/echoaudio/echoaudio_dsp.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/pci/echoaudio/echoaudio_dsp.c b/sound/pci/echoaudio/echoaudio_dsp.c index 64417a7..d8c670c 100644 --- a/sound/pci/echoaudio/echoaudio_dsp.c +++ b/sound/pci/echoaudio/echoaudio_dsp.c @@ -475,7 +475,7 @@ static int load_firmware(struct echoaudio *chip) const struct firmware *fw; int box_type, err; - if (snd_BUG_ON(!chip->dsp_code_to_load || !chip->comm_page)) + if (snd_BUG_ON(!chip->comm_page)) return -EPERM; /* See if the ASIC is present and working - only if the DSP is already loaded */ -- 1.7.4.4

2 1

Re: [alsa-devel] [ALSA hda 3.4-rc] suspend2ram regression in snd_hda_intel
by Konstantin Khlebnikov 06 May '12

06 May '12

Konstantin Khlebnikov wrote: > Mainline commit 785f857d1cb0856b612b46a0545b74aa2596e44a > ("ALSA: hda - Set codec to D3 forcibly even if not used") > breaks sound for my notebook (thinkpad x220), > looks like codec cannot wake from power-save state after resume. > After reverting looks like all works fine. > > how to reproduce: > * unplug the power cord (to enable hda power safe mode) > * play something and stop > * wait until the background noise disappears (codec went into power-save mode) > * suspend > * resume > * play something again and hear the silence > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ Bump BTW, I don't see any locks around hda power-save code, for example hda_power_work() reads codec->power_on and codec->power_count without any locks. This seems racy.

2 1

[alsa-devel] Call for propsals: Audio micro-conf at LPC 2012 San Diego
by Takashi Iwai 05 May '12

05 May '12

Hi, we're planning to hold an Audio micro-conference again this year at Linux Plumbers conference (LPC). It'll be held at San Diego, CA, Aug. 29-31. The Wiki page is found at http://wiki.linuxplumbersconf.org/2012:audio The items listed there are rough ideas popping up during a mail thread. If you have interest and want to give a talk or discussions, don't hesitate to submit your proposal. Please mail to submissions(a)linuxplumbersconf.org, as described in the page below: http://www.linuxplumbersconf.org/2012/2012-lpc-call-for-proposals-take-2/ The deadline for submission is 11:59 PDT on May 1, 2012. So, it's pretty little time left. Sorry for the late announce... thanks, Takashi

2 2

Re: [alsa-devel] [GIT PULL] ASoC fix for 3.4
by Takashi Iwai 05 May '12

05 May '12

At Fri, 04 May 2012 12:24:58 +0100, Liam Girdwood wrote: > > Hi Takashi, > > For your final sound 3.4 fixes pull request. > > Thanks > > Liam > > --- > > The following changes since commit 1a38336b8611a04f0a624330c1f815421f4bf5f4: > > ASoC: wm8994: Improve sequencing of AIF channel enables (2012-04-23 12:55:52 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc.git for-3.4 > > for you to fetch changes up to fad9365bcc2a69ae16adc092e8ac192354980665: > > ASoC: omap-pcm: Free dma buffers in case of error. (2012-05-04 12:09:28 +0100) Thanks, pulled. I'm going to send a pull request to Linus later today. Takashi > ---------------------------------------------------------------- > Oleg Matcovschi (1): > ASoC: omap-pcm: Free dma buffers in case of error. > > sound/soc/omap/omap-pcm.c | 4 ++++ > 1 file changed, 4 insertions(+) > >

1 0

[alsa-devel] ASoC updates for 3.4
by Mark Brown 05 May '12

05 May '12

The following changes since commit 1a38336b8611a04f0a624330c1f815421f4bf5f4: ASoC: wm8994: Improve sequencing of AIF channel enables (2012-04-23 12:55:52 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-3.4 for you to fetch changes up to 06412088ce98f745405b8f65cfc51ddd6b842bbf: ASoC: s3c2412-i2s: Fix dai registration (2012-04-30 23:45:25 +0100) ---------------------------------------------------------------- ASoC: Updates for 3.4 Nothing terribly exciting here, a bunch of small and simple fixes scattered around the place. ---------------------------------------------------------------- Eric Bénard (1): ASoC: tlv312aic23: unbreak resume Fabio Estevam (1): ASoC: dt: sgtl5000.txt: Add description for 'reg' field Heiko Stübner (1): ASoC: s3c2412-i2s: Fix dai registration Lars-Peter Clausen (1): ASoC: bf5xx-ssm2602: Set DAI format Mark Brown (2): ASoC: wm_hubs: Make sure we don't disable differential line outputs ASoC: wm8350: Don't use locally allocated codec struct Richard Zhao (1): ASoC: core: check of_property_count_strings failure Documentation/devicetree/bindings/sound/sgtl5000.txt | 2 ++ sound/soc/blackfin/bf5xx-ssm2602.c | 2 ++ sound/soc/codecs/tlv320aic23.c | 4 ++-- sound/soc/codecs/wm8350.c | 11 ++++++----- sound/soc/codecs/wm_hubs.c | 15 +++++++++------ sound/soc/samsung/s3c2412-i2s.c | 2 +- sound/soc/soc-core.c | 6 +++--- 7 files changed, 25 insertions(+), 17 deletions(-)

2 1

[alsa-devel] Diagnosing why DAPM config is not correctly applied
by Daniel Drake 05 May '12

05 May '12

Hi, I'm working with Linux 3.3 and the soc/codecs/rt5631.c driver in an OLPC XO-1.75 laptop. We are only getting silence when playing back sound. I have added in some debug messages in soc-io.c and enabled DEBUG and VERBOSE_DEBUG in soc-dapm.c. Here are boot messages: http://dev.laptop.org/~dsd/20120504/boot.log At time X in the above log, I start "speaker-test -c 2 -t wav" and leave it running for the remainder of this test. Here is the "amixer" output at this point: http://dev.laptop.org/~dsd/20120504/amixer-initial.txt speaker-test seems happy but no audio can be heard :( However, I have found that the following tweak to the sound controls will fix the left channel: # amixer sset 'Left SPKVOL Mux' 'Vmid' # amixer sset 'Left SPKVOL Mux' 'SPKMIXL' Note that the original value was SPKMIXL (see initial amixer output) so this should have had no effect. However, the result is that sound is now heard through the left channel. (A very similar sound control change will fix the right channel too) While running these commands, the following kernel messages appear: (amixer sset 'Left SPKVOL Mux' 'Vmid') read c = 0 read c = 0 read 10 = 606 read 10 = 606 read c = 0 read c = 0 read a = 0 read a = 0 read 6 = a080 read 1e = 88c0 read 1e = 88c0 read 1e = 88c0 read 1e = 88c0 read 6 = a080 read 20 = 88c0 read 20 = 88c0 read 20 = 88c0 read 20 = 88c0 read 24 = 3000 read 24 = 3000 read 24 = 3000 read 24 = 3000 read 4 = c0c0 read 4 = c0c0 read 4 = c0c0 read 4 = c0c0 read 4 = c0c0 read 4 = c0c0 read 2c = 0 read 2c = 0 read 4 = c0c0 read 6 = a080 read 2 = 4040 read 22 = 7700 read 22 = 7700 read e = 0 read 22 = 7700 read 22 = 7700 read e = 0 read 2c = 0 read 6 = a080 read 26 = 8404 read 26 = 8404 read 26 = 8404 read 2a = 6c00 read 2a = 6c00 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 2 = 4040 read 2 = 4040 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 4 = c0c0 read 6 = a080 read 2 = 4040 read 40 = 4e00 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 2c = 0 read 2a = 6c00 read 2a = 6c00 read 2c = 0 read 2a = 6c00 read 2a = 6c00 read 2 = 4040 read 2 = 4040 read 2 = 4040 read 2 = 4040 read 2 = 4040 read 2 = 4040 read 2 = 4040 read 2 = 4040 rt5631 0-001a: Marking Vmid dirty due to mux connection rt5631 0-001a: Marking Left SPKVOL Mux dirty due to mux change read 2 = 4040 write 2 = 40 (cached) read 2 = 40 (amixer sset 'Left SPKVOL Mux' 'SPKMIXL') read c = 0 read c = 0 read 10 = 606 read 10 = 606 read c = 0 read c = 0 read a = 0 read a = 0 read 6 = a080 read 1e = 88c0 read 1e = 88c0 read 1e = 88c0 read 1e = 88c0 read 6 = a080 read 20 = 88c0 read 20 = 88c0 read 20 = 88c0 read 20 = 88c0 read 24 = 3000 read 24 = 3000 read 24 = 3000 read 24 = 3000 read 4 = c0c0 read 4 = c0c0 read 4 = c0c0 read 4 = c0c0 read 4 = c0c0 read 4 = c0c0 read 2c = 0 read 2c = 0 read 4 = c0c0 read 6 = a080 read 2 = 40 read 22 = 7700 read 22 = 7700 read e = 0 read 22 = 7700 read 22 = 7700 read e = 0 read 2c = 0 read 6 = a080 read 26 = 8404 read 26 = 8404 read 26 = 8404 read 2a = 6c00 read 2a = 6c00 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1a = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 1c = dfc0 read 2 = 40 read 2 = 40 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 14 = b0b0 read 4 = c0c0 read 6 = a080 read 2 = 40 read 40 = 4e00 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 28 = d8d8 read 2c = 0 read 2a = 6c00 read 2a = 6c00 read 2c = 0 read 2a = 6c00 read 2a = 6c00 read 2 = 40 read 2 = 40 read 2 = 40 read 2 = 40 read 2 = 40 read 2 = 40 read 2 = 40 read 2 = 40 rt5631 0-001a: Marking Vmid dirty due to mux disconnection rt5631 0-001a: Marking SPKMIXL Mixer dirty due to mux connection rt5631 0-001a: Marking Left SPKVOL Mux dirty due to mux change rt5631 0-001a: Marking Left DAC dirty due to peer state change rt5631 0-001a: Marking Left DAC To Mixer dirty due to peer state change rt5631 0-001a: Marking DAC REF dirty due to peer state change rt5631 0-001a: Marking I2S dirty due to peer state change rt5631 0-001a: Marking PLL1 dirty due to peer state change rt5631 0-001a: Marking Left DAC_HP dirty due to peer state change rt5631 0-001a: Marking OUTMIXL Mixer dirty due to peer state change read 1a = dfc0 read 28 = d8d8 read 42 = 0 read 42 = 0 read 42 = 0 read 42 = 0 read 2 = 40 write 2 = 4040 (cached) read 3a = 1000 write 3a = 90c0 (cached) read 3a = 90c0 write 3a = 92c0 (cached) read 3b = c write 3b = 200c (cached) read 2 = 4040 So, changing these settings in a way that should have no effect seems to kick DAPM into applying quite a different config from the one initially applied. In particular, the register value register 0x3a (RT5631_PWR_MANAG_ADD1) is quite different from the one applied earlier, and I think this is the key to having playback working. I've spent some time trying to get my head around the dapm code and see whats happening here, without much luck. If someone more experienced here could take a quick look at these messages and the dapm routes in rt5631.c for anything obvious, it would be much appreciated. Further debugging tips welcome too. Thanks, Daniel

1 0

[alsa-devel] ALSA driver issue with the ssm2602.c
by Bishop, Mark 04 May '12

04 May '12

When I enable the 'Output Mixer HiFi' using amixer it also powers up the Mic input on this codec. I believe this is incorrect. I would like to modify the driver to fix it but am having issues with the ALSA structures in the driver. Would I be off if I attempt to make my changes in the snd_soc_dapm_route structures? I am unsure how everything is hooked together in all those structs{}.

2 2

[alsa-devel] [PATCH v2] Provide interface for audio support in DSS
by Ricardo Neri 04 May '12

04 May '12

Hi, This patch is proposed as a result of a previous discussion related to include audio support in the DSS device driver (http://www.spinics.net/lists/linux-omap/msg64748.html) At the moment, this is intended to cover display technologies with audio based on CEA-861 and IEC-60958, such as HDMI and DisplayPort. However, provisions are made to make it extensible (see below). These are the changes with respect to v1: * The audio_enable and audio_start functions were split into enable/disable and start/stop respectively to improve readability. * Comments were added on whether the DSS audio functions may sleep. * In order to make the audio configuration parameters extensible, a struct omap_dss_audio is defined. This helps to easily add more config parameters in the future if/when required (e.g., speaker order configuration). BR, Ricardo Ricardo Neri (1): OMAPDSS: Provide an interface for audio support in DSS Documentation/arm/OMAP/DSS | 38 ++++++++++++++++++++++++++++++++++++++ include/video/omapdss.h | 25 +++++++++++++++++++++++++ 2 files changed, 63 insertions(+), 0 deletions(-) -- 1.7.5.4

1 1

[alsa-devel] [PATCH] ASoC: da7210: Minor improvements and a bugfix
by Ashish Chavan 03 May '12

03 May '12

This patch improves playback quality for few sample rates like 8000 and 11025 Hz. This also fixes an issue observed during testing of pll slave mode. Due to the issue, on some rare occasions there was no sound output for first time playback after system boot, though all subsequent playbacks were fine. It was mainly because of the sequence in which SRM bit was enabled. Signed-off-by: Ashish Chavan <ashish.chavan(a)kpitcummins.com> Signed-off-by: David Dajun Chen <dchen(a)diasemi.com> --- sound/soc/codecs/da7210.c | 28 +++++++++++++++------------- 1 files changed, 15 insertions(+), 13 deletions(-) diff --git a/sound/soc/codecs/da7210.c b/sound/soc/codecs/da7210.c index 10f52ff..af5db70 100644 --- a/sound/soc/codecs/da7210.c +++ b/sound/soc/codecs/da7210.c @@ -850,8 +850,19 @@ static int da7210_hw_params(struct snd_pcm_substream *substream, if (da7210->mclk_rate && (da7210->mclk_rate != sysclk)) { /* PLL mode, disable PLL bypass */ snd_soc_update_bits(codec, DA7210_PLL_DIV3, DA7210_PLL_BYP, 0); + + if (!da7210->master) { + /* PLL slave mode, also enable SRM */ + snd_soc_update_bits(codec, DA7210_PLL, + (DA7210_MCLK_SRM_EN | + DA7210_MCLK_DET_EN), + (DA7210_MCLK_SRM_EN | + DA7210_MCLK_DET_EN)); + } } else { - /* PLL bypass mode, enable PLL bypass */ + /* PLL bypass mode, enable PLL bypass and Auto Detection */ + snd_soc_update_bits(codec, DA7210_PLL, DA7210_MCLK_DET_EN, + DA7210_MCLK_DET_EN); snd_soc_update_bits(codec, DA7210_PLL_DIV3, DA7210_PLL_BYP, DA7210_PLL_BYP); } @@ -1014,18 +1025,9 @@ static int da7210_set_dai_pll(struct snd_soc_dai *codec_dai, int pll_id, snd_soc_update_bits(codec, DA7210_PLL_DIV3, DA7210_PLL_DIV_L_MASK, pll_div3); - if (da7210->master) { - /* In master mode, no need to enable SRM */ - snd_soc_update_bits(codec, DA7210_PLL, DA7210_PLL_EN, - DA7210_PLL_EN); - } else { - /* In slave mode, enable SRM and PLL */ - snd_soc_update_bits(codec, DA7210_PLL, - (DA7210_PLL_EN | DA7210_MCLK_SRM_EN | - DA7210_MCLK_DET_EN), - (DA7210_PLL_EN | DA7210_MCLK_SRM_EN | - DA7210_MCLK_DET_EN)); - } + /* Enable PLL */ + snd_soc_update_bits(codec, DA7210_PLL, DA7210_PLL_EN, DA7210_PLL_EN); + /* Enable active mode */ snd_soc_update_bits(codec, DA7210_STARTUP1, DA7210_SC_MST_EN, DA7210_SC_MST_EN); -- 1.7.1

2 1

Re: [alsa-devel] Fast Track Ultra latency and new streaming logic.
by Clemens Ladisch 03 May '12

03 May '12

Felix Homann wrote: > 2012/5/3 Clemens Ladisch <clemens(a)ladisch.de>: >> USB playback also adds further latency by queueing the packets; the >> number of packets can be seen under "URBs" in /proc/asound/card?/stream0. >> (There are 1000/8000 packets per second at full/high speed.) > > I'm getting "URBs = 2 [ 5 6 ]" for playback and "URBs = 8 [ 8 8 8 8 > 8 8 8 8 ]" for capture with the "old" streaming logic. What does it > mean? The queue length is 5+6 = 11 packets; at high speed, that's 11 / 8 kHz = 1.4 ms. Regards, Clemens

1 0

[alsa-devel] Fast Track Ultra latency and new streaming logic.
by Grant Diffey 03 May '12

03 May '12

Daniel, In continuing my personal habit of looking gift horses in the mouth... I can't seem to get below 512frames in flight (2 256sample frames or 4 128 or 8 64's) without consistant overruns. I have a feeling that the pcm <-> urb layer is buffering until a urb is max urbsize from a quick look at the code does this seem like the right track? This leads to rather high latencies (22ms+) or is this conclusion bogus? Grant.

4 5

Re: [alsa-devel] HDA driver without interrupt
by Clemens Ladisch 03 May '12

03 May '12

Fanchao Liu wrote: > It can transfer data via DMA,the problem is I don't know when to > update hw_ptr and other pointers without interrupt. Does the hardware have some other means to at least read the current position? > I set a timer and call snd_pcm_period_elapsed() every 50ms but get > underrun error. With a call to snd_pcm_period_elapsed(), the driver guarantees that the current position is at or after the next period boundary. Regards, Clemens

1 0

[alsa-devel] HDA driver without interrupt
by liufc 03 May '12

03 May '12

Hi guys,I'm trying to implement an alsa driver based on the Intel HDA driver.However due to some hardware defects,I'm not able to use interrupt.So I wonder whether there is a way to do the job without the help of interrupt.Can anyone give me a suggestion?

3 2

[alsa-devel] [PATCH 00/11] enable imx6q_sabrelite sgtl5000 audio support
by Richard Zhao 02 May '12

02 May '12

It's based on Dong Aisheng's early pinctrl patch and Sascha's v2 convert to common clk patch. You can also get at: https://github.com/riczhao/kernel-imx/tree/topics/audio Richard Zhao (11): dma: imx-sdma: make channel0 operations atomic ASoC: imx-sgtl5000: add of_node_put when probe fail. ASoC: fsl: add sgtl5000 clock support for imx-sgtl5000 i2c: imx: add pinctrl support ARM: imx6q: move imx6q_sabrelite specific code to a dedicated function ARM: dts: imx6q-sabrelite: add ssi device ARM: dts: imx6q-sabrelite: add audmux device ASoC: imx-audmux: add pinctrl support ARM: imx6q: add ssi1 clk_lookup ARM: imx6q_sabrelite: clkdev_add cko1 for sgtl5000 ARM: dts: imx6q-sabrelite: add sound device imx6q-sabrelite-sgtl5000 arch/arm/boot/dts/imx6q-sabrelite.dts | 30 ++++++++++++++++ arch/arm/boot/dts/imx6q.dtsi | 46 +++++++++++++++++++++++-- arch/arm/mach-imx/clk-imx6q.c | 4 ++ arch/arm/mach-imx/mach-imx6q.c | 37 +++++++++++++++++++- drivers/dma/imx-sdma.c | 57 ++++++++++++++++++------------- drivers/i2c/busses/i2c-imx.c | 9 +++++ sound/soc/fsl/imx-audmux.c | 8 ++++ sound/soc/fsl/imx-sgtl5000.c | 61 +++++++++++++++++++++++++-------- 8 files changed, 208 insertions(+), 44 deletions(-) Thanks Richard -- 1.7.5.4

12 54

[alsa-devel] [PATCH 1/2] ASoC: core: Allow DAIs to specify a base address
by Mark Brown 02 May '12

02 May '12

Devices with many DAIs are becoming more and more common, and generally the more modern devices have consistent register layouts between DAIs. Rather than have drivers open code lookups based on the DAI ID or cause uglification in UI by having register addresses for IDs provide a base address field they can use. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- include/sound/soc-dai.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h index c63985b..2704ab0 100644 --- a/include/sound/soc-dai.h +++ b/include/sound/soc-dai.h @@ -198,6 +198,7 @@ struct snd_soc_dai_driver { const char *name; unsigned int id; int ac97_control; + unsigned int base; /* DAI driver callbacks */ int (*probe)(struct snd_soc_dai *dai); -- 1.7.10

2 2

[alsa-devel] [PATCH 8/8] ASoC: Ux500: Add machine-driver
by Ola Lilja 02 May '12

02 May '12

Add machine-driver for ST-Ericsson U8500 platform, including support for the AB8500-codec. Signed-off-by: Ola Lilja <ola.o.lilja(a)stericsson.com> --- sound/soc/ux500/Kconfig | 11 ++ sound/soc/ux500/Makefile | 3 + sound/soc/ux500/u8500.c | 118 +++++++++++++++++++++ sound/soc/ux500/ux500_ab8500.c | 225 ++++++++++++++++++++++++++++++++++++++++ sound/soc/ux500/ux500_ab8500.h | 21 ++++ 5 files changed, 378 insertions(+), 0 deletions(-) create mode 100644 sound/soc/ux500/u8500.c create mode 100644 sound/soc/ux500/ux500_ab8500.c create mode 100644 sound/soc/ux500/ux500_ab8500.h diff --git a/sound/soc/ux500/Kconfig b/sound/soc/ux500/Kconfig index 59da6ce..85031b0 100644 --- a/sound/soc/ux500/Kconfig +++ b/sound/soc/ux500/Kconfig @@ -21,3 +21,14 @@ config SND_SOC_UX500_PLAT_DMA help Say Y if you want to enable the Ux500 platform-driver. +config SND_SOC_UX500_AB8500 + tristate "Codec/Machine - AB8500 (MSA)" + depends on AB8500_CORE && AB8500_GPADC && SND_SOC_UX500 + select SND_SOC_AB8500_CODEC + select SND_SOC_UX500_PLAT_MSP_I2S + select SND_SOC_UX500_PLAT_DMA + help + Select this to enable the Ux500 machine-driver + and the AB8500 codec-driver. It will also enable the platform-driver + Ux500. + diff --git a/sound/soc/ux500/Makefile b/sound/soc/ux500/Makefile index 2e742b1..50b7c42 100644 --- a/sound/soc/ux500/Makefile +++ b/sound/soc/ux500/Makefile @@ -6,3 +6,6 @@ obj-$(CONFIG_SND_SOC_UX500_PLAT_MSP_I2S) += snd-soc-ux500-plat-msp-i2s.o snd-soc-ux500-plat-dma-objs := ux500_pcm.o obj-$(CONFIG_SND_SOC_UX500_PLAT_DMA) += snd-soc-ux500-plat-dma.o +snd-soc-ux500-mach-objs := u8500.o ux500_ab8500.o +obj-$(CONFIG_SND_SOC_UX500_AB8500) += snd-soc-ux500-mach.o + diff --git a/sound/soc/ux500/u8500.c b/sound/soc/ux500/u8500.c new file mode 100644 index 0000000..33348f7 --- /dev/null +++ b/sound/soc/ux500/u8500.c @@ -0,0 +1,118 @@ +/* + * Copyright (C) ST-Ericsson SA 2012 + * + * Author: Ola Lilja (ola.o.lilja(a)stericsson.com) + * for ST-Ericsson. + * + * License terms: + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include <asm/mach-types.h> + +#include <linux/module.h> +#include <linux/io.h> +#include <linux/spi/spi.h> + +#include <sound/soc.h> +#include <sound/initval.h> + +#include "ux500_pcm.h" +#include "ux500_msp_dai.h" + +#ifdef CONFIG_SND_SOC_UX500_AB8500 +#include <ux500_ab8500.h> +#endif + +/* Define the whole U8500 soundcard, linking platform to the codec-drivers */ +struct snd_soc_dai_link u8500_dai_links[] = { + #ifdef CONFIG_SND_SOC_UX500_AB8500 + { + .name = "ab8500_0", + .stream_name = "ab8500_0", + .cpu_dai_name = "ux500-msp-i2s.1", + .codec_dai_name = "ab8500-codec-dai.0", + .platform_name = "ux500-pcm.0", + .codec_name = "ab8500-codec.0", + .init = ux500_ab8500_machine_init, + .ops = ux500_ab8500_ops, + }, + { + .name = "ab8500_1", + .stream_name = "ab8500_1", + .cpu_dai_name = "ux500-msp-i2s.3", + .codec_dai_name = "ab8500-codec-dai.1", + .platform_name = "ux500-pcm.0", + .codec_name = "ab8500-codec.0", + .init = NULL, + .ops = ux500_ab8500_ops, + }, + #endif +}; + +static struct snd_soc_card u8500_card = { + .name = "U8500-card", + .probe = NULL, + .dai_link = u8500_dai_links, + .num_links = ARRAY_SIZE(u8500_dai_links), +}; + + + + +static int __devinit u8500_probe(struct platform_device *pdev) +{ + int ret; + + pr_debug("%s: Enter.\n", __func__); + + u8500_card.dev = &pdev->dev; + + dev_dbg(&pdev->dev, "%s: Card %s: Set platform drvdata.\n", + __func__, u8500_card.name); + platform_set_drvdata(pdev, &u8500_card); + + snd_soc_card_set_drvdata(&u8500_card, NULL); + + dev_dbg(&pdev->dev, "%s: Card %s: num_links = %d\n", + __func__, u8500_card.name, u8500_card.num_links); + dev_dbg(&pdev->dev, "%s: Card %s: DAI-link 0: name = %s\n", + __func__, u8500_card.name, u8500_card.dai_link[0].name); + dev_dbg(&pdev->dev, "%s: Card %s: DAI-link 0: stream_name = %s\n", + __func__, u8500_card.name, u8500_card.dai_link[0].stream_name); + + ret = snd_soc_register_card(&u8500_card); + if (ret) + dev_err(&pdev->dev, "Error: snd_soc_register_card failed (%d)!\n", + ret); + + return ret; +} + +static int __devexit u8500_remove(struct platform_device *pdev) +{ + struct snd_soc_card *u8500_card = platform_get_drvdata(pdev); + + pr_debug("%s: Enter.\n", __func__); + + snd_soc_unregister_card(u8500_card); + platform_set_drvdata(pdev, NULL); + + return 0; +} + +static struct platform_driver snd_soc_u8500_driver = { + .driver = { + .owner = THIS_MODULE, + .name = "snd-soc-u8500", + }, + .probe = u8500_probe, + .remove = __devexit_p(u8500_remove), +}; + +module_platform_driver(snd_soc_u8500_driver); + + diff --git a/sound/soc/ux500/ux500_ab8500.c b/sound/soc/ux500/ux500_ab8500.c new file mode 100644 index 0000000..e4b8c5a --- /dev/null +++ b/sound/soc/ux500/ux500_ab8500.c @@ -0,0 +1,225 @@ +/* + * Copyright (C) ST-Ericsson SA 2012 + * + * Author: Ola Lilja <ola.o.lilja(a)stericsson.com>, + * Kristoffer Karlsson <kristoffer.karlsson(a)stericsson.com> + * for ST-Ericsson. + * + * License terms: + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include <linux/module.h> +#include <linux/device.h> +#include <linux/io.h> + +#include <mach/hardware.h> + +#include <sound/soc.h> +#include <sound/soc-dapm.h> +#include <sound/pcm.h> +#include <sound/jack.h> +#include <sound/pcm_params.h> + +#include "ux500_pcm.h" +#include "ux500_msp_dai.h" +#include "../codecs/ab8500-codec.h" + +#define TX_SLOT_MONO 0x0008 +#define TX_SLOT_STEREO 0x000a +#define RX_SLOT_MONO 0x0001 +#define RX_SLOT_STEREO 0x0003 +#define TX_SLOT_8CH 0x00FF +#define RX_SLOT_8CH 0x00FF + +#define DEF_TX_SLOTS TX_SLOT_STEREO +#define DEF_RX_SLOTS RX_SLOT_MONO + +#define DRIVERMODE_NORMAL 0 +#define DRIVERMODE_CODEC_ONLY 1 + +/* Slot configuration */ +static unsigned int tx_slots = DEF_TX_SLOTS; +static unsigned int rx_slots = DEF_RX_SLOTS; + +static struct snd_kcontrol_new ux500_ab8500_ctrls[] = { + SOC_DAPM_PIN_SWITCH("Headset Left"), + SOC_DAPM_PIN_SWITCH("Headset Right"), + SOC_DAPM_PIN_SWITCH("Earpiece"), + SOC_DAPM_PIN_SWITCH("Speaker Left"), + SOC_DAPM_PIN_SWITCH("Speaker Right"), + SOC_DAPM_PIN_SWITCH("LineOut Left"), + SOC_DAPM_PIN_SWITCH("LineOut Right"), + SOC_DAPM_PIN_SWITCH("Vibra 1"), + SOC_DAPM_PIN_SWITCH("Vibra 2"), + SOC_DAPM_PIN_SWITCH("Mic 1"), + SOC_DAPM_PIN_SWITCH("Mic 2"), + SOC_DAPM_PIN_SWITCH("LineIn Left"), + SOC_DAPM_PIN_SWITCH("LineIn Right"), + SOC_DAPM_PIN_SWITCH("DMic 1"), + SOC_DAPM_PIN_SWITCH("DMic 2"), + SOC_DAPM_PIN_SWITCH("DMic 3"), + SOC_DAPM_PIN_SWITCH("DMic 4"), + SOC_DAPM_PIN_SWITCH("DMic 5"), + SOC_DAPM_PIN_SWITCH("DMic 6"), +}; + +/* ASoC */ + +void ux500_ab8500_shutdown(struct snd_pcm_substream *substream) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct device *dev = rtd->card->dev; + + dev_dbg(dev, "%s: Enter\n", __func__); + + /* Reset slots configuration to default(s) */ + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + tx_slots = DEF_TX_SLOTS; + else + rx_slots = DEF_RX_SLOTS; +} + +int ux500_ab8500_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->codec_dai; + struct snd_soc_dai *cpu_dai = rtd->cpu_dai; + struct device *dev = rtd->card->dev; + unsigned int fmt, fmt_if1; + int channels, ret = 0, slots, slot_width, driver_mode; + bool is_playback; + + dev_dbg(dev, "%s: Enter\n", __func__); + + dev_dbg(dev, "%s: substream->pcm->name = %s\n" + "substream->pcm->id = %s.\n" + "substream->name = %s.\n" + "substream->number = %d.\n", + __func__, + substream->pcm->name, + substream->pcm->id, + substream->name, + substream->number); + + channels = params_channels(params); + + /* Setup codec depending on driver-mode */ + driver_mode = (channels == 8) ? + DRIVERMODE_CODEC_ONLY : DRIVERMODE_NORMAL; + dev_dbg(dev, "%s: Driver-mode: %s.\n", __func__, + (driver_mode == DRIVERMODE_NORMAL) ? "NORMAL" : "CODEC_ONLY"); + + ab8500_audio_set_bit_delay(codec_dai, 1); + + if (driver_mode == DRIVERMODE_NORMAL) { + ab8500_audio_set_word_length(codec_dai, 16); + fmt = SND_SOC_DAIFMT_DSP_A | + SND_SOC_DAIFMT_CBM_CFM | + SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CONT; + } else { + ab8500_audio_set_word_length(codec_dai, 20); + fmt = SND_SOC_DAIFMT_DSP_A | + SND_SOC_DAIFMT_CBM_CFM | + SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_GATED; + } + + ret = snd_soc_dai_set_fmt(codec_dai, fmt); + if (ret < 0) { + dev_err(dev, "%s: ERROR: snd_soc_dai_set_fmt failed " + "for codec_dai (ret = %d)!\n", __func__, ret); + return ret; + } + + ret = snd_soc_dai_set_fmt(cpu_dai, fmt); + if (ret < 0) { + dev_err(dev, "%s: ERROR: snd_soc_dai_set_fmt failed " + "for cpu_dai (ret = %d)!\n", __func__, ret); + return ret; + } + + /* Setup TDM-slots */ + + is_playback = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK); + switch (channels) { + case 1: + slots = 16; + slot_width = 16; + tx_slots = (is_playback) ? TX_SLOT_MONO : 0; + rx_slots = (is_playback) ? 0 : RX_SLOT_MONO; + break; + case 2: + slots = 16; + slot_width = 16; + tx_slots = (is_playback) ? TX_SLOT_STEREO : 0; + rx_slots = (is_playback) ? 0 : RX_SLOT_STEREO; + break; + case 8: + slots = 16; + slot_width = 16; + tx_slots = (is_playback) ? TX_SLOT_8CH : 0; + rx_slots = (is_playback) ? 0 : RX_SLOT_8CH; + break; + default: + return -EINVAL; + } + + dev_dbg(dev, "%s: CPU-DAI TDM: TX=0x%04X RX=0x%04x\n", __func__, + tx_slots, rx_slots); + ret = snd_soc_dai_set_tdm_slot(cpu_dai, tx_slots, rx_slots, slots, slot_width); + if (ret) + return ret; + + dev_dbg(dev, "%s: CODEC-DAI TDM: TX=0x%04X RX=0x%04x\n", __func__, + tx_slots, rx_slots); + ret = snd_soc_dai_set_tdm_slot(codec_dai, tx_slots, rx_slots, slots, slot_width); + if (ret) + return ret; + + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { + dev_dbg(dev, "%s: Setup IF1 for FM-radio.\n", __func__); + fmt_if1 = SND_SOC_DAIFMT_CBM_CFM | SND_SOC_DAIFMT_I2S; + ret = ab8500_audio_setup_if1(codec_dai->codec, fmt_if1, 16, 1); + if (ret) + return ret; + } + + return 0; +} + +struct snd_soc_ops ux500_ab8500_ops[] = { + { + .hw_params = ux500_ab8500_hw_params, + .shutdown = ux500_ab8500_shutdown, + } +}; + +int ux500_ab8500_machine_init(struct snd_soc_pcm_runtime *rtd) +{ + struct snd_soc_codec *codec = rtd->codec; + struct device *dev = rtd->card->dev; + int status; + + dev_dbg(dev, "%s Enter.\n", __func__); + + /* Add controls */ + status = snd_soc_add_codec_controls(codec, ux500_ab8500_ctrls, + ARRAY_SIZE(ux500_ab8500_ctrls)); + if (status < 0) { + pr_err("%s: failed to add machine-controls (%d).\n", + __func__, status); + return status; + } + + status = snd_soc_dapm_enable_pin(&codec->dapm, "Headset Left"); + status |= snd_soc_dapm_enable_pin(&codec->dapm, "Headset Right"); + + return status; +} + diff --git a/sound/soc/ux500/ux500_ab8500.h b/sound/soc/ux500/ux500_ab8500.h new file mode 100644 index 0000000..76ec1e6 --- /dev/null +++ b/sound/soc/ux500/ux500_ab8500.h @@ -0,0 +1,21 @@ +/* + * Copyright (C) ST-Ericsson SA 2012 + * + * Author: Ola Lilja <ola.o.lilja(a)stericsson.com> + * for ST-Ericsson. + * + * License terms: + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#ifndef UX500_AB8500_H +#define UX500_AB8500_H + +extern struct snd_soc_ops ux500_ab8500_ops[]; + +int ux500_ab8500_machine_init(struct snd_soc_pcm_runtime *runtime); + +#endif -- 1.7.8.3

2 11

Re: [alsa-devel] ASoC: wm9712: Microphone doesn't work, "Capture Volume" inverted
by Mark Brown 02 May '12

02 May '12

On Tue, May 01, 2012 at 10:07:57PM +0200, Hans J. Koch wrote: > On Tue, May 01, 2012 at 06:12:07PM +0100, Mark Brown wrote: > > The driver knows exactly which registers are volatile > Then this is the first complex chip I've ever seen where the datasheet covers That's... horrifying, really. The WM9712 really isn't at all complex by modern standards for that matter, but the idea that it's common to have devices with documented registers that might spontaneously change in normal operation doesn't seem at all clever. What happens if the configuration that was set was important? > all corner cases. And what about things like dirty supply voltages or EMI? If you've got that sort of problem with supply quality or EMI there's obviously a very serious system issue to contend with, one that typically requires highly aggressive action to resolve - you're starting to get into games like having to constantly poll the device and restart it if you detect that it fell over which isn't pleasant and most likely means you've already hit serious user visible consequences. Things like device initialisation will need to be redone, for example. I can only think of one driver that takes such measures, and it's actually relying on restore from register cache for part of the recovery :) That said, many devices will get a moderate degree of robustness against this through power saving - the closer the device can get to cold during idle the better from this point of view, and in many cases it's possible to completely power down the device when idle. A common idiom is to take the device down to cold when idle then dump the setup changes that don't need sequencing into the device from cache before doing the bits that need sequencing, especially where many of the register settings can be mapped direictly into userspace. Indeed I'm not sure a cache isn't a bad plan for detecting this sort of thing; if you find the cache values diverging from the physical values for non-volatile registers you know something's up. > Just to save a few clock cycles every now and then you happily accept the > risk of the driver simply stop working after an unusual event, without > any chances of recovery. For the sort of devices we're talking about here it's way more than a few clock cycles that are involved, you're talking about fairly slow and at times congested buses like I2C here. Never mind what happens when someone decides to use a bigbanged controller, which is more common than one might dream of. Obviously if you're on a bus with trivial I/O costs the tradeoffs vary but for the sort of buses we're talking about it's much easier to see a win. Indeed with many older devices readback just isn't physically supported in the first place so if you want to do any kind of readback based thing you're going to have to cache in some way. This was true for the majority of devices at the time WM9712 was new. > Sound is not my usual playing ground, but at least I learned now why the > sound system on my desktop refuses to work after a few days uptime... I don't actually think desktop drivers bother with this much, though ICBW. They relatively infrequently use the slow buses. I'd suggest reporting the issue, anyway - it's probably more constructive. > Fortunately, most other subsystems would never accept such code for mainline. This is actually a standard feature of the regmap API that drivers can use if they want, there's a bunch of device classes where it can offer a useful win (those that typically have slow control interfaces and not so mnay volatile registers).

1 0

[alsa-devel] [PATCH] ASoC: wm_hubs: Cache multiple DCS offsets
by Mark Brown 01 May '12

01 May '12

Rather than invalidating the cached DCS value every time the headphone gain changes store multiple values, indexed by gain. This allows the optimisation we get from the cache to take effect more often. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm_hubs.c | 74 ++++++++++++++++++++++++++++++++++++++------ sound/soc/codecs/wm_hubs.h | 3 +- 2 files changed, 67 insertions(+), 10 deletions(-) diff --git a/sound/soc/codecs/wm_hubs.c b/sound/soc/codecs/wm_hubs.c index 8a29843..dfe957a 100644 --- a/sound/soc/codecs/wm_hubs.c +++ b/sound/soc/codecs/wm_hubs.c @@ -143,12 +143,69 @@ static bool wm_hubs_dac_hp_direct(struct snd_soc_codec *codec) return true; } +struct wm_hubs_dcs_cache { + struct list_head list; + unsigned int left; + unsigned int right; + u16 dcs_cfg; +}; + +static bool wm_hubs_dcs_cache_get(struct snd_soc_codec *codec, + struct wm_hubs_dcs_cache **entry) +{ + struct wm_hubs_data *hubs = snd_soc_codec_get_drvdata(codec); + struct wm_hubs_dcs_cache *cache; + unsigned int left, right; + + left = snd_soc_read(codec, WM8993_LEFT_OUTPUT_VOLUME); + left &= WM8993_HPOUT1L_VOL_MASK; + + right = snd_soc_read(codec, WM8993_RIGHT_OUTPUT_VOLUME); + right &= WM8993_HPOUT1R_VOL_MASK; + + list_for_each_entry(cache, &hubs->dcs_cache, list) { + if (cache->left != left || cache->right != right) + continue; + + *entry = cache; + return true; + } + + return false; +} + +static void wm_hubs_dcs_cache_set(struct snd_soc_codec *codec, u16 dcs_cfg) +{ + struct wm_hubs_data *hubs = snd_soc_codec_get_drvdata(codec); + struct wm_hubs_dcs_cache *cache; + + if (hubs->no_cache_dac_hp_direct) + return; + + cache = devm_kzalloc(codec->dev, sizeof(*cache), GFP_KERNEL); + if (!cache) { + dev_err(codec->dev, "Failed to allocate DCS cache entry\n"); + return; + } + + cache->left = snd_soc_read(codec, WM8993_LEFT_OUTPUT_VOLUME); + cache->left &= WM8993_HPOUT1L_VOL_MASK; + + cache->right = snd_soc_read(codec, WM8993_RIGHT_OUTPUT_VOLUME); + cache->right &= WM8993_HPOUT1R_VOL_MASK; + + cache->dcs_cfg = dcs_cfg; + + list_add_tail(&cache->list, &hubs->dcs_cache); +} + /* * Startup calibration of the DC servo */ static void calibrate_dc_servo(struct snd_soc_codec *codec) { struct wm_hubs_data *hubs = snd_soc_codec_get_drvdata(codec); + struct wm_hubs_dcs_cache *cache; s8 offset; u16 reg, reg_l, reg_r, dcs_cfg, dcs_reg; @@ -163,10 +220,11 @@ static void calibrate_dc_servo(struct snd_soc_codec *codec) /* If we're using a digital only path and have a previously * callibrated DC servo offset stored then use that. */ - if (wm_hubs_dac_hp_direct(codec) && hubs->dac_hp_direct_dcs) { - dev_dbg(codec->dev, "Using cached DC servo offset %x\n", - hubs->dac_hp_direct_dcs); - snd_soc_write(codec, dcs_reg, hubs->dac_hp_direct_dcs); + if (wm_hubs_dac_hp_direct(codec) && + wm_hubs_dcs_cache_get(codec, &cache)) { + dev_dbg(codec->dev, "Using cached DCS offset %x for %d,%d\n", + cache->dcs_cfg, cache->left, cache->right); + snd_soc_write(codec, dcs_reg, cache->dcs_cfg); wait_for_dc_servo(codec, WM8993_DCS_TRIG_DAC_WR_0 | WM8993_DCS_TRIG_DAC_WR_1); @@ -241,8 +299,8 @@ static void calibrate_dc_servo(struct snd_soc_codec *codec) /* Save the callibrated offset if we're in class W mode and * therefore don't have any analogue signal mixed in. */ - if (wm_hubs_dac_hp_direct(codec) && !hubs->no_cache_dac_hp_direct) - hubs->dac_hp_direct_dcs = dcs_cfg; + if (wm_hubs_dac_hp_direct(codec)) + wm_hubs_dcs_cache_set(codec, dcs_cfg); } /* @@ -257,9 +315,6 @@ static int wm8993_put_dc_servo(struct snd_kcontrol *kcontrol, ret = snd_soc_put_volsw(kcontrol, ucontrol); - /* Updating the analogue gains invalidates the DC servo cache */ - hubs->dac_hp_direct_dcs = 0; - /* If we're applying an offset correction then updating the * callibration would be likely to introduce further offsets. */ if (hubs->dcs_codes_l || hubs->dcs_codes_r || hubs->no_series_update) @@ -1057,6 +1112,7 @@ int wm_hubs_add_analogue_routes(struct snd_soc_codec *codec, struct wm_hubs_data *hubs = snd_soc_codec_get_drvdata(codec); struct snd_soc_dapm_context *dapm = &codec->dapm; + INIT_LIST_HEAD(&hubs->dcs_cache); init_completion(&hubs->dcs_done); snd_soc_dapm_add_routes(dapm, analogue_routes, diff --git a/sound/soc/codecs/wm_hubs.h b/sound/soc/codecs/wm_hubs.h index 71861fc..da2dc89 100644 --- a/sound/soc/codecs/wm_hubs.h +++ b/sound/soc/codecs/wm_hubs.h @@ -16,6 +16,7 @@ #include <linux/completion.h> #include <linux/interrupt.h> +#include <linux/list.h> #include <sound/control.h> struct snd_soc_codec; @@ -32,7 +33,7 @@ struct wm_hubs_data { int no_series_update; bool no_cache_dac_hp_direct; - u16 dac_hp_direct_dcs; + struct list_head dcs_cache; bool (*check_class_w_digital)(struct snd_soc_codec *); bool lineout1_se; -- 1.7.10

1 0

Re: [alsa-devel] ASoC: wm9712: Microphone doesn't work, "Capture Volume" inverted
by Mark Brown 01 May '12

01 May '12

On Tue, May 01, 2012 at 01:44:58AM +0200, Hans J. Koch wrote: > On Mon, Apr 30, 2012 at 10:43:33PM +0100, Mark Brown wrote: > > I'm not entirely sure you've looked at the code here... > Oh yes, sorry. I got distracted by your mentioning of the suppressed writes. > Actually, we have suppressed reads. ac97_read() does a "return cache[reg];" > for most registers, assuming the hardware register cannot change after a > ac97_write(). That might or might not be true, to me it looks dangerous. The driver knows exactly which registers are volatile and takes advantage of this - this is entirely idiomatic for devices like this and not really that hard to get right.

1 0

[alsa-devel] davinci-mcasp - external MCLK, CPU generates WCLK and BCLK, slave codec(s), full duplex issues
by Jérôme Carretero 01 May '12

01 May '12

Hi, Note: I opened a thread on TI's E2E forums too, the thread is at: http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/185810.as… Linux is v3.3. Repeating what I have put there: - As we will be using multiple codecs on McASP, we have put the codecs as slaves. We are also using a 8.192MHz external master clock. - We have patched davinci-mcasp.c to handle this mode ("SND_SOC_DAIFMT_EM_CBS_CFS"), and refer to it for the CPU DAI configuration in the machine driver. - Our setup currently has an AIC3X codec, connected to the TX clocks of McASP. The RX clocks are not used, they are left hanging, so we need to enable the TX clocks even when recording. - We only plan to support 32kHz, so currently we have left an ugly hack in the code. - It almost works, but we have a nasty problem: - When performing a capture alone, the sound is recorded as expected - When performing a playback alone, no problem - When starting a playback then a capture, no problem - When starting a capture then a playback, the playback will hang, the stream won't accept more data; no perturbation on the recording side. A review of the McASP code WRT/ SPRUH77A (OMAP-L138 Technical Reference Manual) does not really help. Now, I performed some tracing: - patched the davinci-mcasp.c code, to trace register accesses See attached file. The patch also contains the differences explained on the e2e forum post. - produced the "yes" file by running the "playback then capture" scenario: dmesg -c cat /dev/urandom | pv -B 3200 | aplay -f S16 -r 32000 aplay -B 20000 -f S16 -r 32000 -C -V mono /dev/null dmesg -c | gzip > yes.gz - produced the "no" file by running the "capture then playback" scenario: dmesg -c aplay -B 20000 -f S16 -r 32000 -C -V mono /dev/null cat /dev/urandom | pv -B 3200 | aplay -f S16 -r 32000 dmesg -c | gzip > no.gz And I still have issues seing what could be wrong. Could you somehow help me ? Best regards, -- cJ PS: sorry for the resend, the initial message exceeded the allowed mailing list message size.

1 0

[alsa-devel] [PATCH] s3c2412-i2s: Fix dai registration
by Heiko Stübner 01 May '12

01 May '12

As s3c2412-i2s is using the s3c_i2sv2 it should call the more specialised s3c_i2sv2_register_dai instead of simply calling snd_soc_register_dai. Without this call the snd_soc_dai_ops structure isn't initialised correctly. Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> --- sound/soc/samsung/s3c2412-i2s.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/samsung/s3c2412-i2s.c b/sound/soc/samsung/s3c2412-i2s.c index 7218507..79fbeea 100644 --- a/sound/soc/samsung/s3c2412-i2s.c +++ b/sound/soc/samsung/s3c2412-i2s.c @@ -166,7 +166,7 @@ static struct snd_soc_dai_driver s3c2412_i2s_dai = { static __devinit int s3c2412_iis_dev_probe(struct platform_device *pdev) { - return snd_soc_register_dai(&pdev->dev, &s3c2412_i2s_dai); + return s3c_i2sv2_register_dai(&pdev->dev, -1, &s3c2412_i2s_dai); } static __devexit int s3c2412_iis_dev_remove(struct platform_device *pdev) -- 1.7.5.4

2 2