From: Timur Tabi <timur@freescale.com>
To: ALSA development <alsa-devel@alsa-project.org>,
Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Something broke in snd_soc_pcm_stream
Date: Tue, 7 Jun 2011 16:31:52 -0500 [thread overview]
Message-ID: <4DEE98C8.2010706@freescale.com> (raw)
Mark,
I'm testing your for-3.1 branch on the P1022DS, and I'm getting a kernel panic
because a pointer is NULL where I don't expect it to be. In fsl_dma_new(), I
have this code:
if (dai->driver->capture.channels_min) {
ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, card->dev,
fsl_dma_hardware.buffer_bytes_max,
&pcm->streams[1].substream->dma_buffer);
if (ret) {
dev_err(card->dev, "can't alloc capture dma buffer\n");
snd_dma_free_pages(&pcm->streams[0].substream->dma_buffer);
return ret;
}
}
I test for channels_min because the playback stream is registered separately
from the capture stream, so I expect fsl_dma_new() to be called twice: once to
initialize playback, and again to initialize capture.
In the past, if dai->driver->capture.channels_min was equal to some non-zero
value, then pcm->streams[1].substream was also non-NULL. This appears no longer
to be true. Now it appears that playback.channels_min and capture.channels_min
are both set to 2 before fsl_dma_new() is called the first time.
I can change my code to do this:
if (pcm->streams[1].substream) {
ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, card->dev,
fsl_dma_hardware.buffer_bytes_max,
&pcm->streams[1].substream->dma_buffer);
if (ret) {
dev_err(card->dev, "can't alloc capture dma buffer\n");
snd_dma_free_pages(&pcm->streams[0].substream->dma_buffer);
return ret;
}
}
But before I do that, I'd like to know if this is a bug in ASoC, or just a new
behavior that I need to handle.
--
Timur Tabi
Linux kernel developer at Freescale
next reply other threads:[~2011-06-07 21:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-07 21:31 Timur Tabi [this message]
2011-06-07 21:44 ` Something broke in snd_soc_pcm_stream Mark Brown
2011-06-07 22:20 ` Timur Tabi
2011-06-08 9:05 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DEE98C8.2010706@freescale.com \
--to=timur@freescale.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.