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

Re: [alsa-devel] sound: BUG: unable to handle kernel irq event stamp: 2013419
by Takashi Iwai 15 Mar '12

15 Mar '12

At Thu, 15 Mar 2012 17:36:44 +0200, Sasha Levin wrote: > > On Thu, Mar 15, 2012 at 5:34 PM, Takashi Iwai <tiwai(a)suse.de> wrote: > > The bug seems coming from the old OSS driver. Do you enable any OSS > > drivers? > > They're most likely compiled in (kernel is pretty close to a 'make > allyesconfig'), but I haven't done anything in particular to start > them. What does trinity at all? Takashi

1 0

Re: [alsa-devel] sound: BUG: unable to handle kernel irq event stamp: 2013419
by Takashi Iwai 15 Mar '12

15 Mar '12

At Thu, 15 Mar 2012 17:25:06 +0200, Sasha Levin wrote: > > Hi all, > > I got the following kernel panic when running the trinity fuzzer in a > KVM tool guest, using today's linux-next. > > Please note that the guest doesn't have anything which even remotely > reminds a multimedia device of any sort, although most of the drivers > are compiled into the kernel. > > [ 145.747790] BUG: unable to handle kernel irq event stamp: 2013419 > [ 145.744076] hardirqs last enabled at (2013419): > [<ffffffff811582d8>] __call_rcu+0x128/0x2c0 > [ 145.744076] hardirqs last disabled at (2013418): > [<ffffffff81158247>] __call_rcu+0x97/0x2c0 > [ 145.744076] softirqs last enabled at (2013156): > [<ffffffff810b9a93>] __do_softirq+0x133/0x180 > [ 145.744076] softirqs last disabled at (2013139): > [<ffffffff8270c96c>] call_softirq+0x1c/0x30 > [ 145.748761] paging request at ffffc9000279e000 > [ 145.748761] IP: [<ffffffff821474cb>] midi_poll+0x6b/0x180 > [ 145.748761] PGD 3c9bc067 PUD 3c9bd067 PMD 36b5c067 PTE 0 > [ 145.748761] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 145.748761] CPU 0 > [ 145.748761] Pid: 3129, comm: trinity Tainted: G W > 3.3.0-rc7-next-20120315-sasha-00002-g91cfd71 #51 > [ 145.748761] RIP: 0010:[<ffffffff821474cb>] [<ffffffff821474cb>] > midi_poll+0x6b/0x180 > [ 145.784811] RSP: 0018:ffff88003d603dc0 EFLAGS: 00010086 > [ 145.784811] RAX: 0000000000000000 RBX: 0000000000000282 RCX: ffffc9000279e000 > [ 145.792008] RDX: ffff880034ad0000 RSI: 0000000000000000 RDI: 0000000000000001 > [ 145.792008] RBP: ffff88003d603df0 R08: 0000000000000001 R09: 0000000000000000 > [ 145.792008] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 > [ 145.792008] R13: 0000000010624dd3 R14: 0000000000000001 R15: 0000000000000000 > [ 145.792008] FS: 00007f2af88d0700(0000) GS:ffff88003d600000(0000) > knlGS:0000000000000000 > [ 145.792008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 145.792008] CR2: ffffc9000279e000 CR3: 0000000035195000 CR4: 00000000000406f0 > [ 145.792008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 145.792008] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 145.792008] Process trinity (pid: 3129, threadinfo > ffff880034aca000, task ffff880034ad0000) > [ 145.792008] Stack: > [ 145.792008] ffff880034ad0000 ffff880034acbfd8 ffff88003d603e10 > 0000000000000102 > [ 145.792008] ffffffff82147460 0000000000000000 ffff88003d603e70 > ffffffff810c0c2a > [ 145.792008] ffffffff810c0ba0 ffff88003d603ea0 ffffffff8300abec > ffffffff83d2e370 > [ 145.792008] Call Trace: > [ 145.792008] <IRQ> > [ 145.792008] [<ffffffff82147460>] ? midi_input_intr+0xb0/0xb0 > [ 145.792008] [<ffffffff810c0c2a>] call_timer_fn.clone.11+0x8a/0x110 > [ 145.792008] [<ffffffff810c0ba0>] ? process_timeout+0x10/0x10 > [ 145.792008] [<ffffffff82147460>] ? midi_input_intr+0xb0/0xb0 > [ 145.792008] [<ffffffff810c0efa>] run_timer_softirq+0x13a/0x220 > [ 145.792008] [<ffffffff810b9a28>] __do_softirq+0xc8/0x180 > [ 145.792008] [<ffffffff811fce9d>] ? dput+0x13d/0x1d0 > [ 145.792008] [<ffffffff8270c96c>] call_softirq+0x1c/0x30 > [ 145.792008] [<ffffffff8104fc05>] do_softirq+0xc5/0x100 > [ 145.792008] [<ffffffff810b9e9e>] irq_exit+0xae/0xe0 > [ 145.792008] [<ffffffff810719e8>] smp_apic_timer_interrupt+0x68/0xa0 > [ 145.792008] [<ffffffff8270bf6f>] apic_timer_interrupt+0x6f/0x80 > [ 145.792008] <EOI> > [ 145.792008] [<ffffffff8270a9f4>] ? retint_restore_args+0x13/0x13 > [ 145.792008] [<ffffffff81119528>] ? lock_release+0x98/0xc0 > [ 145.792008] [<ffffffff82709b6e>] _raw_spin_unlock+0x1e/0x60 > [ 145.792008] [<ffffffff811fce9d>] dput+0x13d/0x1d0 > [ 145.792008] [<ffffffff811f35e1>] do_last+0x461/0x790 > [ 145.792008] [<ffffffff811f39e7>] path_openat+0xd7/0x500 > [ 145.792008] [<ffffffff810ec458>] ? sched_clock_cpu+0xc8/0x140 > [ 145.792008] [<ffffffff811f3e54>] do_filp_open+0x44/0xa0 > [ 145.792008] [<ffffffff82709b80>] ? _raw_spin_unlock+0x30/0x60 > [ 145.792008] [<ffffffff81203a36>] ? alloc_fd+0x176/0x240 > [ 145.792008] [<ffffffff811e2c8d>] do_sys_open+0xfd/0x1d0 > [ 145.792008] [<ffffffff811e2d7c>] sys_open+0x1c/0x20 > [ 145.792008] [<ffffffff8270b2bd>] system_call_fastpath+0x1a/0x1f > [ 145.792008] Code: bd d3 4d 62 10 0f 1f 00 4d 63 f4 4a 83 3c f5 e0 > 32 90 84 00 0f 84 ad 00 00 00 4a 8b 0c f5 a0 5b 90 84 48 85 c9 0f 84 > 9c 00 00 00 <8b> 01 85 c0 0f 84 e3 00 00 00 8b 51 04 eb 3d 66 0f 1f 44 > 00 00 > [ 145.792008] RIP [<ffffffff821474cb>] midi_poll+0x6b/0x180 > [ 145.792008] RSP <ffff88003d603dc0> > [ 145.792008] CR2: ffffc9000279e000 > [ 145.792008] ---[ end trace 31f7a567e17c1567 ]--- > [ 145.792008] Kernel panic - not syncing: Fatal exception in interrupt > [ 145.792008] Rebooting in 1 seconds..\ The bug seems coming from the old OSS driver. Do you enable any OSS drivers? Takashi

