* [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
@ 2008-08-21 11:55 Jarkko Nikula
2008-08-21 11:55 ` [RFC] ARM: OMAP: Add support for OMAP2430 in McBSP Jarkko Nikula
` (4 more replies)
0 siblings, 5 replies; 40+ messages in thread
From: Jarkko Nikula @ 2008-08-21 11:55 UTC (permalink / raw)
To: linux-omap
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* [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-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-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 21:25 ` Koen Kooi
@ 2008-08-27 22:14 ` Steve Sakoman
0 siblings, 0 replies; 40+ messages in thread
From: Steve Sakoman @ 2008-08-27 22:14 UTC (permalink / raw)
To: Koen Kooi; +Cc: Jarkko Nikula, Felipe Balbi, linux-omap@vger.kernel.org
> could you try removing /etc/asound.conf, it is set to dmix by default,
> which might screw things up.
Sadly, no effect. Same crash.
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-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
` (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
* [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 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
* 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
* Re: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
[not found] ` <dfeb90390809200453i35da7891lcea6d620dbb0e46a@mail.gmail.com>
@ 2008-09-20 12:21 ` Koen Kooi
0 siblings, 0 replies; 40+ messages in thread
From: Koen Kooi @ 2008-09-20 12:21 UTC (permalink / raw)
To: linux-omap@vger.kernel.org List
[-- Attachment #1: Type: text/plain, Size: 577 bytes --]
Op 20 sep 2008, om 13:53 heeft Arun KS het volgende geschreven:
>>>> 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 overo and beagle board. Any clue how they are
> testing the audio driver.
I use mplayer or aplay to test it, IIRC steve uses something similar.
regards,
Koen
[-- 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
end of thread, other threads:[~2008-09-20 12:22 UTC | newest]
Thread overview: 40+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 ` [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
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-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
2008-08-25 22:54 ` Felipe Balbi
2008-08-25 23:34 ` Steve Sakoman
2008-08-26 0:08 ` Felipe Balbi
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
2008-08-27 13:39 ` Steve Sakoman
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
2008-08-23 11:32 ` Arun KS
2008-09-05 1:12 ` Tony Lindgren
2008-09-05 6:18 ` Steve Sakoman
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
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
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>
2008-09-20 12:21 ` Koen Kooi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox