* [RFC] ARM: OMAP: Add support for OMAP2430 in McBSP
2008-08-21 11:55 [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx Jarkko Nikula
@ 2008-08-21 11:55 ` Jarkko Nikula
2008-08-21 11:55 ` [RFC] ASoC: OMAP: Add support for OMAP2430 and OMAP34xx in McBSP DAI driver Jarkko Nikula
` (3 subsequent siblings)
4 siblings, 0 replies; 40+ messages in thread
From: Jarkko Nikula @ 2008-08-21 11:55 UTC (permalink / raw)
To: linux-omap; +Cc: Jarkko Nikula
Signed-off-by: Jarkko Nikula <jarkko.nikula@nokia.com>
---
arch/arm/mach-omap2/mcbsp.c | 73 ++++++++++++++++++++++++++----
arch/arm/plat-omap/include/mach/mcbsp.h | 3 +
2 files changed, 66 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index cedb9a6..10aa3c6 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -145,8 +145,8 @@ static struct omap_mcbsp_ops omap2_mcbsp_ops = {
.request = omap2_mcbsp_request,
};
-#ifdef CONFIG_ARCH_OMAP24XX
-static struct omap_mcbsp_platform_data omap24xx_mcbsp_pdata[] = {
+#ifdef CONFIG_ARCH_OMAP2420
+static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[] = {
{
.virt_base = OMAP2_IO_ADDRESS(OMAP24XX_MCBSP1_BASE),
.dma_rx_sync = OMAP24XX_DMA_MCBSP1_RX,
@@ -166,10 +166,58 @@ static struct omap_mcbsp_platform_data omap24xx_mcbsp_pdata[] = {
.clk_name = "mcbsp_clk",
},
};
-#define OMAP24XX_MCBSP_PDATA_SZ ARRAY_SIZE(omap24xx_mcbsp_pdata)
+#define OMAP2420_MCBSP_PDATA_SZ ARRAY_SIZE(omap2420_mcbsp_pdata)
#else
-#define omap24xx_mcbsp_pdata NULL
-#define OMAP24XX_MCBSP_PDATA_SZ 0
+#define omap2420_mcbsp_pdata NULL
+#define OMAP2420_MCBSP_PDATA_SZ 0
+#endif
+
+#ifdef CONFIG_ARCH_OMAP2430
+static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[] = {
+ {
+ .virt_base = OMAP2_IO_ADDRESS(OMAP24XX_MCBSP1_BASE),
+ .dma_rx_sync = OMAP24XX_DMA_MCBSP1_RX,
+ .dma_tx_sync = OMAP24XX_DMA_MCBSP1_TX,
+ .rx_irq = INT_24XX_MCBSP1_IRQ_RX,
+ .tx_irq = INT_24XX_MCBSP1_IRQ_TX,
+ .ops = &omap2_mcbsp_ops,
+ .clk_name = "mcbsp_clk",
+ },
+ {
+ .virt_base = OMAP2_IO_ADDRESS(OMAP24XX_MCBSP2_BASE),
+ .dma_rx_sync = OMAP24XX_DMA_MCBSP2_RX,
+ .dma_tx_sync = OMAP24XX_DMA_MCBSP2_TX,
+ .rx_irq = INT_24XX_MCBSP2_IRQ_RX,
+ .tx_irq = INT_24XX_MCBSP2_IRQ_TX,
+ .ops = &omap2_mcbsp_ops,
+ .clk_name = "mcbsp_clk",
+ },
+ {
+ .virt_base = OMAP2_IO_ADDRESS(OMAP2430_MCBSP3_BASE),
+ .dma_rx_sync = OMAP24XX_DMA_MCBSP3_RX,
+ .dma_tx_sync = OMAP24XX_DMA_MCBSP3_TX,
+ .ops = &omap2_mcbsp_ops,
+ .clk_name = "mcbsp_clk",
+ },
+ {
+ .virt_base = OMAP2_IO_ADDRESS(OMAP2430_MCBSP4_BASE),
+ .dma_rx_sync = OMAP24XX_DMA_MCBSP4_RX,
+ .dma_tx_sync = OMAP24XX_DMA_MCBSP4_TX,
+ .ops = &omap2_mcbsp_ops,
+ .clk_name = "mcbsp_clk",
+ },
+ {
+ .virt_base = OMAP2_IO_ADDRESS(OMAP2430_MCBSP5_BASE),
+ .dma_rx_sync = OMAP24XX_DMA_MCBSP5_RX,
+ .dma_tx_sync = OMAP24XX_DMA_MCBSP5_TX,
+ .ops = &omap2_mcbsp_ops,
+ .clk_name = "mcbsp_clk",
+ },
+};
+#define OMAP2430_MCBSP_PDATA_SZ ARRAY_SIZE(omap2430_mcbsp_pdata)
+#else
+#define omap2430_mcbsp_pdata NULL
+#define OMAP2430_MCBSP_PDATA_SZ 0
#endif
#ifdef CONFIG_ARCH_OMAP34XX
@@ -230,8 +278,10 @@ static int __init omap2_mcbsp_init(void)
clk_register(&omap_mcbsp_clks[i].clk);
}
- if (cpu_is_omap24xx())
- omap_mcbsp_count = OMAP24XX_MCBSP_PDATA_SZ;
+ if (cpu_is_omap2420())
+ omap_mcbsp_count = OMAP2420_MCBSP_PDATA_SZ;
+ if (cpu_is_omap2430())
+ omap_mcbsp_count = OMAP2430_MCBSP_PDATA_SZ;
if (cpu_is_omap34xx())
omap_mcbsp_count = OMAP34XX_MCBSP_PDATA_SZ;
@@ -240,9 +290,12 @@ static int __init omap2_mcbsp_init(void)
if (!mcbsp_ptr)
return -ENOMEM;
- if (cpu_is_omap24xx())
- omap_mcbsp_register_board_cfg(omap24xx_mcbsp_pdata,
- OMAP24XX_MCBSP_PDATA_SZ);
+ if (cpu_is_omap2420())
+ omap_mcbsp_register_board_cfg(omap2420_mcbsp_pdata,
+ OMAP2420_MCBSP_PDATA_SZ);
+ if (cpu_is_omap2430())
+ omap_mcbsp_register_board_cfg(omap2430_mcbsp_pdata,
+ OMAP2430_MCBSP_PDATA_SZ);
if (cpu_is_omap34xx())
omap_mcbsp_register_board_cfg(omap34xx_mcbsp_pdata,
OMAP34XX_MCBSP_PDATA_SZ);
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h
index c04bcd5..1df761f 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -43,6 +43,9 @@
#define OMAP24XX_MCBSP1_BASE 0x48074000
#define OMAP24XX_MCBSP2_BASE 0x48076000
+#define OMAP2430_MCBSP3_BASE 0x4808c000
+#define OMAP2430_MCBSP4_BASE 0x4808e000
+#define OMAP2430_MCBSP5_BASE 0x48096000
#define OMAP34XX_MCBSP1_BASE 0x48074000
#define OMAP34XX_MCBSP2_BASE 0x49022000
--
1.5.6.3
^ permalink raw reply related [flat|nested] 40+ messages in thread* [RFC] ASoC: OMAP: Add support for OMAP2430 and OMAP34xx in McBSP DAI driver
2008-08-21 11:55 [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx Jarkko Nikula
2008-08-21 11:55 ` [RFC] ARM: OMAP: Add support for OMAP2430 in McBSP Jarkko Nikula
@ 2008-08-21 11:55 ` Jarkko Nikula
2008-08-21 21:51 ` [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx Steve Sakoman
` (2 subsequent siblings)
4 siblings, 0 replies; 40+ messages in thread
From: Jarkko Nikula @ 2008-08-21 11:55 UTC (permalink / raw)
To: linux-omap; +Cc: Jarkko Nikula
Signed-off-by: Jarkko Nikula <jarkko.nikula@nokia.com>
---
sound/soc/omap/omap-mcbsp.c | 95 ++++++++++++++++++++++++++++++++++--------
1 files changed, 77 insertions(+), 18 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 35310e1..a217cf2 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -84,11 +84,22 @@ static const unsigned long omap1_mcbsp_port[][2] = {
static const int omap1_dma_reqs[][2] = {};
static const unsigned long omap1_mcbsp_port[][2] = {};
#endif
-#if defined(CONFIG_ARCH_OMAP2420)
-static const int omap2420_dma_reqs[][2] = {
+
+#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
+static const int omap24xx_dma_reqs[][2] = {
{ OMAP24XX_DMA_MCBSP1_TX, OMAP24XX_DMA_MCBSP1_RX },
{ OMAP24XX_DMA_MCBSP2_TX, OMAP24XX_DMA_MCBSP2_RX },
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
+ { OMAP24XX_DMA_MCBSP3_TX, OMAP24XX_DMA_MCBSP3_RX },
+ { OMAP24XX_DMA_MCBSP4_TX, OMAP24XX_DMA_MCBSP4_RX },
+ { OMAP24XX_DMA_MCBSP5_TX, OMAP24XX_DMA_MCBSP5_RX },
+#endif
};
+#else
+static const int omap2420_dma_reqs[][2] = {};
+#endif
+
+#if defined(CONFIG_ARCH_OMAP2420)
static const unsigned long omap2420_mcbsp_port[][2] = {
{ OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR1,
OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR1 },
@@ -96,10 +107,43 @@ static const unsigned long omap2420_mcbsp_port[][2] = {
OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR1 },
};
#else
-static const int omap2420_dma_reqs[][2] = {};
static const unsigned long omap2420_mcbsp_port[][2] = {};
#endif
+#if defined(CONFIG_ARCH_OMAP2430)
+static const unsigned long omap2430_mcbsp_port[][2] = {
+ { OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP2430_MCBSP3_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP2430_MCBSP3_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP2430_MCBSP4_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP2430_MCBSP4_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP2430_MCBSP5_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP2430_MCBSP5_BASE + OMAP_MCBSP_REG_DRR },
+};
+#else
+static const unsigned long omap2430_mcbsp_port[][2] = {};
+#endif
+
+#if defined(CONFIG_ARCH_OMAP34XX)
+static const unsigned long omap34xx_mcbsp_port[][2] = {
+ { OMAP34XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP34XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP34XX_MCBSP3_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP3_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP34XX_MCBSP4_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP4_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP34XX_MCBSP5_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP5_BASE + OMAP_MCBSP_REG_DRR },
+};
+#else
+static const unsigned long omap34xx_mcbsp_port[][2] = {};
+#endif
+
static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream)
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
@@ -167,12 +211,15 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream,
dma = omap1_dma_reqs[bus_id][substream->stream];
port = omap1_mcbsp_port[bus_id][substream->stream];
} else if (cpu_is_omap2420()) {
- dma = omap2420_dma_reqs[bus_id][substream->stream];
+ dma = omap24xx_dma_reqs[bus_id][substream->stream];
port = omap2420_mcbsp_port[bus_id][substream->stream];
+ } else if (cpu_is_omap2430()) {
+ dma = omap24xx_dma_reqs[bus_id][substream->stream];
+ port = omap2430_mcbsp_port[bus_id][substream->stream];
+ } else if (cpu_is_omap343x()) {
+ dma = omap24xx_dma_reqs[bus_id][substream->stream];
+ port = omap34xx_mcbsp_port[bus_id][substream->stream];
} else {
- /*
- * TODO: Add support for 2430 and 3430
- */
return -ENODEV;
}
omap_mcbsp_dai_dma_params[id][substream->stream].dma_req = dma;
@@ -310,7 +357,7 @@ static int omap_mcbsp_dai_set_clks_src(struct omap_mcbsp_data *mcbsp_data,
int clk_id)
{
int sel_bit;
- u16 reg;
+ u16 reg, reg_devconf1 = OMAP243X_CONTROL_DEVCONF1;
if (cpu_class_is_omap1()) {
/* OMAP1's can use only external source clock */
@@ -320,6 +367,12 @@ static int omap_mcbsp_dai_set_clks_src(struct omap_mcbsp_data *mcbsp_data,
return 0;
}
+ if (cpu_is_omap2420() && mcbsp_data->bus_id > 1)
+ return -EINVAL;
+
+ if (cpu_is_omap343x())
+ reg_devconf1 = OMAP343X_CONTROL_DEVCONF1;
+
switch (mcbsp_data->bus_id) {
case 0:
reg = OMAP2_CONTROL_DEVCONF0;
@@ -329,20 +382,26 @@ static int omap_mcbsp_dai_set_clks_src(struct omap_mcbsp_data *mcbsp_data,
reg = OMAP2_CONTROL_DEVCONF0;
sel_bit = 6;
break;
- /* TODO: Support for ports 3 - 5 in OMAP2430 and OMAP34xx */
+ case 2:
+ reg = reg_devconf1;
+ sel_bit = 0;
+ break;
+ case 3:
+ reg = reg_devconf1;
+ sel_bit = 2;
+ break;
+ case 4:
+ reg = reg_devconf1;
+ sel_bit = 4;
+ break;
default:
return -EINVAL;
}
- if (cpu_class_is_omap2()) {
- if (clk_id == OMAP_MCBSP_SYSCLK_CLKS_FCLK) {
- omap_ctrl_writel(omap_ctrl_readl(reg) &
- ~(1 << sel_bit), reg);
- } else {
- omap_ctrl_writel(omap_ctrl_readl(reg) |
- (1 << sel_bit), reg);
- }
- }
+ if (clk_id == OMAP_MCBSP_SYSCLK_CLKS_FCLK)
+ omap_ctrl_writel(omap_ctrl_readl(reg) & ~(1 << sel_bit), reg);
+ else
+ omap_ctrl_writel(omap_ctrl_readl(reg) | (1 << sel_bit), reg);
return 0;
}
--
1.5.6.3
^ permalink raw reply related [flat|nested] 40+ messages in thread* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-21 11:55 [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx Jarkko Nikula
2008-08-21 11:55 ` [RFC] ARM: OMAP: Add support for OMAP2430 in McBSP Jarkko Nikula
2008-08-21 11:55 ` [RFC] ASoC: OMAP: Add support for OMAP2430 and OMAP34xx in McBSP DAI driver Jarkko Nikula
@ 2008-08-21 21:51 ` Steve Sakoman
2008-08-22 7:57 ` Jarkko Nikula
2008-08-23 11:32 ` Arun KS
2008-09-05 1:12 ` Tony Lindgren
4 siblings, 1 reply; 40+ messages in thread
From: Steve Sakoman @ 2008-08-21 21:51 UTC (permalink / raw)
To: Jarkko Nikula, linux-omap@vger.kernel.org
I tried these patches with my ASoC driver for TWL4030/Overo (the
Gumstix 35XX based board) and they appear to work for that
combination. When I get a chance I will try them with Beagle and EVM,
but I expect that should go well too.
I will submit the TWL4030 + Beagle, EVM, and Overo ASoC driver patches
as soon as I can track down a recurring crashing bug -- a null
substream pointer that seems to show up in certain circumstances. Not
quite sure my driver is causing the error, but I would like to get to
the bottom of it. It may be a compatibility issue with the version of
alsa lib I am using with the linux-omap kernel since the lib is
passing in the null pointer. Have you seen anything like this on the
N810?
Regards,
Steve
On Thu, Aug 21, 2008 at 4:55 AM, Jarkko Nikula <jarkko.nikula@nokia.com> wrote:
> Here are two patches adding support for OMAP2430 in McBSP driver and
> adding support for 2430 and 34xx in ASoC OMAP McBSP DAI driver.
>
> These are generated from top of currect l-o head but they apply also on
> top of Hiroshi's virtual clock patches with some offsets.
>
> If you have change to try them out on those CPUs, I would be happy to
> hear. I've tested these only on N810. Second patch will naturally go
> through the alsa-devel when we have necessary McBSP patches upstream.
>
> --
> Jarkko
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-21 21:51 ` [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx Steve Sakoman
@ 2008-08-22 7:57 ` Jarkko Nikula
2008-08-25 19:19 ` Steve Sakoman
0 siblings, 1 reply; 40+ messages in thread
From: Jarkko Nikula @ 2008-08-22 7:57 UTC (permalink / raw)
To: ext Steve Sakoman; +Cc: linux-omap@vger.kernel.org
On Thu, 21 Aug 2008 14:51:04 -0700
"ext Steve Sakoman" <sakoman@gmail.com> wrote:
> I will submit the TWL4030 + Beagle, EVM, and Overo ASoC driver patches
> as soon as I can track down a recurring crashing bug -- a null
> substream pointer that seems to show up in certain circumstances. Not
> quite sure my driver is causing the error, but I would like to get to
> the bottom of it. It may be a compatibility issue with the version of
> alsa lib I am using with the linux-omap kernel since the lib is
> passing in the null pointer. Have you seen anything like this on the
> N810?
>
Thus far I've seen only these two fixed
66c23551b1b774e2be3c7bdf91c0ebf2c7a3519e and
55502f74b56f609a84d8919b9b29390b2e0147ff OMAP DMA related dump_stacks
but probably I haven't stressed enough :-)
For testing I use Debian/testing and alsa-utils and various
players like mpg321, madplay, etc from there.
ii libasound2 1.0.16-2 ALSA library
cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.17.
Can you share the error log and steps when this typically occurs in
order to see can I reproduce it?
Jarkko
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-22 7:57 ` Jarkko Nikula
@ 2008-08-25 19:19 ` Steve Sakoman
2008-08-25 19:29 ` Felipe Balbi
` (2 more replies)
0 siblings, 3 replies; 40+ messages in thread
From: Steve Sakoman @ 2008-08-25 19:19 UTC (permalink / raw)
To: Jarkko Nikula, linux-omap@vger.kernel.org
> For testing I use Debian/testing and alsa-utils and various
> players like mpg321, madplay, etc from there.
I've been using mplayer, madplay, aplay, arecord, speakertest . . .
I'm using a rootfs built with OpenEmbedded, the alsa lib version is 1.0.17
root@overo:~# cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.17.
> Can you share the error log and steps when this typically occurs in
> order to see can I reproduce it?
Certainly!
First a few basics -- I can run commands like:
mplayer song.mp3
madplay song.mp3
aplay rawsong
with no problems.
If I run 'mplayer -ao alsa song.mp3' immediately after booting I get a
crash due to a null substream pointer (output below).
However if I run 'mplayer song.mp3' *before* 'mplayer -ao alsa
song.mp3' then the latter command works!
Here's the crash output (alsa debugging is enabled in the kernel):
overo login: root
login[1632]: root login on `ttyS2'
root@overo:~# mplayer -ao alsa /Watermelon_Slim-Black_Water.mp3
MPlayer 1.0rc2-4.3.1 (C) 2000-2007 MPlayer Team
CPU: ARM
Playing /Watermelon_Slim-Black_Water.mp3.
Audio file file format detected.
Clip info:
Title: Black Water
Artist: Watermelon Slim
Album: http://music.download.com
Year: 2007
Comment: http://music.download.com/
Track: 1
Genre: Unknown
==========================================================================
Forced audio codec: mad
Opening audio decoder: [libmad] libmad mpeg audio decoder
AUDIO: 44100 Hz, 2 ch, s16le, 192.0 kbit/13.61% (ratio: 24000->176400)
Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3)
==========================================================================
ALSA sound/core/pcm_native.c:2573: BUG? (substream != ((void *)0))
[<c00309c8>] (dump_stack+0x0/0x14) from [<c0259ba0>]
(snd_pcm_playback_ioctl1+0x34/0x474)
[<c0259b6c>] (snd_pcm_playback_ioctl1+0x0/0x474) from [<c025a0d8>]
(snd_pcm_playback_ioctl+0x34/0x38)
r7:c71bc000 r6:00000005 r5:bea41624 r4:80044100
[<c025a0a4>] (snd_pcm_playback_ioctl+0x0/0x38) from [<c00a5bb8>]
(vfs_ioctl+0x34/0x78)
[<c00a5b84>] (vfs_ioctl+0x0/0x78) from [<c00a5e6c>] (do_vfs_ioctl+0x270/0x280)
r5:bea41624 r4:c71bc000
[<c00a5bfc>] (do_vfs_ioctl+0x0/0x280) from [<c00a5ebc>] (sys_ioctl+0x40/0x64)
r7:c71bc000 r6:80044100 r5:bea41624 r4:00000005
[<c00a5e7c>] (sys_ioctl+0x0/0x64) from [<c002cc80>] (ret_fast_syscall+0x0/0x2c)
r7:00000036 r6:00000400 r5:4001e1cc r4:bea41624
ALSA sound/core/pcm_native.c:2573: BUG? (substream != ((void *)0))
[<c00309c8>] (dump_stack+0x0/0x14) from [<c0259ba0>]
(snd_pcm_playback_ioctl1+0x34/0x474)
[<c0259b6c>] (snd_pcm_playback_ioctl1+0x0/0x474) from [<c025a0d8>]
(snd_pcm_playback_ioctl+0x34/0x38)
r7:c71bc000 r6:00000005 r5:bea41480 r4:81204101
[<c025a0a4>] (snd_pcm_playback_ioctl+0x0/0x38) from [<c00a5bb8>]
(vfs_ioctl+0x34/0x78)
[<c00a5b84>] (vfs_ioctl+0x0/0x78) from [<c00a5e6c>] (do_vfs_ioctl+0x270/0x280)
r5:bea41480 r4:c71bc000
[<c00a5bfc>] (do_vfs_ioctl+0x0/0x280) from [<c00a5ebc>] (sys_ioctl+0x40/0x64)
r7:c71bc000 r6:81204101 r5:bea41480 r4:00000005
[<c00a5e7c>] (sys_ioctl+0x0/0x64) from [<c002cc80>] (ret_fast_syscall+0x0/0x2c)
r7:00000036 r6:402c0444 r5:007ee3b0 r4:402c0444
[AO_ALSA] alsa-lib: pcm_hw.c:261:(snd_pcm_hw_info)
SNDRV_PCM_IOCTL_INFO failed: No such device or address
[AO_ALSA] alsa-lib:
pcm_direct.c:1100:(snd1_pcm_direct_initialize_poll_fd) unable to info
for slave pcm
[AO_ALSA] alsa-lib: pcm_dmix.c:1085:(snd_pcm_dmix_open) unable to
initialize poll_fd
[AO_ALSA] Playback open error: No such device or address
Could not open/initialize audio device -> no sound.
Audio: no sound
Video: no video
Exiting... (End of file)
root@overo:~# ALSA sound/core/pcm_native.c:2180: BUG? (substream != ((void *)0))
[<c00309c8>] (dump_stack+0x0/0x14) from [<c025694c>] (snd_pcm_release+0x38/0xbc)
[<c0256914>] (snd_pcm_release+0x0/0xbc) from [<c009af68>] (__fput+0xb8/0x170)
r9:c7164000 r8:c74dd980 r7:c70c7634 r6:c71bc000 r5:c79faab0
r4:00000008
[<c009aeb0>] (__fput+0x0/0x170) from [<c009b2dc>] (fput+0x30/0x34)
[<c009b2ac>] (fput+0x0/0x34) from [<c008746c>] (remove_vma+0x40/0x70)
[<c008742c>] (remove_vma+0x0/0x70) from [<c0087568>] (exit_mmap+0xcc/0xf8)
r5:c70c7600 r4:c7167898
[<c008749c>] (exit_mmap+0x0/0xf8) from [<c004a624>] (mmput+0x3c/0xc4)
r6:c791a100 r5:00000000 r4:c70c7600
[<c004a5e8>] (mmput+0x0/0xc4) from [<c004dc8c>] (exit_mm+0x110/0x118)
r5:c70c7600 r4:00000000
[<c004db7c>] (exit_mm+0x0/0x118) from [<c004f0f0>] (do_exit+0x1f0/0x6e8)
r7:000000f8 r6:00000000 r5:c791a100 r4:c7164000
[<c004ef00>] (do_exit+0x0/0x6e8) from [<c004f664>] (do_group_exit+0x7c/0xac)
[<c004f5e8>] (do_group_exit+0x0/0xac) from [<c004f6ac>]
(sys_exit_group+0x18/0x1c)
r5:0008c978 r4:0008c99c
[<c004f694>] (sys_exit_group+0x0/0x1c) from [<c002cc80>]
(ret_fast_syscall+0x0/0x2c)
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-25 19:19 ` Steve Sakoman
@ 2008-08-25 19:29 ` Felipe Balbi
2008-08-25 21:35 ` Felipe Balbi
2008-08-26 13:19 ` Jarkko Nikula
2 siblings, 0 replies; 40+ messages in thread
From: Felipe Balbi @ 2008-08-25 19:29 UTC (permalink / raw)
To: Steve Sakoman; +Cc: Jarkko Nikula, linux-omap@vger.kernel.org
On Mon, Aug 25, 2008 at 12:19:16PM -0700, Steve Sakoman wrote:
> Here's the crash output (alsa debugging is enabled in the kernel):
Can you apply the following patch just to make it easier to pinpoint
from where the BUG is coming from ?
diff --git a/include/sound/core.h b/include/sound/core.h
index 558b962..d2edf98 100644
--- a/include/sound/core.h
+++ b/include/sound/core.h
@@ -400,7 +400,7 @@ void snd_verbose_printd(const char *file, int line, const char *format, ...)
} while (0)
#define snd_BUG() do { \
- snd_printk(KERN_ERR "BUG?\n"); \
+ snd_printk(KERN_ERR "%s %d: BUG?\n", __func__, __LINE__); \
dump_stack(); \
} while (0)
--
balbi
^ permalink raw reply related [flat|nested] 40+ messages in thread* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-25 19:19 ` Steve Sakoman
2008-08-25 19:29 ` Felipe Balbi
@ 2008-08-25 21:35 ` Felipe Balbi
2008-08-25 21:39 ` Felipe Balbi
2008-08-25 21:50 ` Steve Sakoman
2008-08-26 13:19 ` Jarkko Nikula
2 siblings, 2 replies; 40+ messages in thread
From: Felipe Balbi @ 2008-08-25 21:35 UTC (permalink / raw)
To: Steve Sakoman; +Cc: Jarkko Nikula, linux-omap@vger.kernel.org
On Mon, Aug 25, 2008 at 12:19:16PM -0700, Steve Sakoman wrote:
> ALSA sound/core/pcm_native.c:2573: BUG? (substream != ((void *)0))
Hmmm... this looks odd.
Jarkko, shouldn't that snd_assert() in pcm_native.c check if substream
_is_ NULL instead of !is NULL ?
I mean:
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index c49b9d9..db86090 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -2570,7 +2570,7 @@ static int snd_pcm_playback_ioctl1(struct file *file,
struct snd_pcm_substream *substream,
unsigned int cmd, void __user *arg)
{
- snd_assert(substream != NULL, return -ENXIO);
+ snd_assert(substream == NULL, return -ENXIO);
snd_assert(substream->stream == SNDRV_PCM_STREAM_PLAYBACK, return -EINVAL);
switch (cmd) {
case SNDRV_PCM_IOCTL_WRITEI_FRAMES:
If you follow up the function calls, we can see that substream is
initialized in pcm_native.c:snd_pcm_open_file():
2080 err = snd_pcm_open_substream(pcm, stream, file, &substream);
2081 if (err < 0)
2082 return err;
and that initialized pointer is added to pcm_file in the same function
a few lines later:
2089 pcm_file->substream = substream;
Am I misreading something ? :-s
--
balbi
^ permalink raw reply related [flat|nested] 40+ messages in thread* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-25 21:35 ` Felipe Balbi
@ 2008-08-25 21:39 ` Felipe Balbi
2008-08-25 21:50 ` Steve Sakoman
1 sibling, 0 replies; 40+ messages in thread
From: Felipe Balbi @ 2008-08-25 21:39 UTC (permalink / raw)
To: Felipe Balbi; +Cc: Steve Sakoman, Jarkko Nikula, linux-omap@vger.kernel.org
On Tue, Aug 26, 2008 at 12:35:13AM +0300, Felipe Balbi wrote:
> On Mon, Aug 25, 2008 at 12:19:16PM -0700, Steve Sakoman wrote:
> > ALSA sound/core/pcm_native.c:2573: BUG? (substream != ((void *)0))
>
> Hmmm... this looks odd.
>
> Jarkko, shouldn't that snd_assert() in pcm_native.c check if substream
> _is_ NULL instead of !is NULL ?
>
> I mean:
>
> diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
> index c49b9d9..db86090 100644
> --- a/sound/core/pcm_native.c
> +++ b/sound/core/pcm_native.c
> @@ -2570,7 +2570,7 @@ static int snd_pcm_playback_ioctl1(struct file *file,
> struct snd_pcm_substream *substream,
> unsigned int cmd, void __user *arg)
> {
> - snd_assert(substream != NULL, return -ENXIO);
> + snd_assert(substream == NULL, return -ENXIO);
> snd_assert(substream->stream == SNDRV_PCM_STREAM_PLAYBACK, return -EINVAL);
> switch (cmd) {
> case SNDRV_PCM_IOCTL_WRITEI_FRAMES:
>
> If you follow up the function calls, we can see that substream is
> initialized in pcm_native.c:snd_pcm_open_file():
>
> 2080 err = snd_pcm_open_substream(pcm, stream, file, &substream);
> 2081 if (err < 0)
> 2082 return err;
>
> and that initialized pointer is added to pcm_file in the same function
> a few lines later:
>
> 2089 pcm_file->substream = substream;
>
> Am I misreading something ? :-s
btw, the for loop in pcm.c:snd_pcm_attach_substream looks weird.
Couldn't it be changed to use list_for_each_entry() or any of its friends ?
797 for (substream = pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream; substream; substream = substr eam->next) {
--
balbi
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-25 21:35 ` Felipe Balbi
2008-08-25 21:39 ` Felipe Balbi
@ 2008-08-25 21:50 ` Steve Sakoman
2008-08-25 21:53 ` Felipe Balbi
1 sibling, 1 reply; 40+ messages in thread
From: Steve Sakoman @ 2008-08-25 21:50 UTC (permalink / raw)
To: me; +Cc: Jarkko Nikula, linux-omap@vger.kernel.org
>> ALSA sound/core/pcm_native.c:2573: BUG? (substream != ((void *)0))
>
> Hmmm... this looks odd.
>
> Jarkko, shouldn't that snd_assert() in pcm_native.c check if substream
> _is_ NULL instead of !is NULL ?
I found this odd also, but looking in
Documentation/sound/alsa/DocBook/writing-an-alsa-driver I found that
the sense of the test is indeed the reverse of what you would expect
-- you are specifying the condition that *should* be met, and the
action to take if it is not.
I can also verify that the substream pointer is indeed null -- the
reason I enabled alsa debugging in the first place is that the kernel
was crashing due to a null pointer :-)
Steve
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-25 21:50 ` Steve Sakoman
@ 2008-08-25 21:53 ` Felipe Balbi
2008-08-25 22:13 ` Steve Sakoman
2008-08-25 22:30 ` Steve Sakoman
0 siblings, 2 replies; 40+ messages in thread
From: Felipe Balbi @ 2008-08-25 21:53 UTC (permalink / raw)
To: Steve Sakoman; +Cc: me, Jarkko Nikula, linux-omap@vger.kernel.org
On Mon, Aug 25, 2008 at 02:50:04PM -0700, Steve Sakoman wrote:
> >> ALSA sound/core/pcm_native.c:2573: BUG? (substream != ((void *)0))
> >
> > Hmmm... this looks odd.
> >
> > Jarkko, shouldn't that snd_assert() in pcm_native.c check if substream
> > _is_ NULL instead of !is NULL ?
>
> I found this odd also, but looking in
> Documentation/sound/alsa/DocBook/writing-an-alsa-driver I found that
> the sense of the test is indeed the reverse of what you would expect
> -- you are specifying the condition that *should* be met, and the
> action to take if it is not.
>
> I can also verify that the substream pointer is indeed null -- the
> reason I enabled alsa debugging in the first place is that the kernel
> was crashing due to a null pointer :-)
Hmm, so the crash is actually somewhere else. Could you disable debug
and get the NULL pointer dereference at the right point ?
I think it'll be easier to track down, maybe.
--
balbi
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-25 21:53 ` Felipe Balbi
@ 2008-08-25 22:13 ` Steve Sakoman
2008-08-25 22:30 ` Steve Sakoman
1 sibling, 0 replies; 40+ messages in thread
From: Steve Sakoman @ 2008-08-25 22:13 UTC (permalink / raw)
To: me, Jarkko Nikula, linux-omap@vger.kernel.org
> Hmm, so the crash is actually somewhere else.
Yes, the assert is the first point at which you can detect that things
are going to go badly :-) The actual crash happens two or three
function calls deeper when the first substream pointer dereference
occurs.
> Could you disable debug
> and get the NULL pointer dereference at the right point ?
Will do, compiling right now.
> I think it'll be easier to track down, maybe.
Maybe -- but the root cause of the crash is the null substream pointer
which was set way up the call chain.
I'll attach the new crash log in a few minutes when the build completes.
Steve
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-25 21:53 ` Felipe Balbi
2008-08-25 22:13 ` Steve Sakoman
@ 2008-08-25 22:30 ` Steve Sakoman
2008-08-25 22:40 ` Felipe Balbi
1 sibling, 1 reply; 40+ messages in thread
From: Steve Sakoman @ 2008-08-25 22:30 UTC (permalink / raw)
To: me; +Cc: Jarkko Nikula, linux-omap@vger.kernel.org
> Hmm, so the crash is actually somewhere else. Could you disable debug
> and get the NULL pointer dereference at the right point ?
The output is below. The crash seems to occur at the substream
pointer dereference in the second line of snd_pcm_info (in
pcm_native.c):
struct snd_pcm *pcm = substream->pcm;
The log:
root@overo:~# mplayer -ao alsa /Watermelon_Slim-Black_Water.mp3
MPlayer 1.0rc2-4.3.1 (C) 2000-2007 MPlayer Team
CPU: ARM
Playing /Watermelon_Slim-Black_Water.mp3.
Audio file file format detected.
Clip info:
Title: Black Water
Artist: Watermelon Slim
Album: http://music.download.com
Year: 2007
Comment: http://music.download.com/
Track: 1
Genre: Unknown
==========================================================================
Forced audio codec: mad
Opening audio decoder: [libmad] libmad mpeg audio decoder
AUDIO: 44100 Hz, 2 ch, s16le, 192.0 kbit/13.61% (ratio: 24000->176400)
Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3)
==========================================================================
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c7108000
[00000000] *pgd=87077031, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1]
Modules linked in: ipv6 rtl8187 eeprom_93cx6
CPU: 0 Not tainted (2.6.27-rc3-omap1 #1)
PC is at snd_pcm_info+0xc/0xe0
LR is at snd_pcm_info_user+0x38/0x94
pc : [<c0256344>] lr : [<c0256450>] psr: a0000013
sp : c716bd98 ip : c716bdb8 fp : c716bdb4
r10: 00000001 r9 : c716a000 r8 : c002ce04
r7 : 00000000 r6 : 00000000 r5 : c70ed600 r4 : beaff480
r3 : 00000001 r2 : 40044145 r1 : c70ed600 r0 : 00000000
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 00c5387f Table: 87108018 DAC: 00000015
Process mplayer (pid: 1757, stack limit = 0xc716a2e8)
Stack: (0xc716bd98 to 0xc716c000)
bd80: beaff480 c70ed600
bda0: 00000000 00000000 c716bdd4 c716bdb8 c0256450 c0256344 beaff480 beaff480
bdc0: 00000005 00000000 c716befc c716bdd8 c0257544 c0256424 84cda0ff c0518b40
bde0: c716be3c c716bdf0 c008373c c007e2f0 c716be14 c7109018 00000001 00000000
be00: 00000001 0000001f 406d5000 c0518b40 c00636b4 00000001 00000000 c716a000
be20: c7bc56e0 406d5000 00000354 c7108000 c716be94 c716be40 c0084280 c00833b8
be40: 0000001f 00000001 00000000 c0518ac0 c716be74 00000001 c7163600 c007dc38
be60: 84cda0ff c0518b40 c716be94 c716be78 c0083d8c c007e470 00000000 00000003
be80: 0000001f c7bc56e0 c716bedc c716be98 c008474c c0083cb0 00000000 00000000
bea0: c7163600 c7864420 00000003 00000022 c0151c6c 00000020 c716a000 406b6000
bec0: 406b6000 c7163600 080020fb 406d6000 c716bf0c 81204101 beaff480 00000005
bee0: 00000000 c002ce04 c716a000 00000001 c716bf2c c716bf00 c0258b5c c025739c
bf00: c716bf54 c716bf10 c00868dc c0085b78 81204101 beaff480 00000005 c70b7080
bf20: c716bf3c c716bf30 c0258c78 c025876c c716bf54 c716bf40 c00a5bb8 c0258c50
bf40: c70b7080 beaff480 c716bf7c c716bf58 c00a5e6c c00a5b90 406b6000 00000096
bf60: 00000005 beaff480 81204101 c70b7080 c716bfa4 c716bf80 c00a5ebc c00a5c08
bf80: c0086b54 00000000 402c0444 007ee3b0 402c0444 00000036 00000000 c716bfa8
bfa0: c002cc80 c00a5e88 402c0444 007ee3b0 00000005 81204101 beaff480 007fbf10
bfc0: 402c0444 007ee3b0 402c0444 00000036 beaff480 00000016 00000001 beaff65c
bfe0: 007ee3b0 beaff458 4025a3d8 404c099c 20000010 00000005 00000000 00000000
Backtrace:
[<c0256338>] (snd_pcm_info+0x0/0xe0) from [<c0256450>]
(snd_pcm_info_user+0x38/0x94)
r7:00000000 r6:00000000 r5:c70ed600 r4:beaff480
[<c0256418>] (snd_pcm_info_user+0x0/0x94) from [<c0257544>]
(snd_pcm_common_ioctl1+0x1b4/0xf9c)
r7:00000000 r6:00000005 r5:beaff480 r4:beaff480
[<c0257390>] (snd_pcm_common_ioctl1+0x0/0xf9c) from [<c0258b5c>]
(snd_pcm_playback_ioctl1+0x3fc/0x420)
[<c0258760>] (snd_pcm_playback_ioctl1+0x0/0x420) from [<c0258c78>]
(snd_pcm_playback_ioctl+0x34/0x38)
r7:c70b7080 r6:00000005 r5:beaff480 r4:81204101
[<c0258c44>] (snd_pcm_playback_ioctl+0x0/0x38) from [<c00a5bb8>]
(vfs_ioctl+0x34/0x78)
[<c00a5b84>] (vfs_ioctl+0x0/0x78) from [<c00a5e6c>] (do_vfs_ioctl+0x270/0x280)
r5:beaff480 r4:c70b7080
[<c00a5bfc>] (do_vfs_ioctl+0x0/0x280) from [<c00a5ebc>] (sys_ioctl+0x40/0x64)
r7:c70b7080 r6:81204101 r5:beaff480 r4:00000005
[<c00a5e7c>] (sys_ioctl+0x0/0x64) from [<c002cc80>] (ret_fast_syscall+0x0/0x2c)
r7:00000036 r6:402c0444 r5:007ee3b0 r4:402c0444
Code: e89da830 e1a0c00d e92dd8f0 e24cb004 (e5904000)
---[ end trace 85720182f0be6892 ]---
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 17 [#2]
Modules linked in: ipv6 rtl8187 eeprom_93cx6
CPU: 0 Tainted: G D (2.6.27-rc3-omap1 #1)
PC is at snd_pcm_release+0x20/0x88
LR is at __fput+0xb8/0x170
pc : [<c0255900>] lr : [<c009af68>] psr: a0000013
sp : c716bb60 ip : c716bb88 fp : c716bb84
r10: c7854000 r9 : c716bd50 r8 : c70b7080
r7 : c70c72a8 r6 : c70b7080 r5 : c79f6ab0 r4 : 00000000
r3 : c02558e0 r2 : 00000000 r1 : c70b7080 r0 : ffffffff
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 00c5387f Table: 871c8018 DAC: 00000015
Process mplayer (pid: 1757, stack limit = 0xc716a2e8)
Stack: (0xc716bb60 to 0xc716c000)
bb60: 00000008 c79f6ab0 c70b7080 c7887608 c74d9780 c716bd50 c716bbb4 c716bb88
bb80: c009af68 c02558ec 00000000 c716a000 c70b7080 00000000 c7887600 c7887608
bba0: 00000000 00000008 c716bbc4 c716bbb8 c009b2dc c009aebc c716bbe4 c716bbc8
bbc0: c009804c c009b2b8 c7887600 00000001 00000014 c7887608 c716bc0c c716bbe8
bbe0: c004de48 c0097fe4 c716a000 c7864420 0000000b c0256344 00000001 c716bd50
bc00: c716bc1c c716bc10 c004dec4 c004ddd0 c716bc34 c716bc20 c004f10c c004dea8
bc20: c004c458 c004c270 c716bc44 c716bc38 c0030864 c004ef0c c716bc64 c716bc48
bc40: c0031cf0 c00305cc 00010000 c71c5420 c7864420 c7163634 c716bca4 c716bc68
bc60: c0031f08 c0031c90 00000000 c0435cdc 00000000 00000017 c716bcac c0426850
bc80: 00000017 c716bd50 00000000 c002ce04 60000113 00000001 c716bd4c c716bca8
bca0: c002c1e8 c0031d0c c007b008 c007986c 00000044 c0436498 00000000 00000000
bcc0: c04364a4 00000000 00000002 00000001 00000000 c716a000 c0435cdc c0435cdc
bce0: c0051174 c043649c 001200d2 c0436498 00000000 c7864420 001200d2 00000000
bd00: c716bd6c c716bd10 c0518b44 c0518b40 c7162ecc 0000001f 00000000 c7162dc0
bd20: 001200d2 00000000 c716bd54 c716bd38 ffffffff c716bd84 00000000 00000000
bd40: c716bdb4 c716bd50 c002c7ec c002c1b8 00000000 c70ed600 40044145 00000001
bd60: beaff480 c70ed600 00000000 00000000 c002ce04 c716a000 00000001 c716bdb4
bd80: c716bdb8 c716bd98 c0256450 c0256344 a0000013 ffffffff beaff480 c70ed600
bda0: 00000000 00000000 c716bdd4 c716bdb8 c0256450 c0256344 beaff480 beaff480
bdc0: 00000005 00000000 c716befc c716bdd8 c0257544 c0256424 84cda0ff c0518b40
bde0: c716be3c c716bdf0 c008373c c007e2f0 c716be14 c7109018 00000001 00000000
be00: 00000001 0000001f 406d5000 c0518b40 c00636b4 00000001 00000000 c716a000
be20: c7bc56e0 406d5000 00000354 c7108000 c716be94 c716be40 c0084280 c00833b8
be40: 0000001f 00000001 00000000 c0518ac0 c716be74 00000001 c7163600 c007dc38
be60: 84cda0ff c0518b40 c716be94 c716be78 c0083d8c c007e470 00000000 00000003
be80: 0000001f c7bc56e0 c716bedc c716be98 c008474c c0083cb0 00000000 00000000
bea0: c7163600 c7864420 00000003 00000022 c0151c6c 00000020 c716a000 406b6000
bec0: 406b6000 c7163600 080020fb 406d6000 c716bf0c 81204101 beaff480 00000005
bee0: 00000000 c002ce04 c716a000 00000001 c716bf2c c716bf00 c0258b5c c025739c
bf00: c716bf54 c716bf10 c00868dc c0085b78 81204101 beaff480 00000005 c70b7080
bf20: c716bf3c c716bf30 c0258c78 c025876c c716bf54 c716bf40 c00a5bb8 c0258c50
bf40: c70b7080 beaff480 c716bf7c c716bf58 c00a5e6c c00a5b90 406b6000 00000096
bf60: 00000005 beaff480 81204101 c70b7080 c716bfa4 c716bf80 c00a5ebc c00a5c08
bf80: c0086b54 00000000 402c0444 007ee3b0 402c0444 00000036 00000000 c716bfa8
bfa0: c002cc80 c00a5e88 402c0444 007ee3b0 00000005 81204101 beaff480 007fbf10
bfc0: 402c0444 007ee3b0 402c0444 00000036 beaff480 00000016 00000001 beaff65c
bfe0: 007ee3b0 beaff458 4025a3d8 404c099c 20000010 00000005 00000000 00000000
Backtrace:
[<c02558e0>] (snd_pcm_release+0x0/0x88) from [<c009af68>] (__fput+0xb8/0x170)
r9:c716bd50 r8:c74d9780 r7:c7887608 r6:c70b7080 r5:c79f6ab0
r4:00000008
[<c009aeb0>] (__fput+0x0/0x170) from [<c009b2dc>] (fput+0x30/0x34)
[<c009b2ac>] (fput+0x0/0x34) from [<c009804c>] (filp_close+0x74/0x80)
[<c0097fd8>] (filp_close+0x0/0x80) from [<c004de48>]
(put_files_struct+0x84/0xd8)
r7:c7887608 r6:00000014 r5:00000001 r4:c7887600
[<c004ddc4>] (put_files_struct+0x0/0xd8) from [<c004dec4>]
(exit_files+0x28/0x2c)
r9:c716bd50 r8:00000001 r7:c0256344 r6:0000000b r5:c7864420
r4:c716a000
[<c004de9c>] (exit_files+0x0/0x2c) from [<c004f10c>] (do_exit+0x20c/0x6e8)
[<c004ef00>] (do_exit+0x0/0x6e8) from [<c0030864>] (die+0x2a4/0x300)
[<c00305c0>] (die+0x0/0x300) from [<c0031cf0>] (__do_kernel_fault+0x6c/0x7c)
[<c0031c84>] (__do_kernel_fault+0x0/0x7c) from [<c0031f08>]
(do_page_fault+0x208/0x224)
r7:c7163634 r6:c7864420 r5:c71c5420 r4:00010000
[<c0031d00>] (do_page_fault+0x0/0x224) from [<c002c1e8>]
(do_DataAbort+0x3c/0x9c)
[<c002c1ac>] (do_DataAbort+0x0/0x9c) from [<c002c7ec>] (__dabt_svc+0x4c/0x60)
Exception stack(0xc716bd50 to 0xc716bd98)
bd40: 00000000 c70ed600 40044145 00000001
bd60: beaff480 c70ed600 00000000 00000000 c002ce04 c716a000 00000001 c716bdb4
bd80: c716bdb8 c716bd98 c0256450 c0256344 a0000013 ffffffff
r7:00000000 r6:00000000 r5:c716bd84 r4:ffffffff
[<c0256338>] (snd_pcm_info+0x0/0xe0) from [<c0256450>]
(snd_pcm_info_user+0x38/0x94)
r7:00000000 r6:00000000 r5:c70ed600 r4:beaff480
[<c0256418>] (snd_pcm_info_user+0x0/0x94) from [<c0257544>]
(snd_pcm_common_ioctl1+0x1b4/0xf9c)
r7:00000000 r6:00000005 r5:beaff480 r4:beaff480
[<c0257390>] (snd_pcm_common_ioctl1+0x0/0xf9c) from [<c0258b5c>]
(snd_pcm_playback_ioctl1+0x3fc/0x420)
[<c0258760>] (snd_pcm_playback_ioctl1+0x0/0x420) from [<c0258c78>]
(snd_pcm_playback_ioctl+0x34/0x38)
r7:c70b7080 r6:00000005 r5:beaff480 r4:81204101
[<c0258c44>] (snd_pcm_playback_ioctl+0x0/0x38) from [<c00a5bb8>]
(vfs_ioctl+0x34/0x78)
[<c00a5b84>] (vfs_ioctl+0x0/0x78) from [<c00a5e6c>] (do_vfs_ioctl+0x270/0x280)
r5:beaff480 r4:c70b7080
[<c00a5bfc>] (do_vfs_ioctl+0x0/0x280) from [<c00a5ebc>] (sys_ioctl+0x40/0x64)
r7:c70b7080 r6:81204101 r5:beaff480 r4:00000005
[<c00a5e7c>] (sys_ioctl+0x0/0x64) from [<c002cc80>] (ret_fast_syscall+0x0/0x2c)
r7:00000036 r6:402c0444 r5:007ee3b0 r4:402c0444
Code: e3a02000 e3e00000 e5974000 e1a08001 (e5945000)
---[ end trace 85720182f0be6892 ]---
Fixing recursive fault but reboot is needed!
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-25 22:30 ` Steve Sakoman
@ 2008-08-25 22:40 ` Felipe Balbi
2008-08-25 22:54 ` Felipe Balbi
0 siblings, 1 reply; 40+ messages in thread
From: Felipe Balbi @ 2008-08-25 22:40 UTC (permalink / raw)
To: Steve Sakoman; +Cc: me, Jarkko Nikula, linux-omap@vger.kernel.org
On Mon, Aug 25, 2008 at 03:30:13PM -0700, Steve Sakoman wrote:
> > Hmm, so the crash is actually somewhere else. Could you disable debug
> > and get the NULL pointer dereference at the right point ?
>
> The output is below. The crash seems to occur at the substream
> pointer dereference in the second line of snd_pcm_info (in
> pcm_native.c):
>
> struct snd_pcm *pcm = substream->pcm;
yeah, at that point substream was NULL. I'm trying to trace the function
call to see why substream is getting NULLed.
I think the following patch is anyway a good thing to apply:
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index c49b9d9..c7c15cf 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -92,10 +92,11 @@ static inline void snd_leave_user(mm_segment_t fs)
int snd_pcm_info(struct snd_pcm_substream *substream, struct snd_pcm_info *info)
{
struct snd_pcm_runtime *runtime;
- struct snd_pcm *pcm = substream->pcm;
+ struct snd_pcm *pcm;
struct snd_pcm_str *pstr = substream->pstr;
snd_assert(substream != NULL, return -ENXIO);
+ pcm = substream->pcm;
memset(info, 0, sizeof(*info));
info->card = pcm->card->number;
info->device = pcm->device;
--
balbi
^ permalink raw reply related [flat|nested] 40+ messages in thread* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-25 22:40 ` Felipe Balbi
@ 2008-08-25 22:54 ` Felipe Balbi
2008-08-25 23:34 ` Steve Sakoman
0 siblings, 1 reply; 40+ messages in thread
From: Felipe Balbi @ 2008-08-25 22:54 UTC (permalink / raw)
To: Felipe Balbi; +Cc: Steve Sakoman, Jarkko Nikula, linux-omap@vger.kernel.org
On Tue, Aug 26, 2008 at 01:40:06AM +0300, Felipe Balbi wrote:
> On Mon, Aug 25, 2008 at 03:30:13PM -0700, Steve Sakoman wrote:
> > > Hmm, so the crash is actually somewhere else. Could you disable debug
> > > and get the NULL pointer dereference at the right point ?
> >
> > The output is below. The crash seems to occur at the substream
> > pointer dereference in the second line of snd_pcm_info (in
> > pcm_native.c):
> >
> > struct snd_pcm *pcm = substream->pcm;
>
> yeah, at that point substream was NULL. I'm trying to trace the function
> call to see why substream is getting NULLed.
>
> I think the following patch is anyway a good thing to apply:
>
> diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
> index c49b9d9..c7c15cf 100644
> --- a/sound/core/pcm_native.c
> +++ b/sound/core/pcm_native.c
> @@ -92,10 +92,11 @@ static inline void snd_leave_user(mm_segment_t fs)
> int snd_pcm_info(struct snd_pcm_substream *substream, struct snd_pcm_info *info)
> {
> struct snd_pcm_runtime *runtime;
> - struct snd_pcm *pcm = substream->pcm;
> + struct snd_pcm *pcm;
> struct snd_pcm_str *pstr = substream->pstr;
>
> snd_assert(substream != NULL, return -ENXIO);
> + pcm = substream->pcm;
> memset(info, 0, sizeof(*info));
> info->card = pcm->card->number;
> info->device = pcm->device;
can you also apply this other patch:
diff --git a/sound/core/pcm.c b/sound/core/pcm.c
index 9dd9bc7..b8f43f3 100644
--- a/sound/core/pcm.c
+++ b/sound/core/pcm.c
@@ -774,7 +774,7 @@ int snd_pcm_attach_substream(struct snd_pcm *pcm, int stream,
size_t size;
snd_assert(rsubstream != NULL, return -EINVAL);
- *rsubstream = NULL;
+// *rsubstream = NULL; why NULL it ?? need to investigate more
snd_assert(pcm != NULL, return -ENXIO);
pstr = &pcm->streams[stream];
if (pstr->substream == NULL || pstr->substream_count == 0)
@@ -795,8 +795,11 @@ int snd_pcm_attach_substream(struct snd_pcm *pcm, int stream,
case SNDRV_PCM_STREAM_PLAYBACK:
if (pcm->info_flags & SNDRV_PCM_INFO_HALF_DUPLEX) {
for (substream = pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream; substream; substream = substream->
- if (SUBSTREAM_BUSY(substream))
+ if (!substream)
return -EAGAIN;
+
+ if (SUBSTREAM_BUSY(substream))
+ continue;
}
}
break;
@@ -875,6 +878,10 @@ int snd_pcm_attach_substream(struct snd_pcm *pcm, int stream,
substream->ref_count = 1;
substream->f_flags = file->f_flags;
pstr->substream_opened++;
+
+ if (!substream)
+ printk(KERN_INFO "substream is NULL\n");
+
*rsubstream = substream;
return 0;
}
--
balbi
^ permalink raw reply related [flat|nested] 40+ messages in thread* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-25 22:54 ` Felipe Balbi
@ 2008-08-25 23:34 ` Steve Sakoman
2008-08-26 0:08 ` Felipe Balbi
0 siblings, 1 reply; 40+ messages in thread
From: Steve Sakoman @ 2008-08-25 23:34 UTC (permalink / raw)
To: me; +Cc: Jarkko Nikula, linux-omap@vger.kernel.org
> can you also apply this other patch:
>
> diff --git a/sound/core/pcm.c b/sound/core/pcm.c
That patch didn't seem to have an effect, pretty much the same crash:
root@overo:~# mplayer -ao alsa /Watermelon_Slim-Black_Water.mp3
MPlayer 1.0rc2-4.3.1 (C) 2000-2007 MPlayer Team
CPU: ARM
Playing /Watermelon_Slim-Black_Water.mp3.
Audio file file format detected.
Clip info:
Title: Black Water
Artist: Watermelon Slim
Album: http://music.download.com
Year: 2007
Comment: http://music.download.com/
Track: 1
Genre: Unknown
==========================================================================
Forced audio codec: mad
Opening audio decoder: [libmad] libmad mpeg audio decoder
AUDIO: 44100 Hz, 2 ch, s16le, 192.0 kbit/13.61% (ratio: 24000->176400)
Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3)
==========================================================================
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c7128000
[00000000] *pgd=871c9031, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1]
Modules linked in: ipv6 rtl8187 eeprom_93cx6
CPU: 0 Not tainted (2.6.27-rc3-omap1 #1)
PC is at snd_pcm_info+0xc/0xe0
LR is at snd_pcm_info_user+0x38/0x94
pc : [<c0256330>] lr : [<c025643c>] psr: a0000013
sp : c71ddd98 ip : c71dddb8 fp : c71dddb4
r10: 00000001 r9 : c71dc000 r8 : c002ce04
r7 : 00000000 r6 : 00000000 r5 : c7077600 r4 : bee1d480
r3 : 00000001 r2 : 40044145 r1 : c7077600 r0 : 00000000
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 00c5387f Table: 87128018 DAC: 00000015
Process mplayer (pid: 1720, stack limit = 0xc71dc2e8)
Stack: (0xc71ddd98 to 0xc71de000)
dd80: bee1d480 c7077600
dda0: 00000000 00000000 c71dddd4 c71dddb8 c025643c c0256330 bee1d480 bee1d480
ddc0: 00000005 00000000 c71ddefc c71dddd8 c0257530 c0256410 84e030ff c051b060
dde0: c71dde3c c71dddf0 c008373c c007e2f0 c005059c c7129018 00000001 00000000
de00: 00000001 0000001f 406d5000 c051b060 c0171ed0 00000001 00000000 c71dc000
de20: c71d2160 406d5000 00000354 c7128000 c71dde94 c71dde40 c0084280 c00833b8
de40: 0000001f 00000001 00000000 c051afe0 c71dde74 00000001 c7123300 c007dc38
de60: 84e030ff c051b060 c71dde94 c71dde78 c0083d8c c007e470 00000000 00000003
de80: 0000001f c71d2160 c71ddedc c71dde98 c008474c c0083cb0 00000000 00000000
dea0: c7123300 c7866520 00000003 00000022 c0151c6c 00000020 c71dc000 406b6000
dec0: 406b6000 c7123300 080020fb 406d6000 c71ddf0c 81204101 bee1d480 00000005
dee0: 00000000 c002ce04 c71dc000 00000001 c71ddf2c c71ddf00 c0258b48 c0257388
df00: c71ddf54 c71ddf10 c00868dc c0085b78 81204101 bee1d480 00000005 c71d3d80
df20: c71ddf3c c71ddf30 c0258c64 c0258758 c71ddf54 c71ddf40 c00a5bb8 c0258c3c
df40: c71d3d80 bee1d480 c71ddf7c c71ddf58 c00a5e6c c00a5b90 406b6000 00000096
df60: 00000005 bee1d480 81204101 c71d3d80 c71ddfa4 c71ddf80 c00a5ebc c00a5c08
df80: c0086b54 00000000 402c0444 007ee3b0 402c0444 00000036 00000000 c71ddfa8
dfa0: c002cc80 c00a5e88 402c0444 007ee3b0 00000005 81204101 bee1d480 007fbf10
dfc0: 402c0444 007ee3b0 402c0444 00000036 bee1d480 00000016 00000001 bee1d65c
dfe0: 007ee3b0 bee1d458 4025a3d8 404c099c 20000010 00000005 00000000 00000000
Backtrace:
[<c0256324>] (snd_pcm_info+0x0/0xe0) from [<c025643c>]
(snd_pcm_info_user+0x38/0x94)
r7:00000000 r6:00000000 r5:c7077600 r4:bee1d480
[<c0256404>] (snd_pcm_info_user+0x0/0x94) from [<c0257530>]
(snd_pcm_common_ioctl1+0x1b4/0xf9c)
r7:00000000 r6:00000005 r5:bee1d480 r4:bee1d480
[<c025737c>] (snd_pcm_common_ioctl1+0x0/0xf9c) from [<c0258b48>]
(snd_pcm_playback_ioctl1+0x3fc/0x420)
[<c025874c>] (snd_pcm_playback_ioctl1+0x0/0x420) from [<c0258c64>]
(snd_pcm_playback_ioctl+0x34/0x38)
r7:c71d3d80 r6:00000005 r5:bee1d480 r4:81204101
[<c0258c30>] (snd_pcm_playback_ioctl+0x0/0x38) from [<c00a5bb8>]
(vfs_ioctl+0x34/0x78)
[<c00a5b84>] (vfs_ioctl+0x0/0x78) from [<c00a5e6c>] (do_vfs_ioctl+0x270/0x280)
r5:bee1d480 r4:c71d3d80
[<c00a5bfc>] (do_vfs_ioctl+0x0/0x280) from [<c00a5ebc>] (sys_ioctl+0x40/0x64)
r7:c71d3d80 r6:81204101 r5:bee1d480 r4:00000005
[<c00a5e7c>] (sys_ioctl+0x0/0x64) from [<c002cc80>] (ret_fast_syscall+0x0/0x2c)
r7:00000036 r6:402c0444 r5:007ee3b0 r4:402c0444
Code: e89da830 e1a0c00d e92dd8f0 e24cb004 (e5904000)
---[ end trace 7a94571fa90e8e6c ]---
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 17 [#2]
Modules linked in: ipv6 rtl8187 eeprom_93cx6
CPU: 0 Tainted: G D (2.6.27-rc3-omap1 #1)
PC is at snd_pcm_release+0x20/0x88
LR is at __fput+0xb8/0x170
pc : [<c02558ec>] lr : [<c009af68>] psr: a0000013
sp : c71ddb60 ip : c71ddb88 fp : c71ddb84
r10: c79d8200 r9 : c71ddd50 r8 : c71d3d80
r7 : c70372a8 r6 : c71d3d80 r5 : c70da3d0 r4 : 00000000
r3 : c02558cc r2 : 00000000 r1 : c71d3d80 r0 : ffffffff
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 00c5387f Table: 87180018 DAC: 00000015
Process mplayer (pid: 1720, stack limit = 0xc71dc2e8)
Stack: (0xc71ddb60 to 0xc71de000)
db60: 00000008 c70da3d0 c71d3d80 c7bf1788 c74dea80 c71ddd50 c71ddbb4 c71ddb88
db80: c009af68 c02558d8 00000000 c71dc000 c71d3d80 00000000 c7bf1780 c7bf1788
dba0: 00000000 00000008 c71ddbc4 c71ddbb8 c009b2dc c009aebc c71ddbe4 c71ddbc8
dbc0: c009804c c009b2b8 c7bf1780 00000001 00000014 c7bf1788 c71ddc0c c71ddbe8
dbe0: c004de48 c0097fe4 c71dc000 c7866520 0000000b c0256330 00000001 c71ddd50
dc00: c71ddc1c c71ddc10 c004dec4 c004ddd0 c71ddc34 c71ddc20 c004f10c c004dea8
dc20: c004c458 c004c270 c71ddc44 c71ddc38 c0030864 c004ef0c c71ddc64 c71ddc48
dc40: c0031cf0 c00305cc 00010000 c71dff78 c7866520 c7123334 c71ddca4 c71ddc68
dc60: c0031f08 c0031c90 00000000 c0435cdc 00000000 00000017 c71ddcac c0426850
dc80: 00000017 c71ddd50 00000000 c002ce04 60000113 00000001 c71ddd4c c71ddca8
dca0: c002c1e8 c0031d0c c007b008 c007986c 00000044 c0436498 00000000 00000000
dcc0: c04364a4 00000000 00000002 00000001 00000000 c71dc000 c0435cdc c0435cdc
dce0: c044a3d0 c043649c 001200d2 c0436498 00000000 c7866520 001200d2 00000000
dd00: c71ddd6c c71ddd10 c051b064 c051b060 c70a7634 0000001f 00000000 c70a7528
dd20: 001200d2 00000000 c71ddd54 c71ddd38 ffffffff c71ddd84 00000000 00000000
dd40: c71dddb4 c71ddd50 c002c7ec c002c1b8 00000000 c7077600 40044145 00000001
dd60: bee1d480 c7077600 00000000 00000000 c002ce04 c71dc000 00000001 c71dddb4
dd80: c71dddb8 c71ddd98 c025643c c0256330 a0000013 ffffffff bee1d480 c7077600
dda0: 00000000 00000000 c71dddd4 c71dddb8 c025643c c0256330 bee1d480 bee1d480
ddc0: 00000005 00000000 c71ddefc c71dddd8 c0257530 c0256410 84e030ff c051b060
dde0: c71dde3c c71dddf0 c008373c c007e2f0 c005059c c7129018 00000001 00000000
de00: 00000001 0000001f 406d5000 c051b060 c0171ed0 00000001 00000000 c71dc000
de20: c71d2160 406d5000 00000354 c7128000 c71dde94 c71dde40 c0084280 c00833b8
de40: 0000001f 00000001 00000000 c051afe0 c71dde74 00000001 c7123300 c007dc38
de60: 84e030ff c051b060 c71dde94 c71dde78 c0083d8c c007e470 00000000 00000003
de80: 0000001f c71d2160 c71ddedc c71dde98 c008474c c0083cb0 00000000 00000000
dea0: c7123300 c7866520 00000003 00000022 c0151c6c 00000020 c71dc000 406b6000
dec0: 406b6000 c7123300 080020fb 406d6000 c71ddf0c 81204101 bee1d480 00000005
dee0: 00000000 c002ce04 c71dc000 00000001 c71ddf2c c71ddf00 c0258b48 c0257388
df00: c71ddf54 c71ddf10 c00868dc c0085b78 81204101 bee1d480 00000005 c71d3d80
df20: c71ddf3c c71ddf30 c0258c64 c0258758 c71ddf54 c71ddf40 c00a5bb8 c0258c3c
df40: c71d3d80 bee1d480 c71ddf7c c71ddf58 c00a5e6c c00a5b90 406b6000 00000096
df60: 00000005 bee1d480 81204101 c71d3d80 c71ddfa4 c71ddf80 c00a5ebc c00a5c08
df80: c0086b54 00000000 402c0444 007ee3b0 402c0444 00000036 00000000 c71ddfa8
dfa0: c002cc80 c00a5e88 402c0444 007ee3b0 00000005 81204101 bee1d480 007fbf10
dfc0: 402c0444 007ee3b0 402c0444 00000036 bee1d480 00000016 00000001 bee1d65c
dfe0: 007ee3b0 bee1d458 4025a3d8 404c099c 20000010 00000005 00000000 00000000
Backtrace:
[<c02558cc>] (snd_pcm_release+0x0/0x88) from [<c009af68>] (__fput+0xb8/0x170)
r9:c71ddd50 r8:c74dea80 r7:c7bf1788 r6:c71d3d80 r5:c70da3d0
r4:00000008
[<c009aeb0>] (__fput+0x0/0x170) from [<c009b2dc>] (fput+0x30/0x34)
[<c009b2ac>] (fput+0x0/0x34) from [<c009804c>] (filp_close+0x74/0x80)
[<c0097fd8>] (filp_close+0x0/0x80) from [<c004de48>]
(put_files_struct+0x84/0xd8)
r7:c7bf1788 r6:00000014 r5:00000001 r4:c7bf1780
[<c004ddc4>] (put_files_struct+0x0/0xd8) from [<c004dec4>]
(exit_files+0x28/0x2c)
r9:c71ddd50 r8:00000001 r7:c0256330 r6:0000000b r5:c7866520
r4:c71dc000
[<c004de9c>] (exit_files+0x0/0x2c) from [<c004f10c>] (do_exit+0x20c/0x6e8)
[<c004ef00>] (do_exit+0x0/0x6e8) from [<c0030864>] (die+0x2a4/0x300)
[<c00305c0>] (die+0x0/0x300) from [<c0031cf0>] (__do_kernel_fault+0x6c/0x7c)
[<c0031c84>] (__do_kernel_fault+0x0/0x7c) from [<c0031f08>]
(do_page_fault+0x208/0x224)
r7:c7123334 r6:c7866520 r5:c71dff78 r4:00010000
[<c0031d00>] (do_page_fault+0x0/0x224) from [<c002c1e8>]
(do_DataAbort+0x3c/0x9c)
[<c002c1ac>] (do_DataAbort+0x0/0x9c) from [<c002c7ec>] (__dabt_svc+0x4c/0x60)
Exception stack(0xc71ddd50 to 0xc71ddd98)
dd40: 00000000 c7077600 40044145 00000001
dd60: bee1d480 c7077600 00000000 00000000 c002ce04 c71dc000 00000001 c71dddb4
dd80: c71dddb8 c71ddd98 c025643c c0256330 a0000013 ffffffff
r7:00000000 r6:00000000 r5:c71ddd84 r4:ffffffff
[<c0256324>] (snd_pcm_info+0x0/0xe0) from [<c025643c>]
(snd_pcm_info_user+0x38/0x94)
r7:00000000 r6:00000000 r5:c7077600 r4:bee1d480
[<c0256404>] (snd_pcm_info_user+0x0/0x94) from [<c0257530>]
(snd_pcm_common_ioctl1+0x1b4/0xf9c)
r7:00000000 r6:00000005 r5:bee1d480 r4:bee1d480
[<c025737c>] (snd_pcm_common_ioctl1+0x0/0xf9c) from [<c0258b48>]
(snd_pcm_playback_ioctl1+0x3fc/0x420)
[<c025874c>] (snd_pcm_playback_ioctl1+0x0/0x420) from [<c0258c64>]
(snd_pcm_playback_ioctl+0x34/0x38)
r7:c71d3d80 r6:00000005 r5:bee1d480 r4:81204101
[<c0258c30>] (snd_pcm_playback_ioctl+0x0/0x38) from [<c00a5bb8>]
(vfs_ioctl+0x34/0x78)
[<c00a5b84>] (vfs_ioctl+0x0/0x78) from [<c00a5e6c>] (do_vfs_ioctl+0x270/0x280)
r5:bee1d480 r4:c71d3d80
[<c00a5bfc>] (do_vfs_ioctl+0x0/0x280) from [<c00a5ebc>] (sys_ioctl+0x40/0x64)
r7:c71d3d80 r6:81204101 r5:bee1d480 r4:00000005
[<c00a5e7c>] (sys_ioctl+0x0/0x64) from [<c002cc80>] (ret_fast_syscall+0x0/0x2c)
r7:00000036 r6:402c0444 r5:007ee3b0 r4:402c0444
Code: e3a02000 e3e00000 e5974000 e1a08001 (e5945000)
---[ end trace 7a94571fa90e8e6c ]---
Fixing recursive fault but reboot is needed!
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-25 23:34 ` Steve Sakoman
@ 2008-08-26 0:08 ` Felipe Balbi
0 siblings, 0 replies; 40+ messages in thread
From: Felipe Balbi @ 2008-08-26 0:08 UTC (permalink / raw)
To: Steve Sakoman; +Cc: me, Jarkko Nikula, linux-omap@vger.kernel.org
On Mon, Aug 25, 2008 at 04:34:40PM -0700, Steve Sakoman wrote:
> > can you also apply this other patch:
> >
> > diff --git a/sound/core/pcm.c b/sound/core/pcm.c
>
> That patch didn't seem to have an effect, pretty much the same crash:
Hmm... so more investigation is needed but now is already too late for
me, it's past 3am :-p
If Jarkko doesn't get a fix before me (I'm pretty sure he will :-p) I'll
try to dig more when I wake up.
But the problems seems to be on the file open() path. Try to track down
the use of struct snd_pcm_substream, starting at
pcm_native.c:snd_pcm_open_file().
Put some printks around that function and see when substream is getting
nulled.
Something like:
printk(KERN_INFO "%s %d substream %p\n", __func__, __LINE__, substream);
And go down the functional calls following the ones that have a struct
snd_pcm_substream as argument. That will probably allow you to see where
substream is getting NULLed and try to guess a fix for that.
--
balbi
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-25 19:19 ` Steve Sakoman
2008-08-25 19:29 ` Felipe Balbi
2008-08-25 21:35 ` Felipe Balbi
@ 2008-08-26 13:19 ` Jarkko Nikula
2008-08-26 14:23 ` Steve Sakoman
2008-08-26 17:18 ` Steve Sakoman
2 siblings, 2 replies; 40+ messages in thread
From: Jarkko Nikula @ 2008-08-26 13:19 UTC (permalink / raw)
To: ext Steve Sakoman; +Cc: linux-omap@vger.kernel.org
On Mon, 25 Aug 2008 12:19:16 -0700
"ext Steve Sakoman" <sakoman@gmail.com> wrote:
> If I run 'mplayer -ao alsa song.mp3' immediately after booting I get a
> crash due to a null substream pointer (output below).
>
> However if I run 'mplayer song.mp3' *before* 'mplayer -ao alsa
> song.mp3' then the latter command works!
>
Sounds indeed strange. Can you track is the pcm_file->substream getting
zeroed somewhere after it is set in snd_pcm_open_file? Like printing
both address of pcm_file and pcm_file->substream.
I don't know, can we still have some instabilities with OMAP3 and
latest 2.6.27-rcx?
Jarkko
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-26 13:19 ` Jarkko Nikula
@ 2008-08-26 14:23 ` Steve Sakoman
2008-08-26 17:18 ` Steve Sakoman
1 sibling, 0 replies; 40+ messages in thread
From: Steve Sakoman @ 2008-08-26 14:23 UTC (permalink / raw)
To: Jarkko Nikula; +Cc: linux-omap@vger.kernel.org
> Sounds indeed strange. Can you track is the pcm_file->substream getting
> zeroed somewhere after it is set in snd_pcm_open_file? Like printing
> both address of pcm_file and pcm_file->substream.
>
> I don't know, can we still have some instabilities with OMAP3 and
> latest 2.6.27-rcx?
That is my suspicion also.
I have tracked things through the exit of snd_pcm_open_file and found
the substream pointer to be valid to that point.
The null substream pointer seems to be coming in to a
snd_pcm_playback_ioctl call that occurs after the file open (I suspect
from a
call to snd_pcm_hw_info in alsa-lib)
Looks like I need to start adding debug printf's in alsa-lib too. I'm
working on this as a background task while bringing up some new hw so
progress is a bit slow :-(
Steve
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-26 13:19 ` Jarkko Nikula
2008-08-26 14:23 ` Steve Sakoman
@ 2008-08-26 17:18 ` Steve Sakoman
2008-08-27 6:38 ` Jarkko Nikula
1 sibling, 1 reply; 40+ messages in thread
From: Steve Sakoman @ 2008-08-26 17:18 UTC (permalink / raw)
To: Jarkko Nikula, Felipe Balbi; +Cc: linux-omap@vger.kernel.org
> Sounds indeed strange. Can you track is the pcm_file->substream getting
> zeroed somewhere after it is set in snd_pcm_open_file? Like printing
> both address of pcm_file and pcm_file->substream.
I added a bunch of tracking to the ioctl handling in pcm_native.c to
see where the substream pointer goes null.
It appears that substream is valid through the SNDRV_PCM_IOCTL_START
ioctl call, and then goes null for SNDRV_PCM_IOCTL_PVERSION and
SNDRV_PCM_IOCTL_INFO where it finally crashes.
I don't believe that it is the SNDRV_PCM_IOCTL_START that writes a
null in substream, so it is likely something in alsa-lib :-(
It isn't confidence inspiring to see comments like /* AB: FIXME!!!
This is definitely nonsense */ in snd_pcm_info (the function where it
finally crashes)
Steve
root@overo:~# mplayer -ao alsa /Watermelon_Slim-Black_Water.mp3
MPlayer 1.0rc2-4.3.1 (C) 2000-2007 MPlayer Team
CPU: ARM
Playing /Watermelon_Slim-Black_Water.mp3.
Audio file file format detected.
Clip info:
Title: Black Water
Artist: Watermelon Slim
Album: http://music.download.com
Year: 2007
Comment: http://music.download.com/
Track: 1
Genre: Unknown
==========================================================================
Forced audio codec: mad
Opening audio decoder: [libmad] libmad mpeg audio decoder
AUDIO: 44100 Hz, 2 ch, s16le, 192.0 kbit/13.61% (ratio: 24000->176400)
Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3)
==========================================================================
snd_pcm_open_file 2102 substream c7bdb900
success: snd_pcm_open 2168 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_INFO:snd_pcm_common_ioctl1 2517 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_INFO:snd_pcm_common_ioctl1 2517 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_PVERSION:snd_pcm_common_ioctl1 2514 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_TSTAMP:snd_pcm_common_ioctl1 2520 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_SYNC_PTR:snd_pcm_common_ioctl1 2571 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_HW_REFINE:snd_pcm_common_ioctl1 2526 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_HW_PARAMS:snd_pcm_common_ioctl1 2529 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_SYNC_PTR:snd_pcm_common_ioctl1 2571 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_SW_PARAMS:snd_pcm_common_ioctl1 2535 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_CHANNEL_INFO:snd_pcm_common_ioctl1 2541 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_CHANNEL_INFO:snd_pcm_common_ioctl1 2541 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_PREPARE:snd_pcm_common_ioctl1 2544 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_SYNC_PTR:snd_pcm_common_ioctl1 2571 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_SW_PARAMS:snd_pcm_common_ioctl1 2535 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_SYNC_PTR:snd_pcm_common_ioctl1 2571 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream c7bdb900
SNDRV_PCM_IOCTL_START:snd_pcm_common_ioctl1 2550 substream c7bdb900
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream 00000000
SNDRV_PCM_IOCTL_PVERSION:snd_pcm_common_ioctl1 2514 substream 00000000
OTHER (passing to snd_pcm_common_ioctl1):snd_pcm_playback_ioctl1 2682
substream 00000000
SNDRV_PCM_IOCTL_INFO:snd_pcm_common_ioctl1 2517 substream 00000000
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c6db8000
[00000000] *pgd=86d5e031, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1]
Modules linked in: ipv6 rtl8187 eeprom_93cx6
CPU: 0 Not tainted (2.6.27-rc3-omap1 #1)
PC is at snd_pcm_info+0xc/0xe0
LR is at snd_pcm_info_user+0x38/0x94
pc : [<c0256414>] lr : [<c0256520>] psr: a0000013
sp : c6ccdd98 ip : c6ccddb8 fp : c6ccddb4
r10: 00000001 r9 : c6ccc000 r8 : c002ce04
r7 : 00000000 r6 : 00000000 r5 : c7b85c00 r4 : bef36480
r3 : 00000001 r2 : 00000000 r1 : c7b85c00 r0 : 00000000
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 00c5387f Table: 86db8018 DAC: 00000015
Process mplayer (pid: 1719, stack limit = 0xc6ccc2e8)
Stack: (0xc6ccdd98 to 0xc6cce000)
dd80: bef36480 c7b85c00
dda0: 00000000 00000000 c6ccddd4 c6ccddb8 c0256520 c0256414 81204101 bef36480
ddc0: c6cca080 00000000 c6ccdefc c6ccddd8 c025783c c02564f4 00000025 c0430a98
dde0: c6ccde0c c6ccddf0 c002c04c c0051114 ffffffff d8200000 00000000 c6cca080
de00: c6ccded4 c6ccde10 c002c830 c002c00c c042e39c 000051cf 00000000 30000013
de20: c045252c bef36480 00000000 c6cca080 c03f8448 c0452588 00000000 c6ccded4
de40: c6ccde30 c6ccde58 c004cd4c c004d278 60000013 ffffffff c6c37480 00000006
de60: 30000013 0000005c c6ccde94 c6ccde78 c0083d8c c007e470 00000000 00000003
de80: 0000001f c6d79160 c6ccdedc c6ccde98 c008474c c0083cb0 00000000 00000000
dea0: c6c37480 c791a520 00000003 81204101 bef36480 00000000 c6cca080 c002ce04
dec0: c6ccc000 00000001 c6ccdeec c6ccded8 c004d2d0 81204101 bef36480 00000000
dee0: c6cca080 c002ce04 c6ccc000 00000001 c6ccdf2c c6ccdf00 c0258fe0 c025766c
df00: c6ccdf54 c6ccdf10 c00868dc c0085b78 81204101 bef36480 00000005 c6cca080
df20: c6ccdf3c c6ccdf30 c0259108 c0258b84 c6ccdf54 c6ccdf40 c00a5bb8 c02590e0
df40: c6cca080 bef36480 c6ccdf7c c6ccdf58 c00a5e6c c00a5b90 406b6000 00000096
df60: 00000005 bef36480 81204101 c6cca080 c6ccdfa4 c6ccdf80 c00a5ebc c00a5c08
df80: c0086b54 00000000 402c0444 007ee3b0 402c0444 00000036 00000000 c6ccdfa8
dfa0: c002cc80 c00a5e88 402c0444 007ee3b0 00000005 81204101 bef36480 007fbf10
dfc0: 402c0444 007ee3b0 402c0444 00000036 bef36480 00000016 00000001 bef3665c
dfe0: 007ee3b0 bef36458 4025a3d8 404c099c 20000010 00000005 00000000 00000000
Backtrace:
[<c0256408>] (snd_pcm_info+0x0/0xe0) from [<c0256520>]
(snd_pcm_info_user+0x38/0x94)
r7:00000000 r6:00000000 r5:c7b85c00 r4:bef36480
[<c02564e8>] (snd_pcm_info_user+0x0/0x94) from [<c025783c>]
(snd_pcm_common_ioctl1+0x1dc/0x10e4)
r7:00000000 r6:c6cca080 r5:bef36480 r4:81204101
[<c0257660>] (snd_pcm_common_ioctl1+0x0/0x10e4) from [<c0258fe0>]
(snd_pcm_playback_ioctl1+0x468/0x498)
[<c0258b78>] (snd_pcm_playback_ioctl1+0x0/0x498) from [<c0259108>]
(snd_pcm_playback_ioctl+0x34/0x38)
r7:c6cca080 r6:00000005 r5:bef36480 r4:81204101
[<c02590d4>] (snd_pcm_playback_ioctl+0x0/0x38) from [<c00a5bb8>]
(vfs_ioctl+0x34/0x78)
[<c00a5b84>] (vfs_ioctl+0x0/0x78) from [<c00a5e6c>] (do_vfs_ioctl+0x270/0x280)
r5:bef36480 r4:c6cca080
[<c00a5bfc>] (do_vfs_ioctl+0x0/0x280) from [<c00a5ebc>] (sys_ioctl+0x40/0x64)
r7:c6cca080 r6:81204101 r5:bef36480 r4:00000005
[<c00a5e7c>] (sys_ioctl+0x0/0x64) from [<c002cc80>] (ret_fast_syscall+0x0/0x2c)
r7:00000036 r6:402c0444 r5:007ee3b0 r4:402c0444
Code: e89da830 e1a0c00d e92dd8f0 e24cb004 (e5904000)
---[ end trace 720db3cd45410745 ]---
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 17 [#2]
Modules linked in: ipv6 rtl8187 eeprom_93cx6
CPU: 0 Tainted: G D (2.6.27-rc3-omap1 #1)
PC is at snd_pcm_release+0x20/0x88
LR is at __fput+0xb8/0x170
pc : [<c025590c>] lr : [<c009af68>] psr: a0000013
sp : c6ccdb60 ip : c6ccdb88 fp : c6ccdb84
r10: c79d8200 r9 : c6ccdd50 r8 : c6cca080
r7 : c6d9e2a8 r6 : c6cca080 r5 : c6c41ab0 r4 : 00000000
r3 : c02558ec r2 : 00000000 r1 : c6cca080 r0 : ffffffff
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 00c5387f Table: 86dbc018 DAC: 00000015
Process mplayer (pid: 1719, stack limit = 0xc6ccc2e8)
Stack: (0xc6ccdb60 to 0xc6cce000)
db60: 00000008 c6c41ab0 c6cca080 c7887788 c74eb980 c6ccdd50 c6ccdbb4 c6ccdb88
db80: c009af68 c02558f8 00000000 c6ccc000 c6cca080 00000000 c7887780 c7887788
dba0: 00000000 00000008 c6ccdbc4 c6ccdbb8 c009b2dc c009aebc c6ccdbe4 c6ccdbc8
dbc0: c009804c c009b2b8 c7887780 00000001 00000014 c7887788 c6ccdc0c c6ccdbe8
dbe0: c004de48 c0097fe4 c6ccc000 c791a520 0000000b c0256414 00000001 c6ccdd50
dc00: c6ccdc1c c6ccdc10 c004dec4 c004ddd0 c6ccdc34 c6ccdc20 c004f10c c004dea8
dc20: c004c458 c004c270 c6ccdc44 c6ccdc38 c0030864 c004ef0c c6ccdc64 c6ccdc48
dc40: c0031cf0 c00305cc 00010000 c6ca9b58 c791a520 c6c374b4 c6ccdca4 c6ccdc68
dc60: c0031f08 c0031c90 00000001 c0456944 0000000a 00000017 00000000 c0426850
dc80: 00000017 c6ccdd50 00000000 c002ce04 60000113 00000001 c6ccdd4c c6ccdca8
dca0: c002c1e8 c0031d0c c0051174 c00448d0 00000025 c0430a98 c6ccdce4 c6ccdcc8
dcc0: c002c04c c0051114 ffffffff d8200000 00000000 00000000 c6ccddac c6ccdce8
dce0: c002c830 c002c00c c042e39c 00005215 00000000 60000013 c045252c bef36480
dd00: 00000000 00000000 c03f7fe3 c0452572 00000000 c6ccddac c6ccdd08 c6ccdd30
dd20: c004cd4c c004d278 60000013 ffffffff ffffffff c6ccdd84 00000000 00000000
dd40: c6ccddb4 c6ccdd50 c002c7ec c002c1b8 00000000 c7b85c00 00000000 00000001
dd60: bef36480 c7b85c00 00000000 00000000 c002ce04 c6ccc000 00000001 c6ccddb4
dd80: c6ccddb8 c6ccdd98 c0256520 c0256414 a0000013 ffffffff bef36480 c7b85c00
dda0: 00000000 00000000 c6ccddd4 c6ccddb8 c0256520 c0256414 81204101 bef36480
ddc0: c6cca080 00000000 c6ccdefc c6ccddd8 c025783c c02564f4 00000025 c0430a98
dde0: c6ccde0c c6ccddf0 c002c04c c0051114 ffffffff d8200000 00000000 c6cca080
de00: c6ccded4 c6ccde10 c002c830 c002c00c c042e39c 000051cf 00000000 30000013
de20: c045252c bef36480 00000000 c6cca080 c03f8448 c0452588 00000000 c6ccded4
de40: c6ccde30 c6ccde58 c004cd4c c004d278 60000013 ffffffff c6c37480 00000006
de60: 30000013 0000005c c6ccde94 c6ccde78 c0083d8c c007e470 00000000 00000003
de80: 0000001f c6d79160 c6ccdedc c6ccde98 c008474c c0083cb0 00000000 00000000
dea0: c6c37480 c791a520 00000003 81204101 bef36480 00000000 c6cca080 c002ce04
dec0: c6ccc000 00000001 c6ccdeec c6ccded8 c004d2d0 81204101 bef36480 00000000
dee0: c6cca080 c002ce04 c6ccc000 00000001 c6ccdf2c c6ccdf00 c0258fe0 c025766c
df00: c6ccdf54 c6ccdf10 c00868dc c0085b78 81204101 bef36480 00000005 c6cca080
df20: c6ccdf3c c6ccdf30 c0259108 c0258b84 c6ccdf54 c6ccdf40 c00a5bb8 c02590e0
df40: c6cca080 bef36480 c6ccdf7c c6ccdf58 c00a5e6c c00a5b90 406b6000 00000096
df60: 00000005 bef36480 81204101 c6cca080 c6ccdfa4 c6ccdf80 c00a5ebc c00a5c08
df80: c0086b54 00000000 402c0444 007ee3b0 402c0444 00000036 00000000 c6ccdfa8
dfa0: c002cc80 c00a5e88 402c0444 007ee3b0 00000005 81204101 bef36480 007fbf10
dfc0: 402c0444 007ee3b0 402c0444 00000036 bef36480 00000016 00000001 bef3665c
dfe0: 007ee3b0 bef36458 4025a3d8 404c099c 20000010 00000005 00000000 00000000
Backtrace:
[<c02558ec>] (snd_pcm_release+0x0/0x88) from [<c009af68>] (__fput+0xb8/0x170)
r9:c6ccdd50 r8:c74eb980 r7:c7887788 r6:c6cca080 r5:c6c41ab0
r4:00000008
[<c009aeb0>] (__fput+0x0/0x170) from [<c009b2dc>] (fput+0x30/0x34)
[<c009b2ac>] (fput+0x0/0x34) from [<c009804c>] (filp_close+0x74/0x80)
[<c0097fd8>] (filp_close+0x0/0x80) from [<c004de48>]
(put_files_struct+0x84/0xd8)
r7:c7887788 r6:00000014 r5:00000001 r4:c7887780
[<c004ddc4>] (put_files_struct+0x0/0xd8) from [<c004dec4>]
(exit_files+0x28/0x2c)
r9:c6ccdd50 r8:00000001 r7:c0256414 r6:0000000b r5:c791a520
r4:c6ccc000
[<c004de9c>] (exit_files+0x0/0x2c) from [<c004f10c>] (do_exit+0x20c/0x6e8)
[<c004ef00>] (do_exit+0x0/0x6e8) from [<c0030864>] (die+0x2a4/0x300)
[<c00305c0>] (die+0x0/0x300) from [<c0031cf0>] (__do_kernel_fault+0x6c/0x7c)
[<c0031c84>] (__do_kernel_fault+0x0/0x7c) from [<c0031f08>]
(do_page_fault+0x208/0x224)
r7:c6c374b4 r6:c791a520 r5:c6ca9b58 r4:00010000
[<c0031d00>] (do_page_fault+0x0/0x224) from [<c002c1e8>]
(do_DataAbort+0x3c/0x9c)
[<c002c1ac>] (do_DataAbort+0x0/0x9c) from [<c002c7ec>] (__dabt_svc+0x4c/0x60)
Exception stack(0xc6ccdd50 to 0xc6ccdd98)
dd40: 00000000 c7b85c00 00000000 00000001
dd60: bef36480 c7b85c00 00000000 00000000 c002ce04 c6ccc000 00000001 c6ccddb4
dd80: c6ccddb8 c6ccdd98 c0256520 c0256414 a0000013 ffffffff
r7:00000000 r6:00000000 r5:c6ccdd84 r4:ffffffff
[<c0256408>] (snd_pcm_info+0x0/0xe0) from [<c0256520>]
(snd_pcm_info_user+0x38/0x94)
r7:00000000 r6:00000000 r5:c7b85c00 r4:bef36480
[<c02564e8>] (snd_pcm_info_user+0x0/0x94) from [<c025783c>]
(snd_pcm_common_ioctl1+0x1dc/0x10e4)
r7:00000000 r6:c6cca080 r5:bef36480 r4:81204101
[<c0257660>] (snd_pcm_common_ioctl1+0x0/0x10e4) from [<c0258fe0>]
(snd_pcm_playback_ioctl1+0x468/0x498)
[<c0258b78>] (snd_pcm_playback_ioctl1+0x0/0x498) from [<c0259108>]
(snd_pcm_playback_ioctl+0x34/0x38)
r7:c6cca080 r6:00000005 r5:bef36480 r4:81204101
[<c02590d4>] (snd_pcm_playback_ioctl+0x0/0x38) from [<c00a5bb8>]
(vfs_ioctl+0x34/0x78)
[<c00a5b84>] (vfs_ioctl+0x0/0x78) from [<c00a5e6c>] (do_vfs_ioctl+0x270/0x280)
r5:bef36480 r4:c6cca080
[<c00a5bfc>] (do_vfs_ioctl+0x0/0x280) from [<c00a5ebc>] (sys_ioctl+0x40/0x64)
r7:c6cca080 r6:81204101 r5:bef36480 r4:00000005
[<c00a5e7c>] (sys_ioctl+0x0/0x64) from [<c002cc80>] (ret_fast_syscall+0x0/0x2c)
r7:00000036 r6:402c0444 r5:007ee3b0 r4:402c0444
Code: e3a02000 e3e00000 e5974000 e1a08001 (e5945000)
---[ end trace 720db3cd45410745 ]---
Fixing recursive fault but reboot is needed!
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-26 17:18 ` Steve Sakoman
@ 2008-08-27 6:38 ` Jarkko Nikula
2008-08-27 13:39 ` Steve Sakoman
0 siblings, 1 reply; 40+ messages in thread
From: Jarkko Nikula @ 2008-08-27 6:38 UTC (permalink / raw)
To: ext Steve Sakoman; +Cc: Felipe Balbi, linux-omap@vger.kernel.org
On Tue, 26 Aug 2008 10:18:56 -0700
"ext Steve Sakoman" <sakoman@gmail.com> wrote:
> > Sounds indeed strange. Can you track is the pcm_file->substream
> > getting zeroed somewhere after it is set in snd_pcm_open_file? Like
> > printing both address of pcm_file and pcm_file->substream.
>
> I don't believe that it is the SNDRV_PCM_IOCTL_START that writes a
> null in substream, so it is likely something in alsa-lib :-(
>
One thing came to my mind that does your kernel and user space (E)ABI
match? I rememeber that there were some strange IOCTL related errors
with ALSA mixers if the kernel was compiled with CONFIG_EABI and
CONFIG_OABI_COMPAT but Debian was using legacy ABI.
> It isn't confidence inspiring to see comments like /* AB: FIXME!!!
> This is definitely nonsense */ in snd_pcm_info (the function where it
> finally crashes)
>
Heh, that's true.
Jarkko
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-27 6:38 ` Jarkko Nikula
@ 2008-08-27 13:39 ` Steve Sakoman
2008-08-27 20:57 ` Steve Sakoman
0 siblings, 1 reply; 40+ messages in thread
From: Steve Sakoman @ 2008-08-27 13:39 UTC (permalink / raw)
To: Jarkko Nikula; +Cc: Felipe Balbi, linux-omap@vger.kernel.org
> One thing came to my mind that does your kernel and user space (E)ABI
> match? I rememeber that there were some strange IOCTL related errors
> with ALSA mixers if the kernel was compiled with CONFIG_EABI and
> CONFIG_OABI_COMPAT but Debian was using legacy ABI.
Both kernel and user space are EABI.
I received some new hw to bring up yesterday, so I wasn't able to get
much further on debugging this. But I did verify that running
'mplayer song.mp3' first before using 'mplayer -ao alsa song.mp3'
resulted in an ioctl trace where substream did *not* go NULL after the
START ioctl. Very strange!
Hope to get back to it later today if I can finish bringing up the new hw.
Steve
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-27 13:39 ` Steve Sakoman
@ 2008-08-27 20:57 ` Steve Sakoman
2008-08-27 21:25 ` Koen Kooi
2008-08-28 11:03 ` Jarkko Nikula
0 siblings, 2 replies; 40+ messages in thread
From: Steve Sakoman @ 2008-08-27 20:57 UTC (permalink / raw)
To: Jarkko Nikula; +Cc: Felipe Balbi, linux-omap@vger.kernel.org
> Hope to get back to it later today if I can finish bringing up the new hw.
Had a few moments to look at this while waiting for a build.
This set of ioctl's are called at the failure point:
SNDRV_PCM_IOCTL_START:snd_pcm_common_ioctl1 2550 substream c7bdb900
SNDRV_PCM_IOCTL_PVERSION:snd_pcm_common_ioctl1 2514 substream 00000000
SNDRV_PCM_IOCTL_INFO:snd_pcm_common_ioctl1 2517 substream 00000000
Unable to handle kernel NULL pointer dereference at virtual address 00000000
So substream goes null sometime after the SNDRV_PCM_IOCTL_START but
before SNDRV_PCM_IOCTL_PVERSION . I believe that those calls are
generated by the following code in alsa-lib's
snd_pcm_direct_initialize_slave function in src/pcm/pcm_direct.c:
ret = snd_pcm_start(spcm); <=== THIS ROUTINE GENERATES A
SNDRV_PCM_IOCTL_START IOCTL
if (ret < 0) {
SNDERR("unable to start PCM stream");
return ret;
}
if (snd_pcm_poll_descriptors_count(spcm) != 1) {
SNDERR("unable to use hardware pcm with fd more than one!!!");
return ret;
}
snd_pcm_poll_descriptors(spcm, &fd, 1);
dmix->hw_fd = fd.fd;
save_slave_setting(dmix, spcm);
/* Currently, we assume that each dmix client has the same
* hw_params setting.
* If the arbitrary hw_parmas is supported in future,
* boundary has to be taken from the slave config but
* recalculated for the native boundary size (for 32bit
* emulation on 64bit arch).
*/
dmix->slave_buffer_size = spcm->buffer_size;
dmix->slave_period_size = spcm->period_size;
dmix->slave_boundary = spcm->boundary;
spcm->donot_close = 1;
{
int ver = 0;
ioctl(spcm->poll_fd, SNDRV_PCM_IOCTL_PVERSION, &ver); <=== THIS IS
THE FIRST POINT OF NULL SUBSTREAM
if (ver < SNDRV_PROTOCOL_VERSION(2, 0, 8))
dmix->shmptr->use_server = 1;
}
So this seems to narrow the area to search quite considerably! Back
to hw bringup . . .
Steve
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-27 20:57 ` Steve Sakoman
@ 2008-08-27 21:25 ` Koen Kooi
2008-08-27 22:14 ` Steve Sakoman
2008-08-28 11:03 ` Jarkko Nikula
1 sibling, 1 reply; 40+ messages in thread
From: Koen Kooi @ 2008-08-27 21:25 UTC (permalink / raw)
To: Steve Sakoman; +Cc: Jarkko Nikula, Felipe Balbi, linux-omap@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 2387 bytes --]
Op 27 aug 2008, om 22:57 heeft Steve Sakoman het volgende geschreven:
>> Hope to get back to it later today if I can finish bringing up the
>> new hw.
>
> Had a few moments to look at this while waiting for a build.
>
> This set of ioctl's are called at the failure point:
>
> SNDRV_PCM_IOCTL_START:snd_pcm_common_ioctl1 2550 substream c7bdb900
>
> SNDRV_PCM_IOCTL_PVERSION:snd_pcm_common_ioctl1 2514 substream 00000000
>
> SNDRV_PCM_IOCTL_INFO:snd_pcm_common_ioctl1 2517 substream 00000000
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 00000000
>
>
> So substream goes null sometime after the SNDRV_PCM_IOCTL_START but
> before SNDRV_PCM_IOCTL_PVERSION . I believe that those calls are
> generated by the following code in alsa-lib's
> snd_pcm_direct_initialize_slave function in src/pcm/pcm_direct.c:
>
> ret = snd_pcm_start(spcm); <=== THIS ROUTINE GENERATES A
> SNDRV_PCM_IOCTL_START IOCTL
> if (ret < 0) {
> SNDERR("unable to start PCM stream");
> return ret;
> }
>
> if (snd_pcm_poll_descriptors_count(spcm) != 1) {
> SNDERR("unable to use hardware pcm with fd more than one!!!");
> return ret;
> }
> snd_pcm_poll_descriptors(spcm, &fd, 1);
> dmix->hw_fd = fd.fd;
>
> save_slave_setting(dmix, spcm);
>
> /* Currently, we assume that each dmix client has the same
> * hw_params setting.
> * If the arbitrary hw_parmas is supported in future,
> * boundary has to be taken from the slave config but
> * recalculated for the native boundary size (for 32bit
> * emulation on 64bit arch).
> */
> dmix->slave_buffer_size = spcm->buffer_size;
> dmix->slave_period_size = spcm->period_size;
> dmix->slave_boundary = spcm->boundary;
>
> spcm->donot_close = 1;
>
> {
> int ver = 0;
> ioctl(spcm->poll_fd, SNDRV_PCM_IOCTL_PVERSION, &ver); <=== THIS IS
> THE FIRST POINT OF NULL SUBSTREAM
> if (ver < SNDRV_PROTOCOL_VERSION(2, 0, 8))
> dmix->shmptr->use_server = 1;
> }
>
>
> So this seems to narrow the area to search quite considerably! Back
> to hw bringup . . .
could you try removing /etc/asound.conf, it is set to dmix by
default, which might screw things up.
regards,
Koen
>
>
> Steve
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-27 20:57 ` Steve Sakoman
2008-08-27 21:25 ` Koen Kooi
@ 2008-08-28 11:03 ` Jarkko Nikula
1 sibling, 0 replies; 40+ messages in thread
From: Jarkko Nikula @ 2008-08-28 11:03 UTC (permalink / raw)
To: ext Steve Sakoman; +Cc: Felipe Balbi, linux-omap@vger.kernel.org
On Wed, 27 Aug 2008 13:57:36 -0700
"ext Steve Sakoman" <sakoman@gmail.com> wrote:
> So substream goes null sometime after the SNDRV_PCM_IOCTL_START but
> before SNDRV_PCM_IOCTL_PVERSION . I believe that those calls are
> generated by the following code in alsa-lib's
> snd_pcm_direct_initialize_slave function in src/pcm/pcm_direct.c:
>
It's also worth to check are there other fields than substream which get
zeroed in pcm_file structure. I don't know does it help but worth to
check probably.
Jarkko
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-21 11:55 [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx Jarkko Nikula
` (2 preceding siblings ...)
2008-08-21 21:51 ` [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx Steve Sakoman
@ 2008-08-23 11:32 ` Arun KS
2008-09-05 1:12 ` Tony Lindgren
4 siblings, 0 replies; 40+ messages in thread
From: Arun KS @ 2008-08-23 11:32 UTC (permalink / raw)
To: Jarkko Nikula; +Cc: linux-omap
Hi Jarkko,
I applied your patch manually on the latest omap-git and tested ASOC
driver on omap2evm board with tlv320aic34 codec. It works fine.
omap2evm is based on omap2430.
Best Regards,
Arun KS
On Thu, Aug 21, 2008 at 5:25 PM, Jarkko Nikula <jarkko.nikula@nokia.com> wrote:
> Here are two patches adding support for OMAP2430 in McBSP driver and
> adding support for 2430 and 34xx in ASoC OMAP McBSP DAI driver.
>
> These are generated from top of currect l-o head but they apply also on
> top of Hiroshi's virtual clock patches with some offsets.
>
> If you have change to try them out on those CPUs, I would be happy to
> hear. I've tested these only on N810. Second patch will naturally go
> through the alsa-devel when we have necessary McBSP patches upstream.
>
> --
> Jarkko
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-08-21 11:55 [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx Jarkko Nikula
` (3 preceding siblings ...)
2008-08-23 11:32 ` Arun KS
@ 2008-09-05 1:12 ` Tony Lindgren
2008-09-05 6:18 ` Steve Sakoman
4 siblings, 1 reply; 40+ messages in thread
From: Tony Lindgren @ 2008-09-05 1:12 UTC (permalink / raw)
To: Jarkko Nikula; +Cc: linux-omap
* Jarkko Nikula <jarkko.nikula@nokia.com> [080821 04:58]:
> Here are two patches adding support for OMAP2430 in McBSP driver and
> adding support for 2430 and 34xx in ASoC OMAP McBSP DAI driver.
>
> These are generated from top of currect l-o head but they apply also on
> top of Hiroshi's virtual clock patches with some offsets.
>
> If you have change to try them out on those CPUs, I would be happy to
> hear. I've tested these only on N810. Second patch will naturally go
> through the alsa-devel when we have necessary McBSP patches upstream.
Can you please refresh these against the current l-o head?
Thanks,
Tony
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-09-05 1:12 ` Tony Lindgren
@ 2008-09-05 6:18 ` Steve Sakoman
2008-09-05 16:56 ` Tony Lindgren
2008-09-20 11:22 ` [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx Arun KS
0 siblings, 2 replies; 40+ messages in thread
From: Steve Sakoman @ 2008-09-05 6:18 UTC (permalink / raw)
To: Tony Lindgren, linux-omap@vger.kernel.org
On Thu, Sep 4, 2008 at 6:12 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Jarkko Nikula <jarkko.nikula@nokia.com> [080821 04:58]:
>> Here are two patches adding support for OMAP2430 in McBSP driver and
>> adding support for 2430 and 34xx in ASoC OMAP McBSP DAI driver.
>>
>> These are generated from top of currect l-o head but they apply also on
>> top of Hiroshi's virtual clock patches with some offsets.
>>
>> If you have change to try them out on those CPUs, I would be happy to
>> hear. I've tested these only on N810. Second patch will naturally go
>> through the alsa-devel when we have necessary McBSP patches upstream.
>
> Can you please refresh these against the current l-o head?
I've been testing these patches along with my Overo patches on the
current l-o head. Audio is working fine, so the mcbsp changes haven't
broken anything.
I do miss having functional USB though :-)
Steve
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-09-05 6:18 ` Steve Sakoman
@ 2008-09-05 16:56 ` Tony Lindgren
2008-09-05 17:23 ` Steve Sakoman
` (3 more replies)
2008-09-20 11:22 ` [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx Arun KS
1 sibling, 4 replies; 40+ messages in thread
From: Tony Lindgren @ 2008-09-05 16:56 UTC (permalink / raw)
To: Steve Sakoman; +Cc: linux-omap@vger.kernel.org
* Steve Sakoman <sakoman@gmail.com> [080904 23:36]:
> On Thu, Sep 4, 2008 at 6:12 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Jarkko Nikula <jarkko.nikula@nokia.com> [080821 04:58]:
> >> Here are two patches adding support for OMAP2430 in McBSP driver and
> >> adding support for 2430 and 34xx in ASoC OMAP McBSP DAI driver.
> >>
> >> These are generated from top of currect l-o head but they apply also on
> >> top of Hiroshi's virtual clock patches with some offsets.
> >>
> >> If you have change to try them out on those CPUs, I would be happy to
> >> hear. I've tested these only on N810. Second patch will naturally go
> >> through the alsa-devel when we have necessary McBSP patches upstream.
> >
> > Can you please refresh these against the current l-o head?
>
> I've been testing these patches along with my Overo patches on the
> current l-o head. Audio is working fine, so the mcbsp changes haven't
> broken anything.
At least the first patch needs to be updated for phys_pbase instead of
virt_base.
> I do miss having functional USB though :-)
Hmm, is the musb broken now?
Tony
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-09-05 16:56 ` Tony Lindgren
@ 2008-09-05 17:23 ` Steve Sakoman
2008-09-05 17:52 ` Tony Lindgren
2008-09-08 10:29 ` [RFC 0/2 rev2] " Jarkko Nikula
` (2 subsequent siblings)
3 siblings, 1 reply; 40+ messages in thread
From: Steve Sakoman @ 2008-09-05 17:23 UTC (permalink / raw)
To: Tony Lindgren, linux-omap@vger.kernel.org
> At least the first patch needs to be updated for phys_pbase instead of
> virt_base.
Yes it does, mcbsp is likely still working by the same accident of fate.
> Hmm, is the musb broken now?
It is on Overo if I base my patches against current top of tree
(a376251519ced5831ed07ed234430725230ed93a)
Doesn't crash, just quietly doesn't work. I hear from Beagle folk
that musb doesn't work there either. I have it configured as a host
port, and IIRC so do the Beagle folks
If I base my patches against the state of the tree just prior to the
move to rc5 (81c893795c2e1fbe0bf5f638ed6ae1e500b80a2d), musb works as
well as it ever has.
Steve
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-09-05 17:23 ` Steve Sakoman
@ 2008-09-05 17:52 ` Tony Lindgren
0 siblings, 0 replies; 40+ messages in thread
From: Tony Lindgren @ 2008-09-05 17:52 UTC (permalink / raw)
To: Steve Sakoman; +Cc: linux-omap@vger.kernel.org
* Steve Sakoman <sakoman@gmail.com> [080905 10:24]:
> > At least the first patch needs to be updated for phys_pbase instead of
> > virt_base.
>
> Yes it does, mcbsp is likely still working by the same accident of fate.
>
> > Hmm, is the musb broken now?
>
> It is on Overo if I base my patches against current top of tree
> (a376251519ced5831ed07ed234430725230ed93a)
>
> Doesn't crash, just quietly doesn't work. I hear from Beagle folk
> that musb doesn't work there either. I have it configured as a host
> port, and IIRC so do the Beagle folks
>
> If I base my patches against the state of the tree just prior to the
> move to rc5 (81c893795c2e1fbe0bf5f638ed6ae1e500b80a2d), musb works as
> well as it ever has.
Well with -rc5 we switched to the drivers/usb/musb code from mainline
kernel. Maybe try to diff musb code with:
$ git-diff 81c893795c2e1fbe0bf5f638ed6ae1e500b80a2d.. drivers/usb/musb
And see if there are any clues?
Tony
^ permalink raw reply [flat|nested] 40+ messages in thread
* [RFC 0/2 rev2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-09-05 16:56 ` Tony Lindgren
2008-09-05 17:23 ` Steve Sakoman
@ 2008-09-08 10:29 ` Jarkko Nikula
2008-09-09 0:48 ` Tony Lindgren
2008-09-08 10:29 ` [RFC rev2] ARM: OMAP: Add support for OMAP2430 in McBSP Jarkko Nikula
2008-09-08 10:29 ` [RFC rev2] ASoC: OMAP: Add support for OMAP2430 and OMAP34xx in McBSP DAI driver Jarkko Nikula
3 siblings, 1 reply; 40+ messages in thread
From: Jarkko Nikula @ 2008-09-08 10:29 UTC (permalink / raw)
To: linux-omap
Here is second version of patch adding support for 2430 in McBSP driver.
Updated version uses phys_base instead of virt_base. See following commits from Russell King:
ecec3b3e080464cc1b4e792cf4d8e7e89d50b011
2cfd6fcda3b8c6ee7a5fa9a4573e3246532a0716
Second patch is the same than first version. It's for testing ASoC OMAP
and eventually it will go through the alsa-devel.
--
Jarkko
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2 rev2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-09-08 10:29 ` [RFC 0/2 rev2] " Jarkko Nikula
@ 2008-09-09 0:48 ` Tony Lindgren
0 siblings, 0 replies; 40+ messages in thread
From: Tony Lindgren @ 2008-09-09 0:48 UTC (permalink / raw)
To: Jarkko Nikula; +Cc: linux-omap
* Jarkko Nikula <jarkko.nikula@nokia.com> [080908 03:30]:
> Here is second version of patch adding support for 2430 in McBSP driver.
> Updated version uses phys_base instead of virt_base. See following commits from Russell King:
>
> ecec3b3e080464cc1b4e792cf4d8e7e89d50b011
> 2cfd6fcda3b8c6ee7a5fa9a4573e3246532a0716
>
> Second patch is the same than first version. It's for testing ASoC OMAP
> and eventually it will go through the alsa-devel.
Thanks, pushing these to l-o tree.
Tony
^ permalink raw reply [flat|nested] 40+ messages in thread
* [RFC rev2] ARM: OMAP: Add support for OMAP2430 in McBSP
2008-09-05 16:56 ` Tony Lindgren
2008-09-05 17:23 ` Steve Sakoman
2008-09-08 10:29 ` [RFC 0/2 rev2] " Jarkko Nikula
@ 2008-09-08 10:29 ` Jarkko Nikula
2008-09-08 10:29 ` [RFC rev2] ASoC: OMAP: Add support for OMAP2430 and OMAP34xx in McBSP DAI driver Jarkko Nikula
3 siblings, 0 replies; 40+ messages in thread
From: Jarkko Nikula @ 2008-09-08 10:29 UTC (permalink / raw)
To: linux-omap; +Cc: Jarkko Nikula
Signed-off-by: Jarkko Nikula <jarkko.nikula@nokia.com>
---
arch/arm/mach-omap2/mcbsp.c | 73 ++++++++++++++++++++++++++----
arch/arm/plat-omap/include/mach/mcbsp.h | 3 +
2 files changed, 66 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 7addc5a..afbe1e6 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -145,8 +145,8 @@ static struct omap_mcbsp_ops omap2_mcbsp_ops = {
.request = omap2_mcbsp_request,
};
-#ifdef CONFIG_ARCH_OMAP24XX
-static struct omap_mcbsp_platform_data omap24xx_mcbsp_pdata[] = {
+#ifdef CONFIG_ARCH_OMAP2420
+static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[] = {
{
.phys_base = OMAP24XX_MCBSP1_BASE,
.dma_rx_sync = OMAP24XX_DMA_MCBSP1_RX,
@@ -166,10 +166,58 @@ static struct omap_mcbsp_platform_data omap24xx_mcbsp_pdata[] = {
.clk_name = "mcbsp_clk",
},
};
-#define OMAP24XX_MCBSP_PDATA_SZ ARRAY_SIZE(omap24xx_mcbsp_pdata)
+#define OMAP2420_MCBSP_PDATA_SZ ARRAY_SIZE(omap2420_mcbsp_pdata)
#else
-#define omap24xx_mcbsp_pdata NULL
-#define OMAP24XX_MCBSP_PDATA_SZ 0
+#define omap2420_mcbsp_pdata NULL
+#define OMAP2420_MCBSP_PDATA_SZ 0
+#endif
+
+#ifdef CONFIG_ARCH_OMAP2430
+static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[] = {
+ {
+ .phys_base = OMAP24XX_MCBSP1_BASE,
+ .dma_rx_sync = OMAP24XX_DMA_MCBSP1_RX,
+ .dma_tx_sync = OMAP24XX_DMA_MCBSP1_TX,
+ .rx_irq = INT_24XX_MCBSP1_IRQ_RX,
+ .tx_irq = INT_24XX_MCBSP1_IRQ_TX,
+ .ops = &omap2_mcbsp_ops,
+ .clk_name = "mcbsp_clk",
+ },
+ {
+ .phys_base = OMAP24XX_MCBSP2_BASE,
+ .dma_rx_sync = OMAP24XX_DMA_MCBSP2_RX,
+ .dma_tx_sync = OMAP24XX_DMA_MCBSP2_TX,
+ .rx_irq = INT_24XX_MCBSP2_IRQ_RX,
+ .tx_irq = INT_24XX_MCBSP2_IRQ_TX,
+ .ops = &omap2_mcbsp_ops,
+ .clk_name = "mcbsp_clk",
+ },
+ {
+ .phys_base = OMAP2430_MCBSP3_BASE,
+ .dma_rx_sync = OMAP24XX_DMA_MCBSP3_RX,
+ .dma_tx_sync = OMAP24XX_DMA_MCBSP3_TX,
+ .ops = &omap2_mcbsp_ops,
+ .clk_name = "mcbsp_clk",
+ },
+ {
+ .phys_base = OMAP2430_MCBSP4_BASE,
+ .dma_rx_sync = OMAP24XX_DMA_MCBSP4_RX,
+ .dma_tx_sync = OMAP24XX_DMA_MCBSP4_TX,
+ .ops = &omap2_mcbsp_ops,
+ .clk_name = "mcbsp_clk",
+ },
+ {
+ .phys_base = OMAP2430_MCBSP5_BASE,
+ .dma_rx_sync = OMAP24XX_DMA_MCBSP5_RX,
+ .dma_tx_sync = OMAP24XX_DMA_MCBSP5_TX,
+ .ops = &omap2_mcbsp_ops,
+ .clk_name = "mcbsp_clk",
+ },
+};
+#define OMAP2430_MCBSP_PDATA_SZ ARRAY_SIZE(omap2430_mcbsp_pdata)
+#else
+#define omap2430_mcbsp_pdata NULL
+#define OMAP2430_MCBSP_PDATA_SZ 0
#endif
#ifdef CONFIG_ARCH_OMAP34XX
@@ -230,8 +278,10 @@ static int __init omap2_mcbsp_init(void)
clk_register(&omap_mcbsp_clks[i].clk);
}
- if (cpu_is_omap24xx())
- omap_mcbsp_count = OMAP24XX_MCBSP_PDATA_SZ;
+ if (cpu_is_omap2420())
+ omap_mcbsp_count = OMAP2420_MCBSP_PDATA_SZ;
+ if (cpu_is_omap2430())
+ omap_mcbsp_count = OMAP2430_MCBSP_PDATA_SZ;
if (cpu_is_omap34xx())
omap_mcbsp_count = OMAP34XX_MCBSP_PDATA_SZ;
@@ -240,9 +290,12 @@ static int __init omap2_mcbsp_init(void)
if (!mcbsp_ptr)
return -ENOMEM;
- if (cpu_is_omap24xx())
- omap_mcbsp_register_board_cfg(omap24xx_mcbsp_pdata,
- OMAP24XX_MCBSP_PDATA_SZ);
+ if (cpu_is_omap2420())
+ omap_mcbsp_register_board_cfg(omap2420_mcbsp_pdata,
+ OMAP2420_MCBSP_PDATA_SZ);
+ if (cpu_is_omap2430())
+ omap_mcbsp_register_board_cfg(omap2430_mcbsp_pdata,
+ OMAP2430_MCBSP_PDATA_SZ);
if (cpu_is_omap34xx())
omap_mcbsp_register_board_cfg(omap34xx_mcbsp_pdata,
OMAP34XX_MCBSP_PDATA_SZ);
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h
index f4e7980..6a0d1a0 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -43,6 +43,9 @@
#define OMAP24XX_MCBSP1_BASE 0x48074000
#define OMAP24XX_MCBSP2_BASE 0x48076000
+#define OMAP2430_MCBSP3_BASE 0x4808c000
+#define OMAP2430_MCBSP4_BASE 0x4808e000
+#define OMAP2430_MCBSP5_BASE 0x48096000
#define OMAP34XX_MCBSP1_BASE 0x48074000
#define OMAP34XX_MCBSP2_BASE 0x49022000
--
1.5.6.5
^ permalink raw reply related [flat|nested] 40+ messages in thread* [RFC rev2] ASoC: OMAP: Add support for OMAP2430 and OMAP34xx in McBSP DAI driver
2008-09-05 16:56 ` Tony Lindgren
` (2 preceding siblings ...)
2008-09-08 10:29 ` [RFC rev2] ARM: OMAP: Add support for OMAP2430 in McBSP Jarkko Nikula
@ 2008-09-08 10:29 ` Jarkko Nikula
3 siblings, 0 replies; 40+ messages in thread
From: Jarkko Nikula @ 2008-09-08 10:29 UTC (permalink / raw)
To: linux-omap; +Cc: Jarkko Nikula
Signed-off-by: Jarkko Nikula <jarkko.nikula@nokia.com>
---
sound/soc/omap/omap-mcbsp.c | 95 ++++++++++++++++++++++++++++++++++--------
1 files changed, 77 insertions(+), 18 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 35310e1..a217cf2 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -84,11 +84,22 @@ static const unsigned long omap1_mcbsp_port[][2] = {
static const int omap1_dma_reqs[][2] = {};
static const unsigned long omap1_mcbsp_port[][2] = {};
#endif
-#if defined(CONFIG_ARCH_OMAP2420)
-static const int omap2420_dma_reqs[][2] = {
+
+#if defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
+static const int omap24xx_dma_reqs[][2] = {
{ OMAP24XX_DMA_MCBSP1_TX, OMAP24XX_DMA_MCBSP1_RX },
{ OMAP24XX_DMA_MCBSP2_TX, OMAP24XX_DMA_MCBSP2_RX },
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
+ { OMAP24XX_DMA_MCBSP3_TX, OMAP24XX_DMA_MCBSP3_RX },
+ { OMAP24XX_DMA_MCBSP4_TX, OMAP24XX_DMA_MCBSP4_RX },
+ { OMAP24XX_DMA_MCBSP5_TX, OMAP24XX_DMA_MCBSP5_RX },
+#endif
};
+#else
+static const int omap2420_dma_reqs[][2] = {};
+#endif
+
+#if defined(CONFIG_ARCH_OMAP2420)
static const unsigned long omap2420_mcbsp_port[][2] = {
{ OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR1,
OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR1 },
@@ -96,10 +107,43 @@ static const unsigned long omap2420_mcbsp_port[][2] = {
OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR1 },
};
#else
-static const int omap2420_dma_reqs[][2] = {};
static const unsigned long omap2420_mcbsp_port[][2] = {};
#endif
+#if defined(CONFIG_ARCH_OMAP2430)
+static const unsigned long omap2430_mcbsp_port[][2] = {
+ { OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP2430_MCBSP3_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP2430_MCBSP3_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP2430_MCBSP4_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP2430_MCBSP4_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP2430_MCBSP5_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP2430_MCBSP5_BASE + OMAP_MCBSP_REG_DRR },
+};
+#else
+static const unsigned long omap2430_mcbsp_port[][2] = {};
+#endif
+
+#if defined(CONFIG_ARCH_OMAP34XX)
+static const unsigned long omap34xx_mcbsp_port[][2] = {
+ { OMAP34XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP34XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP34XX_MCBSP3_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP3_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP34XX_MCBSP4_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP4_BASE + OMAP_MCBSP_REG_DRR },
+ { OMAP34XX_MCBSP5_BASE + OMAP_MCBSP_REG_DXR,
+ OMAP34XX_MCBSP5_BASE + OMAP_MCBSP_REG_DRR },
+};
+#else
+static const unsigned long omap34xx_mcbsp_port[][2] = {};
+#endif
+
static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream)
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
@@ -167,12 +211,15 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream,
dma = omap1_dma_reqs[bus_id][substream->stream];
port = omap1_mcbsp_port[bus_id][substream->stream];
} else if (cpu_is_omap2420()) {
- dma = omap2420_dma_reqs[bus_id][substream->stream];
+ dma = omap24xx_dma_reqs[bus_id][substream->stream];
port = omap2420_mcbsp_port[bus_id][substream->stream];
+ } else if (cpu_is_omap2430()) {
+ dma = omap24xx_dma_reqs[bus_id][substream->stream];
+ port = omap2430_mcbsp_port[bus_id][substream->stream];
+ } else if (cpu_is_omap343x()) {
+ dma = omap24xx_dma_reqs[bus_id][substream->stream];
+ port = omap34xx_mcbsp_port[bus_id][substream->stream];
} else {
- /*
- * TODO: Add support for 2430 and 3430
- */
return -ENODEV;
}
omap_mcbsp_dai_dma_params[id][substream->stream].dma_req = dma;
@@ -310,7 +357,7 @@ static int omap_mcbsp_dai_set_clks_src(struct omap_mcbsp_data *mcbsp_data,
int clk_id)
{
int sel_bit;
- u16 reg;
+ u16 reg, reg_devconf1 = OMAP243X_CONTROL_DEVCONF1;
if (cpu_class_is_omap1()) {
/* OMAP1's can use only external source clock */
@@ -320,6 +367,12 @@ static int omap_mcbsp_dai_set_clks_src(struct omap_mcbsp_data *mcbsp_data,
return 0;
}
+ if (cpu_is_omap2420() && mcbsp_data->bus_id > 1)
+ return -EINVAL;
+
+ if (cpu_is_omap343x())
+ reg_devconf1 = OMAP343X_CONTROL_DEVCONF1;
+
switch (mcbsp_data->bus_id) {
case 0:
reg = OMAP2_CONTROL_DEVCONF0;
@@ -329,20 +382,26 @@ static int omap_mcbsp_dai_set_clks_src(struct omap_mcbsp_data *mcbsp_data,
reg = OMAP2_CONTROL_DEVCONF0;
sel_bit = 6;
break;
- /* TODO: Support for ports 3 - 5 in OMAP2430 and OMAP34xx */
+ case 2:
+ reg = reg_devconf1;
+ sel_bit = 0;
+ break;
+ case 3:
+ reg = reg_devconf1;
+ sel_bit = 2;
+ break;
+ case 4:
+ reg = reg_devconf1;
+ sel_bit = 4;
+ break;
default:
return -EINVAL;
}
- if (cpu_class_is_omap2()) {
- if (clk_id == OMAP_MCBSP_SYSCLK_CLKS_FCLK) {
- omap_ctrl_writel(omap_ctrl_readl(reg) &
- ~(1 << sel_bit), reg);
- } else {
- omap_ctrl_writel(omap_ctrl_readl(reg) |
- (1 << sel_bit), reg);
- }
- }
+ if (clk_id == OMAP_MCBSP_SYSCLK_CLKS_FCLK)
+ omap_ctrl_writel(omap_ctrl_readl(reg) & ~(1 << sel_bit), reg);
+ else
+ omap_ctrl_writel(omap_ctrl_readl(reg) | (1 << sel_bit), reg);
return 0;
}
--
1.5.6.5
^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-09-05 6:18 ` Steve Sakoman
2008-09-05 16:56 ` Tony Lindgren
@ 2008-09-20 11:22 ` Arun KS
2008-09-20 11:41 ` Koen Kooi
1 sibling, 1 reply; 40+ messages in thread
From: Arun KS @ 2008-09-20 11:22 UTC (permalink / raw)
To: Steve Sakoman; +Cc: linux-omap@vger.kernel.org
On Fri, Sep 5, 2008 at 11:48 AM, Steve Sakoman <sakoman@gmail.com> wrote:
> On Thu, Sep 4, 2008 at 6:12 PM, Tony Lindgren <tony@atomide.com> wrote:
>> * Jarkko Nikula <jarkko.nikula@nokia.com> [080821 04:58]:
>>> Here are two patches adding support for OMAP2430 in McBSP driver and
>>> adding support for 2430 and 34xx in ASoC OMAP McBSP DAI driver.
>>>
>>> These are generated from top of currect l-o head but they apply also on
>>> top of Hiroshi's virtual clock patches with some offsets.
>>>
>>> If you have change to try them out on those CPUs, I would be happy to
>>> hear. I've tested these only on N810. Second patch will naturally go
>>> through the alsa-devel when we have necessary McBSP patches upstream.
>>
>> Can you please refresh these against the current l-o head?
>
> I've been testing these patches along with my Overo patches on the
> current l-o head. Audio is working fine, so the mcbsp changes haven't
> broken anything.
Is the null substream pointer was the problem in the alsa-lib? Is it fixed?
I am facing similar issue when using 5912 osk with tlvaic23b codec.
Regards,
Arun
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-09-20 11:22 ` [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx Arun KS
@ 2008-09-20 11:41 ` Koen Kooi
2008-09-20 12:03 ` Arun KS
[not found] ` <dfeb90390809200453i35da7891lcea6d620dbb0e46a@mail.gmail.com>
0 siblings, 2 replies; 40+ messages in thread
From: Koen Kooi @ 2008-09-20 11:41 UTC (permalink / raw)
To: Arun KS; +Cc: Steve Sakoman, linux-omap@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]
Op 20 sep 2008, om 13:22 heeft Arun KS het volgende geschreven:
> On Fri, Sep 5, 2008 at 11:48 AM, Steve Sakoman <sakoman@gmail.com>
> wrote:
>> On Thu, Sep 4, 2008 at 6:12 PM, Tony Lindgren <tony@atomide.com>
>> wrote:
>>> * Jarkko Nikula <jarkko.nikula@nokia.com> [080821 04:58]:
>>>> Here are two patches adding support for OMAP2430 in McBSP driver
>>>> and
>>>> adding support for 2430 and 34xx in ASoC OMAP McBSP DAI driver.
>>>>
>>>> These are generated from top of currect l-o head but they apply
>>>> also on
>>>> top of Hiroshi's virtual clock patches with some offsets.
>>>>
>>>> If you have change to try them out on those CPUs, I would be
>>>> happy to
>>>> hear. I've tested these only on N810. Second patch will naturally
>>>> go
>>>> through the alsa-devel when we have necessary McBSP patches
>>>> upstream.
>>>
>>> Can you please refresh these against the current l-o head?
>>
>> I've been testing these patches along with my Overo patches on the
>> current l-o head. Audio is working fine, so the mcbsp changes
>> haven't
>> broken anything.
>
> Is the null substream pointer was the problem in the alsa-lib?
We suspect it's in alsa-lib
> Is it fixed?
Sadly not :(
regards,
Koen
>
> I am facing similar issue when using 5912 osk with tlvaic23b codec.
>
> Regards,
> Arun
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply [flat|nested] 40+ messages in thread* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
2008-09-20 11:41 ` Koen Kooi
@ 2008-09-20 12:03 ` Arun KS
[not found] ` <dfeb90390809200453i35da7891lcea6d620dbb0e46a@mail.gmail.com>
1 sibling, 0 replies; 40+ messages in thread
From: Arun KS @ 2008-09-20 12:03 UTC (permalink / raw)
To: Koen Kooi; +Cc: Steve Sakoman, linux-omap@vger.kernel.org
On Sat, Sep 20, 2008 at 5:11 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>
> Op 20 sep 2008, om 13:22 heeft Arun KS het volgende geschreven:
>
>> On Fri, Sep 5, 2008 at 11:48 AM, Steve Sakoman <sakoman@gmail.com> wrote:
>>>
>>> On Thu, Sep 4, 2008 at 6:12 PM, Tony Lindgren <tony@atomide.com> wrote:
>>>>
>>>> * Jarkko Nikula <jarkko.nikula@nokia.com> [080821 04:58]:
>>>>>
>>>>> Here are two patches adding support for OMAP2430 in McBSP driver and
>>>>> adding support for 2430 and 34xx in ASoC OMAP McBSP DAI driver.
>>>>>
>>>>> These are generated from top of currect l-o head but they apply also on
>>>>> top of Hiroshi's virtual clock patches with some offsets.
>>>>>
>>>>> If you have change to try them out on those CPUs, I would be happy to
>>>>> hear. I've tested these only on N810. Second patch will naturally go
>>>>> through the alsa-devel when we have necessary McBSP patches upstream.
>>>>
>>>> Can you please refresh these against the current l-o head?
>>>
>>> I've been testing these patches along with my Overo patches on the
>>> current l-o head. Audio is working fine, so the mcbsp changes haven't
>>> broken anything.
>>
>> Is the null substream pointer was the problem in the alsa-lib?
>
> We suspect it's in alsa-lib
>
>> Is it fixed?
>
> Sadly not :(
I saw ASOC patches for over and beagle board. Any clue how they are
testing the audio dirver.
Regards,
Arun
>
> regards,
>
> Koen
>>
>> I am facing similar issue when using 5912 osk with tlvaic23b codec.
>>
>> Regards,
>> Arun
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
^ permalink raw reply [flat|nested] 40+ messages in thread[parent not found: <dfeb90390809200453i35da7891lcea6d620dbb0e46a@mail.gmail.com>]