1 0

[alsa-devel] [PATCH v4] ASoC: add imx-sgtl5000 machine driver working with fsl_ssi
by Shawn Guo 15 Mar '12

15 Mar '12

Changes since v3: * Change imx compatible to "fsl,imx21-ssi" * Leave locking issue as a FIXME for Timur to sort out separately --- Shawn Guo (10): ASoC: fsl: separate SSI and DMA Kconfig options ASoC: imx: merge sound/soc/imx into sound/soc/fsl ASoC: fsl: rename imx-pcm Kconfig options and filename ASoC: fsl: create fsl_utils to accommodate the common functions ASoC: fsl: remove helper fsl_asoc_get_codec_dev_name ASoC: fsl: check property 'compatible' for the machine name ASoC: fsl: make fsl_ssi driver compilable on ARM/IMX ASoC: fsl: remove the fatal error checking on codec-handle ASoC: fsl: let fsl_ssi work with imx pcm and machine drivers ASoC: fsl: add imx-sgtl5000 machine driver .../bindings/sound/imx-audio-sgtl5000.txt | 24 +++ arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig | 1 + arch/powerpc/configs/mpc85xx_defconfig | 1 + arch/powerpc/configs/mpc85xx_smp_defconfig | 1 + sound/soc/Kconfig | 1 - sound/soc/Makefile | 1 - sound/soc/fsl/Kconfig | 124 ++++++++++++- sound/soc/fsl/Makefile | 29 +++- sound/soc/{imx => fsl}/eukrea-tlv320.c | 2 +- sound/soc/fsl/fsl_ssi.c | 140 +++++++++++---- sound/soc/fsl/fsl_utils.c | 91 ++++++++++ sound/soc/fsl/fsl_utils.h | 26 +++ sound/soc/{imx => fsl}/imx-audmux.c | 0 sound/soc/{imx => fsl}/imx-audmux.h | 0 .../{imx/imx-pcm-dma-mx2.c => fsl/imx-pcm-dma.c} | 0 sound/soc/{imx => fsl}/imx-pcm-fiq.c | 0 sound/soc/{imx => fsl}/imx-pcm.c | 0 sound/soc/{imx => fsl}/imx-pcm.h | 0 sound/soc/fsl/imx-sgtl5000.c | 177 ++++++++++++++++++ sound/soc/{imx => fsl}/imx-ssi.c | 2 +- sound/soc/{imx => fsl}/imx-ssi.h | 0 sound/soc/fsl/mpc8610_hpcd.c | 168 ++---------------- sound/soc/{imx => fsl}/mx27vis-aic32x4.c | 0 sound/soc/fsl/p1022_ds.c | 190 ++------------------ sound/soc/{imx => fsl}/phycore-ac97.c | 0 sound/soc/{imx => fsl}/wm1133-ev1.c | 0 sound/soc/imx/Kconfig | 79 -------- sound/soc/imx/Makefile | 22 --- 28 files changed, 604 insertions(+), 475 deletions(-)

