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

[alsa-devel] Listing virtual devices for a sound card (aplay -L)
by Nitin PAI 26 Feb '10

26 Feb '10

Hi, I have added proprietary sound cards which are statically compiled in the kernel. Card 0: Name=X, Card 1: Name=Y. I want to create virtual devices using these cards, like front, left,surround,iec958. I see that this is usually done at /usr/share/alsa/cards/.... Please let me know how this mapping works? I mean how does aplay -L list these devices by mapping the sound card to the ones in /usr/share/alsa/cards/... I tried creating X.conf and Y.conf there with front,left,surroud,iec958, but aplay -L doesnt seem to recognize them. Also, I want iec958 card to be one of the cards listed via aplay -L, and defining this in asound.conf gives error with aplay. Any help will be appreciated. Thanks, Nitin

1 1

[alsa-devel] [RFC] ASoC: Allow mulitple usage of codec and cpu dai
by Jassi Brar 26 Feb '10

26 Feb '10

We can have a snd_soc_dai i.e, cpu_dai and codec_dai, shared among two or more dai_links by avoiding shutting-down/powering-up if the dai is already in an appropriate state. For that, we change semantics of the snd_soc_dai.active flag from indicator to reference counter. This patch only attempts to block duplicate startup/shutdown and the mute callbacks, presuming currently no dai driver anticipates 'dai reuse'. Signed-off-by: Jassi Brar <jassi.brar(a)samsung.com> --- include/sound/soc.h | 2 +- sound/soc/soc-core.c | 47 ++++++++++++++++++++++++++++------------------- 2 files changed, 29 insertions(+), 20 deletions(-) The codec->active can also be deducted by codec_dai->capture/playback.active So, we can get rid of snd_soc_codec.active field as well to reduce number of variables we have to manage in future while making delicate changes in ASoC. diff --git a/include/sound/soc.h b/include/sound/soc.h index 27a2ad9..f792c18 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -375,7 +375,7 @@ struct snd_soc_pcm_stream { unsigned int rate_max; /* max rate */ unsigned int channels_min; /* min channels */ unsigned int channels_max; /* max channels */ - unsigned int active:1; /* stream is in use */ + unsigned int active; /* num of active users of the stream */ }; /* SoC audio ops */ diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 2b66719..459f1f5 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -352,7 +352,7 @@ static int soc_pcm_open(struct snd_pcm_substream *substream) mutex_lock(&pcm_mutex); /* startup the audio subsystem */ - if (cpu_dai->ops->startup) { + if (cpu_dai->active == 0 && cpu_dai->ops->startup) { ret = cpu_dai->ops->startup(substream, cpu_dai); if (ret < 0) { printk(KERN_ERR "asoc: can't open interface %s\n", @@ -369,7 +369,7 @@ static int soc_pcm_open(struct snd_pcm_substream *substream) } } - if (codec_dai->ops->startup) { + if (codec_dai->active == 0 && codec_dai->ops->startup) { ret = codec_dai->ops->startup(substream, codec_dai); if (ret < 0) { printk(KERN_ERR "asoc: can't open codec %s\n", @@ -454,11 +454,15 @@ static int soc_pcm_open(struct snd_pcm_substream *substream) pr_debug("asoc: min rate %d max rate %d\n", runtime->hw.rate_min, runtime->hw.rate_max); - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) - cpu_dai->playback.active = codec_dai->playback.active = 1; - else - cpu_dai->capture.active = codec_dai->capture.active = 1; - cpu_dai->active = codec_dai->active = 1; + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { + cpu_dai->playback.active++; + codec_dai->playback.active++; + } else { + cpu_dai->capture.active++; + codec_dai->capture.active++; + } + cpu_dai->active++; + codec_dai->active++; card->codec->active++; mutex_unlock(&pcm_mutex); return 0; @@ -534,27 +538,28 @@ static int soc_codec_close(struct snd_pcm_substream *substream) mutex_lock(&pcm_mutex); - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) - cpu_dai->playback.active = codec_dai->playback.active = 0; - else - cpu_dai->capture.active = codec_dai->capture.active = 0; - - if (codec_dai->playback.active == 0 && - codec_dai->capture.active == 0) { - cpu_dai->active = codec_dai->active = 0; + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { + cpu_dai->playback.active--; + codec_dai->playback.active--; + } else { + cpu_dai->capture.active--; + codec_dai->capture.active--; } + + cpu_dai->active--; + codec_dai->active--; codec->active--; /* Muting the DAC suppresses artifacts caused during digital * shutdown, for example from stopping clocks. */ - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + if (codec_dai->active == 0 && substream->stream == SNDRV_PCM_STREAM_PLAYBACK) snd_soc_dai_digital_mute(codec_dai, 1); - if (cpu_dai->ops->shutdown) + if (cpu_dai->active == 0 && cpu_dai->ops->shutdown) cpu_dai->ops->shutdown(substream, cpu_dai); - if (codec_dai->ops->shutdown) + if (codec_dai->active == 0 && codec_dai->ops->shutdown) codec_dai->ops->shutdown(substream, codec_dai); if (machine->ops && machine->ops->shutdown) @@ -563,6 +568,10 @@ static int soc_codec_close(struct snd_pcm_substream *substream) if (platform->pcm_ops->close) platform->pcm_ops->close(substream); + /* Skip DAPM if codec is still active via some other dai_link */ + if (codec_dai->active) + goto exit; + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { /* start delayed pop wq here for playback streams */ codec_dai->pop_wait = 1; @@ -574,7 +583,7 @@ static int soc_codec_close(struct snd_pcm_substream *substream) codec_dai->capture.stream_name, SND_SOC_DAPM_STREAM_STOP); } - +exit: mutex_unlock(&pcm_mutex); return 0; } -- 1.6.2.5

3 5

[alsa-devel] [PATCH] ASoC: Allow mulitple usage count of codec and cpu dai
by Jassi Brar 26 Feb '10

26 Feb '10

If we are to have a snd_soc_dai i.e, cpu_dai and codec_dai, shared among two or more dai_links we need to log the number of active users of the dai. For that, we change semantics of the snd_soc_dai.active flag from indicator to reference counter. Signed-off-by: Jassi Brar <jassi.brar(a)samsung.com> --- include/sound/soc.h | 2 +- sound/soc/soc-core.c | 31 ++++++++++++++++++------------- 2 files changed, 19 insertions(+), 14 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index 27a2ad9..f792c18 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -375,7 +375,7 @@ struct snd_soc_pcm_stream { unsigned int rate_max; /* max rate */ unsigned int channels_min; /* min channels */ unsigned int channels_max; /* max channels */ - unsigned int active:1; /* stream is in use */ + unsigned int active; /* num of active users of the stream */ }; /* SoC audio ops */ diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 2b66719..0211369 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -454,11 +454,15 @@ static int soc_pcm_open(struct snd_pcm_substream *substream) pr_debug("asoc: min rate %d max rate %d\n", runtime->hw.rate_min, runtime->hw.rate_max); - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) - cpu_dai->playback.active = codec_dai->playback.active = 1; - else - cpu_dai->capture.active = codec_dai->capture.active = 1; - cpu_dai->active = codec_dai->active = 1; + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { + cpu_dai->playback.active++; + codec_dai->playback.active++; + } else { + cpu_dai->capture.active++; + codec_dai->capture.active++; + } + cpu_dai->active++; + codec_dai->active++; card->codec->active++; mutex_unlock(&pcm_mutex); return 0; @@ -534,15 +538,16 @@ static int soc_codec_close(struct snd_pcm_substream *substream) mutex_lock(&pcm_mutex); - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) - cpu_dai->playback.active = codec_dai->playback.active = 0; - else - cpu_dai->capture.active = codec_dai->capture.active = 0; - - if (codec_dai->playback.active == 0 && - codec_dai->capture.active == 0) { - cpu_dai->active = codec_dai->active = 0; + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { + cpu_dai->playback.active--; + codec_dai->playback.active--; + } else { + cpu_dai->capture.active--; + codec_dai->capture.active--; } + + cpu_dai->active--; + codec_dai->active--; codec->active--; /* Muting the DAC suppresses artifacts caused during digital -- 1.6.2.5

3 2

[alsa-devel] Procedure to add files in /usr/share/alsa/cards/
by Nitin PAI 26 Feb '10

26 Feb '10

Hi, What is the procedure to add a new conf file in /usr/share/alsa/cards ? What should be the name of the file and any other changes i need to make so that aplay -L displayes all the devices. Thanks, Nitin

1 0

[alsa-devel] [PATCH] [patch 2/2] AC97: add full duplex support for atmel AT91 and AVR.
by Sedji Gaouaou 26 Feb '10

26 Feb '10

This patch add full duplex support on AT91 and AVR. It was a bug: we needed to check first if there are some chips opened so we could enable both reception and sending of the data. Signed-off-by: Sedji Gaouaou <sedji.gaouaou(a)atmel.com> --- sound/atmel/ac97c.c | 16 ++++++++++++---- 1 files changed, 12 insertions(+), 4 deletions(-) diff --git a/sound/atmel/ac97c.c b/sound/atmel/ac97c.c index d48a59a..6f5e22c 100644 --- a/sound/atmel/ac97c.c +++ b/sound/atmel/ac97c.c @@ -339,7 +339,11 @@ static int atmel_ac97c_playback_prepare(struct snd_pcm_substream *substream) ac97c_writel(chip, OCA, word); /* configure sample format and size */ - word = AC97C_CMR_DMAEN | AC97C_CMR_SIZE_16; + word = ac97c_readl(chip, CAMR); + if (chip->opened <= 1) + word = AC97C_CMR_DMAEN | AC97C_CMR_SIZE_16; + else + word |= AC97C_CMR_DMAEN | AC97C_CMR_SIZE_16; switch (runtime->format) { case SNDRV_PCM_FORMAT_S16_LE: @@ -426,7 +430,11 @@ static int atmel_ac97c_capture_prepare(struct snd_pcm_substream *substream) ac97c_writel(chip, ICA, word); /* configure sample format and size */ - word = AC97C_CMR_DMAEN | AC97C_CMR_SIZE_16; + word = ac97c_readl(chip, CAMR); + if (chip->opened <= 1) + word = AC97C_CMR_DMAEN | AC97C_CMR_SIZE_16; + else + word |= AC97C_CMR_DMAEN | AC97C_CMR_SIZE_16; switch (runtime->format) { case SNDRV_PCM_FORMAT_S16_LE: @@ -506,7 +514,7 @@ atmel_ac97c_playback_trigger(struct snd_pcm_substream *substream, int cmd) } else { ptcr = ATMEL_PDC_TXTEN; } - camr |= AC97C_CMR_CENA; + camr |= AC97C_CMR_CENA | AC97C_CSR_ENDTX; break; case SNDRV_PCM_TRIGGER_PAUSE_PUSH: /* fall through */ case SNDRV_PCM_TRIGGER_SUSPEND: /* fall through */ @@ -551,7 +559,7 @@ atmel_ac97c_capture_trigger(struct snd_pcm_substream *substream, int cmd) } else { ptcr = ATMEL_PDC_RXTEN; } - camr |= AC97C_CMR_CENA; + camr |= AC97C_CMR_CENA | AC97C_CSR_ENDRX; break; case SNDRV_PCM_TRIGGER_PAUSE_PUSH: /* fall through */ case SNDRV_PCM_TRIGGER_SUSPEND: /* fall through */ -- 1.5.6.5

3 2

[alsa-devel] Why use spin_lock or spin_lock_irq in trigger callback (audio capture)?
by Yiliang Bao 26 Feb '10

26 Feb '10

Hi, I looked at some PCI audio capture driver like BT878 (sound/pci/bt87x.c) or SAA7134 (drivers/media/video/saa7134-alsa.c), I found that spin_lock instead of spin_lock_irq (or spin_lock_irqsave) is used in trigger function. Is there any reason for that? Thanks, Yiliang

2 1

Re: [alsa-devel] [alsa-cvslog] alsa-kernel: Official ALSA project GIT repository for Linux 2.6 branch, master now at v2.6.31-rc8-407-gfc9e4a3
by Takashi Iwai 26 Feb '10

26 Feb '10

At Tue, 6 Oct 2009 08:36:04 +0200 (CEST), noreply-git(a)alsa-project.org wrote: > commit fc9e4a3811567f8d1d4c263a89e27b52c90d6098 > Author: Clemens Ladisch <clemens(a)ladisch.de> > AuthorDate: Tue Oct 6 08:21:04 2009 +0200 > Commit: Clemens Ladisch <clemens(a)ladisch.de> > CommitDate: Tue Oct 6 08:21:04 2009 +0200 > > sound: via82xx: move DXS volume controls to PCM interface > > The "VIA DXS" controls are actually volume controls that apply to the > four PCM substreams, so we better indicate this connection by moving the > controls to the PCM interface. > > Commit b452e08e73c0e3dbb0be82130217be4b7084299e in 2.6.30 broke the > restoring of these volumes by "amixer restore" that most distributions > use; the renaming in this patch cures that regression by preventing > amixer from applying the old, wrong volume levels to the new controls. > http://bugzilla.kernel.org/show_bug.cgi?id=14151 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532613 > > Signed-off-by: Clemens Ladisch <clemens(a)ladisch.de> > Cc: <stable(a)kernel.org> Well, this control was once removed, and then revived due to complains by users who have used it in mixer. Moving this to PCM iface does almost the same thing, disabling an easy way to access it. I'm afraid that this patch might be regarded as another "regression". For such an old driver, the compatibility is the most important item. If any, we must provide a way to back to the old behavior. thanks, Takashi > > ----------------------------------------------------------------------- > > Diffstat: > sound/pci/via82xx.c | 27 ++++++++++++++++++--------- > 1 files changed, 18 insertions(+), 9 deletions(-) > > > Patch -------------- (max 1500 lines) > diff --git a/sound/pci/via82xx.c b/sound/pci/via82xx.c > index acfa476..91683a3 100644 > --- a/sound/pci/via82xx.c > +++ b/sound/pci/via82xx.c > @@ -1626,7 +1626,7 @@ static int snd_via8233_dxs_volume_get(struct snd_kcontrol *kcontrol, > struct snd_ctl_elem_value *ucontrol) > { > struct via82xx *chip = snd_kcontrol_chip(kcontrol); > - unsigned int idx = snd_ctl_get_ioff(kcontrol, &ucontrol->id); > + unsigned int idx = kcontrol->id.subdevice; > > ucontrol->value.integer.value[0] = VIA_DXS_MAX_VOLUME - chip->playback_volume[idx][0]; > ucontrol->value.integer.value[1] = VIA_DXS_MAX_VOLUME - chip->playback_volume[idx][1]; > @@ -1646,7 +1646,7 @@ static int snd_via8233_dxs_volume_put(struct snd_kcontrol *kcontrol, > struct snd_ctl_elem_value *ucontrol) > { > struct via82xx *chip = snd_kcontrol_chip(kcontrol); > - unsigned int idx = snd_ctl_get_ioff(kcontrol, &ucontrol->id); > + unsigned int idx = kcontrol->id.subdevice; > unsigned long port = chip->port + 0x10 * idx; > unsigned char val; > int i, change = 0; > @@ -1705,11 +1705,12 @@ static struct snd_kcontrol_new snd_via8233_pcmdxs_volume_control __devinitdata = > }; > > static struct snd_kcontrol_new snd_via8233_dxs_volume_control __devinitdata = { > - .name = "VIA DXS Playback Volume", > - .iface = SNDRV_CTL_ELEM_IFACE_MIXER, > + .iface = SNDRV_CTL_ELEM_IFACE_PCM, > + .device = 0, > + /* .subdevice set later */ > + .name = "PCM Playback Volume", > .access = (SNDRV_CTL_ELEM_ACCESS_READWRITE | > SNDRV_CTL_ELEM_ACCESS_TLV_READ), > - .count = 4, > .info = snd_via8233_dxs_volume_info, > .get = snd_via8233_dxs_volume_get, > .put = snd_via8233_dxs_volume_put, > @@ -1936,10 +1937,18 @@ static int __devinit snd_via8233_init_misc(struct via82xx *chip) > } > else /* Using DXS when PCM emulation is enabled is really weird */ > { > - /* Standalone DXS controls */ > - err = snd_ctl_add(chip->card, snd_ctl_new1(&snd_via8233_dxs_volume_control, chip)); > - if (err < 0) > - return err; > + for (i = 0; i < 4; ++i) { > + struct snd_kcontrol *kctl; > + > + kctl = snd_ctl_new1( > + &snd_via8233_dxs_volume_control, chip); > + if (!kctl) > + return -ENOMEM; > + kctl->id.subdevice = i; > + err = snd_ctl_add(chip->card, kctl); > + if (err < 0) > + return err; > + } > } > } > /* select spdif data slot 10/11 */ > ------- End of patch > > hooks/update > --- > Git Source Code Management System > hooks/update refs/heads/master \ > 62f08ef9739c5cb5fff5b5bdec3bc02d522b9a12 \ > fc9e4a3811567f8d1d4c263a89e27b52c90d6098 > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Alsa-cvslog mailing list > Alsa-cvslog(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/alsa-cvslog >

6 22

[alsa-devel] issues porting codec to s3c2443
by Austin, Brian 26 Feb '10

26 Feb '10

Hello, I have forward ported the CS42L52 from 2.6.26.2 to the current asoc git tree. The codec and smdk2443-cs42l52 drivers load correctly, at least I think so, and would like to submit the CS42L52 driver but am having some issues with s3c2412-i2s. From my previous kernel version to the latest there has been significant changes to the S3C architecture and I pretty sure that I am missing something because of that. The question is, is it ok to submit the codec standalone and have someone look at it to make sure I made the correct changes. No compiler warnings occur. My port was based off of the WM8750 if that helps any Here is the output from my SMDK2443 Simtec Advanced Linux Sound Architecture Driver Version 1.0.18a. No device for DAI CS42L52 No device for DAI s3c2412-i2s SMDK2443 cs42l52 ALSA SoC driver ver1.1 10/2008 soc-audio soc-audio: RXEN: Invalid MODE in IISMOD CS42L52: Cirrus Logic ALSA SoC codec cs42l52 driver verison 1.1 10/2008 ALSA device list: No soundcards found. It seems that the S3C2412 I2S is not setup correctly for my platform. Thanks, Brian Austin

4 6

[alsa-devel] aplay: possible circular locking dependency detected
by Daniel Mack 25 Feb '10

25 Feb '10

I got this once while testing an USB audio device. Appeareantly not reproducable. Daniel Feb 21 14:26:29 jup kernel: [69661.385427] Feb 21 14:26:29 jup kernel: [69661.385430] ======================================================= Feb 21 14:26:29 jup kernel: [69661.385435] [ INFO: possible circular locking dependency detected ] Feb 21 14:26:29 jup kernel: [69661.385439] 2.6.33-rc8 #21 Feb 21 14:26:29 jup kernel: [69661.385441] ------------------------------------------------------- Feb 21 14:26:29 jup kernel: [69661.385444] aplay/11761 is trying to acquire lock: Feb 21 14:26:29 jup kernel: [69661.385446] (sysfs_mutex){+.+.+.}, at: [<c10f0668>] sysfs_get_dirent+0x15/0x4c Feb 21 14:26:29 jup kernel: [69661.385457] Feb 21 14:26:29 jup kernel: [69661.385457] but task is already holding lock: Feb 21 14:26:29 jup kernel: [69661.385460] (&pcm->open_mutex){+.+.+.}, at: [<fb68bc8e>] snd_pcm_release+0x55/0x9e [snd_pcm] Feb 21 14:26:29 jup kernel: [69661.385474] Feb 21 14:26:29 jup kernel: [69661.385474] which lock already depends on the new lock. Feb 21 14:26:29 jup kernel: [69661.385476] Feb 21 14:26:29 jup kernel: [69661.385478] Feb 21 14:26:29 jup kernel: [69661.385479] the existing dependency chain (in reverse order) is: Feb 21 14:26:29 jup kernel: [69661.385481] Feb 21 14:26:29 jup kernel: [69661.385482] -> #2 (&pcm->open_mutex){+.+.+.}: Feb 21 14:26:29 jup kernel: [69661.385487] [<c1059070>] __lock_acquire+0x10ff/0x1422 Feb 21 14:26:29 jup kernel: [69661.385493] [<c105943b>] lock_acquire+0xa8/0xbf Feb 21 14:26:29 jup kernel: [69661.385498] [<c13720d3>] mutex_lock_nested+0x47/0x2b2 Feb 21 14:26:29 jup kernel: [69661.385503] [<fb68bc8e>] snd_pcm_release+0x55/0x9e [snd_pcm] Feb 21 14:26:29 jup kernel: [69661.385513] [<c10aabe9>] __fput+0xeb/0x196 Feb 21 14:26:29 jup kernel: [69661.385517] [<c10aacad>] fput+0x19/0x1b Feb 21 14:26:29 jup kernel: [69661.385522] [<c109ae3b>] remove_vma+0x39/0x58 Feb 21 14:26:29 jup kernel: [69661.385528] [<c109bab3>] do_munmap+0x23c/0x259 Feb 21 14:26:29 jup kernel: [69661.385532] [<c109bb00>] sys_munmap+0x30/0x3f Feb 21 14:26:29 jup kernel: [69661.385536] [<c10028d0>] sysenter_do_call+0x12/0x36 Feb 21 14:26:29 jup kernel: [69661.385541] Feb 21 14:26:29 jup kernel: [69661.385542] -> #1 (&mm->mmap_sem){++++++}: Feb 21 14:26:29 jup kernel: [69661.385547] [<c1059070>] __lock_acquire+0x10ff/0x1422 Feb 21 14:26:29 jup kernel: [69661.385551] [<c105943b>] lock_acquire+0xa8/0xbf Feb 21 14:26:29 jup kernel: [69661.385556] [<c10968db>] might_fault+0x6b/0x88 Feb 21 14:26:29 jup kernel: [69661.385561] [<c11b3cf0>] copy_to_user+0x2c/0xfc Feb 21 14:26:29 jup kernel: [69661.385565] [<c10b5e73>] filldir64+0x97/0xcd Feb 21 14:26:29 jup kernel: [69661.385570] [<c10f0534>] sysfs_readdir+0x117/0x14b Feb 21 14:26:29 jup kernel: [69661.385574] [<c10b6085>] vfs_readdir+0x68/0x94 Feb 21 14:26:29 jup kernel: [69661.385578] [<c10b6114>] sys_getdents64+0x63/0xa0 Feb 21 14:26:29 jup kernel: [69661.385582] [<c10028d0>] sysenter_do_call+0x12/0x36 Feb 21 14:26:29 jup kernel: [69661.385587] Feb 21 14:26:29 jup kernel: [69661.385587] -> #0 (sysfs_mutex){+.+.+.}: Feb 21 14:26:29 jup kernel: [69661.385592] [<c1058dc6>] __lock_acquire+0xe55/0x1422 Feb 21 14:26:29 jup kernel: [69661.385597] [<c105943b>] lock_acquire+0xa8/0xbf Feb 21 14:26:29 jup kernel: [69661.385601] [<c13720d3>] mutex_lock_nested+0x47/0x2b2 Feb 21 14:26:29 jup kernel: [69661.385605] [<c10f0668>] sysfs_get_dirent+0x15/0x4c Feb 21 14:26:29 jup kernel: [69661.385609] [<c10f1b4a>] sysfs_remove_group+0x1e/0xa3 Feb 21 14:26:29 jup kernel: [69661.385614] [<c12359b8>] dpm_sysfs_remove+0x10/0x12 Feb 21 14:26:29 jup kernel: [69661.385619] [<c123114c>] device_del+0x33/0x154 Feb 21 14:26:29 jup kernel: [69661.385625] [<c1231278>] device_unregister+0xb/0x15 Feb 21 14:26:29 jup kernel: [69661.385629] [<c129a209>] usb_remove_ep_devs+0x15/0x1f Feb 21 14:26:29 jup kernel: [69661.385635] [<c12943ff>] remove_intf_ep_devs+0x21/0x32 Feb 21 14:26:29 jup kernel: [69661.385640] [<c12954ea>] usb_set_interface+0x18c/0x22c Feb 21 14:26:29 jup kernel: [69661.385644] [<fc703cd7>] snd_usb_playback_close+0x20/0x33 [snd_usb_audio] Feb 21 14:26:29 jup kernel: [69661.385654] [<fb68bc10>] snd_pcm_release_substream+0x3d/0x66 [snd_pcm] Feb 21 14:26:29 jup kernel: [69661.385664] [<fb68bc95>] snd_pcm_release+0x5c/0x9e [snd_pcm] Feb 21 14:26:29 jup kernel: [69661.385673] [<c10aabe9>] __fput+0xeb/0x196 Feb 21 14:26:29 jup kernel: [69661.385677] [<c10aacad>] fput+0x19/0x1b Feb 21 14:26:29 jup kernel: [69661.385681] [<c109ae3b>] remove_vma+0x39/0x58 Feb 21 14:26:29 jup kernel: [69661.385685] [<c109bab3>] do_munmap+0x23c/0x259 Feb 21 14:26:29 jup kernel: [69661.385689] [<c109bb00>] sys_munmap+0x30/0x3f Feb 21 14:26:29 jup kernel: [69661.385693] [<c10028d0>] sysenter_do_call+0x12/0x36 Feb 21 14:26:29 jup kernel: [69661.385698] Feb 21 14:26:29 jup kernel: [69661.385698] other info that might help us debug this: Feb 21 14:26:29 jup kernel: [69661.385700] Feb 21 14:26:29 jup kernel: [69661.385702] 2 locks held by aplay/11761: Feb 21 14:26:29 jup kernel: [69661.385705] #0: (&mm->mmap_sem){++++++}, at: [<c109baf3>] sys_munmap+0x23/0x3f Feb 21 14:26:29 jup kernel: [69661.385711] #1: (&pcm->open_mutex){+.+.+.}, at: [<fb68bc8e>] snd_pcm_release+0x55/0x9e [snd_pcm] Feb 21 14:26:29 jup kernel: [69661.385723] Feb 21 14:26:29 jup kernel: [69661.385724] stack backtrace: Feb 21 14:26:29 jup kernel: [69661.385727] Pid: 11761, comm: aplay Not tainted 2.6.33-rc8 #21 Feb 21 14:26:29 jup kernel: [69661.385730] Call Trace: Feb 21 14:26:29 jup kernel: [69661.385735] [<c137062c>] ? printk+0xf/0x11 Feb 21 14:26:29 jup kernel: [69661.385740] [<c1057b26>] print_circular_bug+0x90/0x9c Feb 21 14:26:29 jup kernel: [69661.385744] [<c1058dc6>] __lock_acquire+0xe55/0x1422 Feb 21 14:26:29 jup kernel: [69661.385748] [<c105917f>] ? __lock_acquire+0x120e/0x1422 Feb 21 14:26:29 jup kernel: [69661.385753] [<c103d4d3>] ? try_to_del_timer_sync+0x9c/0xa4 Feb 21 14:26:29 jup kernel: [69661.385758] [<c105943b>] lock_acquire+0xa8/0xbf Feb 21 14:26:29 jup kernel: [69661.385762] [<c10f0668>] ? sysfs_get_dirent+0x15/0x4c Feb 21 14:26:29 jup kernel: [69661.385766] [<c10f0668>] ? sysfs_get_dirent+0x15/0x4c Feb 21 14:26:29 jup kernel: [69661.385769] [<c13720d3>] mutex_lock_nested+0x47/0x2b2 Feb 21 14:26:29 jup kernel: [69661.385773] [<c10f0668>] ? sysfs_get_dirent+0x15/0x4c Feb 21 14:26:29 jup kernel: [69661.385777] [<c137187f>] ? __mutex_unlock_slowpath+0xe9/0x105 Feb 21 14:26:29 jup kernel: [69661.385781] [<c10572e5>] ? trace_hardirqs_on_caller+0xff/0x120 Feb 21 14:26:29 jup kernel: [69661.385785] [<c10f0668>] sysfs_get_dirent+0x15/0x4c Feb 21 14:26:29 jup kernel: [69661.385789] [<c10f1b4a>] sysfs_remove_group+0x1e/0xa3 Feb 21 14:26:29 jup kernel: [69661.385793] [<c12359b8>] dpm_sysfs_remove+0x10/0x12 Feb 21 14:26:29 jup kernel: [69661.385797] [<c123114c>] device_del+0x33/0x154 Feb 21 14:26:29 jup kernel: [69661.385801] [<c1231278>] device_unregister+0xb/0x15 Feb 21 14:26:29 jup kernel: [69661.385805] [<c129a209>] usb_remove_ep_devs+0x15/0x1f Feb 21 14:26:29 jup kernel: [69661.385809] [<c12943ff>] remove_intf_ep_devs+0x21/0x32 Feb 21 14:26:29 jup kernel: [69661.385813] [<c12954ea>] usb_set_interface+0x18c/0x22c Feb 21 14:26:29 jup kernel: [69661.385822] [<fc703cd7>] snd_usb_playback_close+0x20/0x33 [snd_usb_audio] Feb 21 14:26:29 jup kernel: [69661.385830] [<fb68bc10>] snd_pcm_release_substream+0x3d/0x66 [snd_pcm] Feb 21 14:26:29 jup kernel: [69661.385839] [<fb68bc95>] snd_pcm_release+0x5c/0x9e [snd_pcm] Feb 21 14:26:29 jup kernel: [69661.385843] [<c10aabe9>] __fput+0xeb/0x196 Feb 21 14:26:29 jup kernel: [69661.385847] [<c10aacad>] fput+0x19/0x1b Feb 21 14:26:29 jup kernel: [69661.385851] [<c109ae3b>] remove_vma+0x39/0x58 Feb 21 14:26:29 jup kernel: [69661.385854] [<c109bab3>] do_munmap+0x23c/0x259 Feb 21 14:26:29 jup kernel: [69661.385858] [<c109bb00>] sys_munmap+0x30/0x3f Feb 21 14:26:29 jup kernel: [69661.385862] [<c10028d0>] sysenter_do_call+0x12/0x36

2 2

[alsa-devel] ASoC updates for 2.6.34
by Mark Brown 25 Feb '10

25 Feb '10

The following changes since commit d62abe563fa4718e7f85f3e871655434db92366d: Misael Lopez Cruz (1): OMAP4: PMIC: Add support for twl6030 codec are available in the git repository at: git://opensource.wolfsonmicro.com/linux-2.6-asoc.git for-2.6.34 These wind up being a bug fix, without fixing the reporting of the periods a lot of hardware is going to get lots of clock domain issues. Mark Brown (2): ASoC: Remove a unused variables from i.MX FIQ runtime data ASoC: Check progress when reporting periods from i.MX FIQ handler sound/soc/imx/imx-pcm-fiq.c | 40 ++++++++++++++++++++++++++++++---------- 1 files changed, 30 insertions(+), 10 deletions(-)

2 3