4 18

[alsa-devel] [PATCH 1/2] ASoC: core: Fix obscure leak of runtime array
by Mark Brown 15 Mar '12

15 Mar '12

We're currently not freeing card->rtd in cases where the card is unregistered before being registered - convert it to devm_kzalloc() to make sure that happens. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/soc-core.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 9a7ca0e..b0f8666 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1694,7 +1694,6 @@ static int soc_cleanup_card_resources(struct snd_soc_card *card) snd_soc_dapm_free(&card->dapm); - kfree(card->rtd); snd_card_free(card->snd_card); return 0; @@ -3120,9 +3119,10 @@ int snd_soc_register_card(struct snd_soc_card *card) soc_init_card_debugfs(card); - card->rtd = kzalloc(sizeof(struct snd_soc_pcm_runtime) * - (card->num_links + card->num_aux_devs), - GFP_KERNEL); + card->rtd = devm_kzalloc(card->dev, + sizeof(struct snd_soc_pcm_runtime) * + (card->num_links + card->num_aux_devs), + GFP_KERNEL); if (card->rtd == NULL) return -ENOMEM; card->rtd_aux = &card->rtd[card->num_links]; -- 1.7.9.1

2 2

[alsa-devel] [PATCH] ALSA: pcm: Constify the list in snd_pcm_hw_constraint_list
by Mark Brown 15 Mar '12

15 Mar '12

Allows the constraint lists to be declared const by drivers which seems reasonable; there's plenty of other constification we could do if we were being complete but this was easy and quick. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- include/sound/pcm.h | 5 +++-- sound/core/pcm_lib.c | 3 ++- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/include/sound/pcm.h b/include/sound/pcm.h index 1d58d79..0d11128 100644 --- a/include/sound/pcm.h +++ b/include/sound/pcm.h @@ -264,7 +264,7 @@ struct snd_pcm_hw_constraint_ratdens { struct snd_pcm_hw_constraint_list { unsigned int count; - unsigned int *list; + const unsigned int *list; unsigned int mask; }; @@ -785,7 +785,8 @@ void snd_interval_muldivk(const struct snd_interval *a, const struct snd_interva unsigned int k, struct snd_interval *c); void snd_interval_mulkdiv(const struct snd_interval *a, unsigned int k, const struct snd_interval *b, struct snd_interval *c); -int snd_interval_list(struct snd_interval *i, unsigned int count, unsigned int *list, unsigned int mask); +int snd_interval_list(struct snd_interval *i, unsigned int count, + const unsigned int *list, unsigned int mask); int snd_interval_ratnum(struct snd_interval *i, unsigned int rats_count, struct snd_ratnum *rats, unsigned int *nump, unsigned int *denp); diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index 3420bd3..4d18941 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -1029,7 +1029,8 @@ static int snd_interval_ratden(struct snd_interval *i, * * Returns non-zero if the value is changed, zero if not changed. */ -int snd_interval_list(struct snd_interval *i, unsigned int count, unsigned int *list, unsigned int mask) +int snd_interval_list(struct snd_interval *i, unsigned int count, + const unsigned int *list, unsigned int mask) { unsigned int k; struct snd_interval list_range; -- 1.7.9.1

2 1

[alsa-devel] ASoC updates for 3.4
by Mark Brown 15 Mar '12

15 Mar '12

The following changes since commit 303076342b8a30aa98f8a53b539155d0b81ff0c3: Merge tag 'asoc-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into topic/asoc (2012-03-06 14:04:16 +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 5ec65ee589fdaca7298b6303fd74ad6c121a8f38: ASoC: mx27vis-aic32x4: Convert it to platform driver (2012-03-13 23:09:59 +0000) ---------------------------------------------------------------- Linus decided to go for another week so here's a few more updates - a mixed bag here, a few minor diagnostic tweaks, some driver enhancements and the dmaengine conversion for ep93xx drivers which was tested a while ago and just waiting for a signoff. ---------------------------------------------------------------- Ashish Chavan (2): ASoC: da7210: Update for using I2C regmap ASoC: da7210: Remove extra registers from defaults list Fabio Estevam (2): ASoC: imx: imx-audmux: Fix section mismatch ASoC: mx27vis-aic32x4: Convert it to platform driver Lars-Peter Clausen (1): ASoC: ep93xx-pcm: Use dmaengine PCM helper functions Liam Girdwood (3): ASoC: dapm: Use dev_warn for debugfs warning message ASoC: core: Add platform component mutex ASoC: DAPM: Make sure DAPM widget IO ops hold the component mutex Mark Brown (5): ASoC: dapm: Only lock CODEC for I/O if not using regmap ASoC: wm8996: Remove some volatile regisers from the defaults table ASoC: wm8996: Remove separate output stage enable step ASoC: Revert widget I/O locking for 3.4 ASoC: wm8994: Prevent ABBA deadlock with CODEC and accdet mutexes Mika Westerberg (1): ASoC: dmaengine_pcm: Reset pointer position when starting a stream Qiao Zhou (1): ASoC: add more sample rate for pxa-ssp Shawn Guo (2): ASoC: core: missing set_fmt should not be complaint ASoC: fsl: check property 'compatible' for the machine name Stephen Warren (1): ASoC: tegra: Remove unused variable arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 1 + include/sound/soc.h | 1 + sound/soc/codecs/da7210.c | 146 +++++++++++++++++++------- sound/soc/codecs/wm8994.c | 69 ++++++------- sound/soc/codecs/wm8996.c | 34 ++---- sound/soc/ep93xx/Kconfig | 1 + sound/soc/ep93xx/ep93xx-pcm.c | 148 ++++----------------------- sound/soc/fsl/fsl_ssi.c | 6 +- sound/soc/fsl/mpc8610_hpcd.c | 2 +- sound/soc/fsl/p1022_ds.c | 32 +----- sound/soc/imx/imx-audmux.c | 8 +- sound/soc/imx/mx27vis-aic32x4.c | 41 ++++---- sound/soc/pxa/pxa-ssp.c | 3 +- sound/soc/soc-core.c | 12 ++- sound/soc/soc-dapm.c | 2 +- sound/soc/soc-dmaengine-pcm.c | 1 + sound/soc/tegra/tegra_alc5632.c | 1 - 17 files changed, 225 insertions(+), 283 deletions(-)

2 1

[alsa-devel] [RFC] ymfpci - re-enable legacy audio after suspend resume
by Raymond Yau 15 Mar '12

15 Mar '12

Since the Legacy Audio Control register is reset to default after suspend resume cycle need to enable the Legacy Audio Control Bit in order to use OPL3 FM Synth however it is still need to use sbiload instrument loader to reload the instruments

2 8

[alsa-devel] sending a sequencer event to a delayed queue
by Henning Thielemann 14 Mar '12

14 Mar '12

Unfortunately the ALSA doc does not say, what happens if I send an event to a queue that is not running. I expected that the event is being delivered once the queue is started. But it seems that instead the event is dropped. What is the reason for that behaviour? What I want to do is the following: I have a program that computes a sequence of events in real-time. Since computation of an event requires varying amount of time, I want to add a latency in order to get a correctly timed output. To this end I set up two queues: One queue triggers computation of events via Echo messages and the other queue delivers the computed events. I want to use the same time stamps for both queues and just start the queues with a delay between them. Why is it not possible to use one queue and add latency manually to the timestamps? Because the user of the program shall be able to halt the computation. Thus the computation must be halted first and the delivery of events must be halted later. I cannot achieve this with one queue and a queue_stop command. Now the problem is: When my program starts it computes the first event and sends it to the second (delayed) queue. But since this queue is started only after a delay, it is not yet running and thus my event is not delayed, but lost. :-( How to solve that problem? Is there a proposed way to manage latency in ALSA sequencing? Regards, Henning

3 12

[alsa-devel] [PATCH 1/2] ASoC: wm8996: Add 44.1kHz support
by Mark Brown 14 Mar '12

14 Mar '12

The WM8996 specification has been updated to specify 44.1kHz as a supported sample rate. Update the driver to accept this configuration. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8996.c | 19 ++++++++++--------- 1 files changed, 10 insertions(+), 9 deletions(-) diff --git a/sound/soc/codecs/wm8996.c b/sound/soc/codecs/wm8996.c index 40a124c..1fd6354 100644 --- a/sound/soc/codecs/wm8996.c +++ b/sound/soc/codecs/wm8996.c @@ -1914,7 +1914,7 @@ static int wm8996_hw_params(struct snd_pcm_substream *substream, { struct snd_soc_codec *codec = dai->codec; struct wm8996_priv *wm8996 = snd_soc_codec_get_drvdata(codec); - int bits, i, bclk_rate; + int bits, i, bclk_rate, best; int aifdata = 0; int lrclk = 0; int dsp = 0; @@ -1963,14 +1963,11 @@ static int wm8996_hw_params(struct snd_pcm_substream *substream, return bits; aifdata |= (bits << WM8996_AIF1TX_WL_SHIFT) | bits; + best = 0; for (i = 0; i < ARRAY_SIZE(dsp_divs); i++) { - if (dsp_divs[i] == params_rate(params)) - break; - } - if (i == ARRAY_SIZE(dsp_divs)) { - dev_err(codec->dev, "Unsupported sample rate %dHz\n", - params_rate(params)); - return -EINVAL; + if (abs(dsp_divs[i] - params_rate(params)) < + abs(dsp_divs[best] - params_rate(params))) + best = i; } dsp |= i << dsp_shift; @@ -2030,13 +2027,16 @@ static int wm8996_set_sysclk(struct snd_soc_dai *dai, } switch (wm8996->sysclk) { + case 5644800: case 6144000: snd_soc_update_bits(codec, WM8996_AIF_RATE, WM8996_SYSCLK_RATE, 0); break; + case 22579200: case 24576000: ratediv = WM8996_SYSCLK_DIV; wm8996->sysclk /= 2; + case 11289600: case 12288000: snd_soc_update_bits(codec, WM8996_AIF_RATE, WM8996_SYSCLK_RATE, WM8996_SYSCLK_RATE); @@ -3060,7 +3060,8 @@ static struct snd_soc_codec_driver soc_codec_dev_wm8996 = { }; #define WM8996_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_16000 |\ - SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_48000) + SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |\ + SNDRV_PCM_RATE_48000) #define WM8996_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE |\ SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S24_LE |\ SNDRV_PCM_FMTBIT_S32_LE) -- 1.7.9.1

1 1

[alsa-devel] snd_seq_parse_address matching prefix
by Henning Thielemann 14 Mar '12

14 Mar '12

snd_seq_parse_address(seq, addr, "foo") does not look for a client named "foo" but for a client with prefix "foo". I always found this to be a feature, not a bug, although it is not documented. Is this behavior intended? If yes, how to cope with the case where one client's name is the prefix of another one? E.g. let the clients be "foobar" "foo" (in this order) then parsing "foo" will return the client address of "foobar", not that of "foo". Even more there is no prefix that will select "foo", but not "foobar". Sorting the clients with respect to increasing name lengths and then searching for matching prefixes in the sorted list would solve that problem. Currently it's only a theoretical problem but if that behavior is intended it should at least be documented. Using snd_seq_query_next_client everyone can write his own parse_address. We should only know about the theoretical problem.

2 3