All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type
@ 2011-05-11 13:55 ` Sanjeev Premi
  0 siblings, 0 replies; 31+ messages in thread
From: Sanjeev Premi @ 2011-05-11 13:55 UTC (permalink / raw)
  To: alsa-devel, linux-omap, linux-arm-kernel
  Cc: Jarkko, Sanjeev Premi, Liam Girdwood, Mark Brown

Current checks for cpu type were too restrictive leading
to failures for other silicons in same family.

The problem was found while testing audio playback on
AM37x and AM35x processors. But should exist on OMAP36xx
as well.

Signed-off-by: Sanjeev Premi <premi@ti.com>
cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
cc: Liam Girdwood <lrg@ti.com>
cc: Jarkko Nikula <jhnikula@gmail.com>
---

 Changes in v4:
   Reposting after validating that patch still applies cleanly on
   linux-omap master [46966f1]

   Changed the subject as suggested by Jarkko. Since the subject
   has changed, i have omitted v4.

 Changes in v3::
   None. Reposting[1] after subscribing to alsa-devel list

 Changes in v2:
   1) Added one more check to the changes.
   2) Updated commit message to use plurals.


 [1] http://marc.info/?l=linux-omap&m=130026430110592&w=2


 sound/soc/omap/omap-mcbsp.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 2175f09..a88a0bf 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -146,7 +146,7 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream,
 	 * 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words)
 	 * 4 channels: size is 128 / 4 = 32 frames (4 * 32 words)
 	 */
-	if (cpu_is_omap343x() || cpu_is_omap44xx()) {
+	if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
 		/*
 		* Rule for the buffer size. We should not allow
 		* smaller buffer than the FIFO size to avoid underruns
@@ -258,7 +258,7 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream,
 	default:
 		return -EINVAL;
 	}
-	if (cpu_is_omap343x()) {
+	if (cpu_is_omap34xx()) {
 		dma_data->set_threshold = omap_mcbsp_set_threshold;
 		/* TODO: Currently, MODE_ELEMENT == MODE_FRAME */
 		if (omap_mcbsp_get_dma_op_mode(bus_id) ==
-- 
1.7.2.2

^ permalink raw reply related	[flat|nested] 31+ messages in thread

* [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type
@ 2011-05-11 13:55 ` Sanjeev Premi
  0 siblings, 0 replies; 31+ messages in thread
From: Sanjeev Premi @ 2011-05-11 13:55 UTC (permalink / raw)
  To: linux-arm-kernel

Current checks for cpu type were too restrictive leading
to failures for other silicons in same family.

The problem was found while testing audio playback on
AM37x and AM35x processors. But should exist on OMAP36xx
as well.

Signed-off-by: Sanjeev Premi <premi@ti.com>
cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
cc: Liam Girdwood <lrg@ti.com>
cc: Jarkko Nikula <jhnikula@gmail.com>
---

 Changes in v4:
   Reposting after validating that patch still applies cleanly on
   linux-omap master [46966f1]

   Changed the subject as suggested by Jarkko. Since the subject
   has changed, i have omitted v4.

 Changes in v3::
   None. Reposting[1] after subscribing to alsa-devel list

 Changes in v2:
   1) Added one more check to the changes.
   2) Updated commit message to use plurals.


 [1] http://marc.info/?l=linux-omap&m=130026430110592&w=2


 sound/soc/omap/omap-mcbsp.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 2175f09..a88a0bf 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -146,7 +146,7 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream,
 	 * 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words)
 	 * 4 channels: size is 128 / 4 = 32 frames (4 * 32 words)
 	 */
-	if (cpu_is_omap343x() || cpu_is_omap44xx()) {
+	if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
 		/*
 		* Rule for the buffer size. We should not allow
 		* smaller buffer than the FIFO size to avoid underruns
@@ -258,7 +258,7 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream,
 	default:
 		return -EINVAL;
 	}
-	if (cpu_is_omap343x()) {
+	if (cpu_is_omap34xx()) {
 		dma_data->set_threshold = omap_mcbsp_set_threshold;
 		/* TODO: Currently, MODE_ELEMENT == MODE_FRAME */
 		if (omap_mcbsp_get_dma_op_mode(bus_id) ==
-- 
1.7.2.2

^ permalink raw reply related	[flat|nested] 31+ messages in thread

* Re: [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type
  2011-05-11 13:55 ` Sanjeev Premi
@ 2011-05-11 13:57   ` Mark Brown
  -1 siblings, 0 replies; 31+ messages in thread
From: Mark Brown @ 2011-05-11 13:57 UTC (permalink / raw)
  To: Sanjeev Premi; +Cc: alsa-devel, linux-omap, Liam Girdwood, linux-arm-kernel

On Wed, May 11, 2011 at 07:25:35PM +0530, Sanjeev Premi wrote:
> Current checks for cpu type were too restrictive leading
> to failures for other silicons in same family.
> 
> The problem was found while testing audio playback on
> AM37x and AM35x processors. But should exist on OMAP36xx
> as well.

Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

^ permalink raw reply	[flat|nested] 31+ messages in thread

* [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type
@ 2011-05-11 13:57   ` Mark Brown
  0 siblings, 0 replies; 31+ messages in thread
From: Mark Brown @ 2011-05-11 13:57 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 11, 2011 at 07:25:35PM +0530, Sanjeev Premi wrote:
> Current checks for cpu type were too restrictive leading
> to failures for other silicons in same family.
> 
> The problem was found while testing audio playback on
> AM37x and AM35x processors. But should exist on OMAP36xx
> as well.

Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type
  2011-05-11 13:55 ` Sanjeev Premi
@ 2011-05-11 14:44   ` Peter Ujfalusi
  -1 siblings, 0 replies; 31+ messages in thread
From: Peter Ujfalusi @ 2011-05-11 14:44 UTC (permalink / raw)
  To: alsa-devel
  Cc: Premi, Sanjeev, Mark Brown, Jarkko, linux-omap, Girdwood, Liam,
	linux-arm-kernel

On Wednesday 11 May 2011 16:55:35 Premi, Sanjeev wrote:
> Current checks for cpu type were too restrictive leading
> to failures for other silicons in same family.
> 
> The problem was found while testing audio playback on
> AM37x and AM35x processors. But should exist on OMAP36xx
> as well.
> 
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> cc: Liam Girdwood <lrg@ti.com>
> cc: Jarkko Nikula <jhnikula@gmail.com>
> ---

Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

^ permalink raw reply	[flat|nested] 31+ messages in thread

* [alsa-devel] [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type
@ 2011-05-11 14:44   ` Peter Ujfalusi
  0 siblings, 0 replies; 31+ messages in thread
From: Peter Ujfalusi @ 2011-05-11 14:44 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 11 May 2011 16:55:35 Premi, Sanjeev wrote:
> Current checks for cpu type were too restrictive leading
> to failures for other silicons in same family.
> 
> The problem was found while testing audio playback on
> AM37x and AM35x processors. But should exist on OMAP36xx
> as well.
> 
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> cc: Liam Girdwood <lrg@ti.com>
> cc: Jarkko Nikula <jhnikula@gmail.com>
> ---

Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type
  2011-05-11 13:55 ` Sanjeev Premi
@ 2011-05-11 15:38   ` Jarkko Nikula
  -1 siblings, 0 replies; 31+ messages in thread
From: Jarkko Nikula @ 2011-05-11 15:38 UTC (permalink / raw)
  To: Sanjeev Premi
  Cc: alsa-devel, linux-omap, Liam Girdwood, linux-arm-kernel, Mark Brown

On Wed, 11 May 2011 19:25:35 +0530
Sanjeev Premi <premi@ti.com> wrote:

> Current checks for cpu type were too restrictive leading
> to failures for other silicons in same family.
> 
> The problem was found while testing audio playback on
> AM37x and AM35x processors. But should exist on OMAP36xx
> as well.
> 
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> cc: Liam Girdwood <lrg@ti.com>
> cc: Jarkko Nikula <jhnikula@gmail.com>
> ---
Acked-by: Jarkko Nikula <jhnikula@gmail.com>

^ permalink raw reply	[flat|nested] 31+ messages in thread

* [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type
@ 2011-05-11 15:38   ` Jarkko Nikula
  0 siblings, 0 replies; 31+ messages in thread
From: Jarkko Nikula @ 2011-05-11 15:38 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, 11 May 2011 19:25:35 +0530
Sanjeev Premi <premi@ti.com> wrote:

> Current checks for cpu type were too restrictive leading
> to failures for other silicons in same family.
> 
> The problem was found while testing audio playback on
> AM37x and AM35x processors. But should exist on OMAP36xx
> as well.
> 
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> cc: Liam Girdwood <lrg@ti.com>
> cc: Jarkko Nikula <jhnikula@gmail.com>
> ---
Acked-by: Jarkko Nikula <jhnikula@gmail.com>

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: [alsa-devel] [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type
  2011-05-11 13:55 ` Sanjeev Premi
                   ` (3 preceding siblings ...)
  (?)
@ 2011-05-11 18:16 ` Steve Calfee
  2011-05-11 19:19   ` Premi, Sanjeev
  2011-05-11 21:31   ` beagleboardxm 2.6.39rc4 mcbsp problems Steve Calfee
  -1 siblings, 2 replies; 31+ messages in thread
From: Steve Calfee @ 2011-05-11 18:16 UTC (permalink / raw)
  To: Sanjeev Premi; +Cc: linux-omap, Liam Girdwood

On 05/11/11 06:55, Sanjeev Premi wrote:
> Current checks for cpu type were too restrictive leading
> to failures for other silicons in same family.
> 
> The problem was found while testing audio playback on
> AM37x and AM35x processors. But should exist on OMAP36xx
> as well.
> 
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> cc: Liam Girdwood <lrg@ti.com>
> cc: Jarkko Nikula <jhnikula@gmail.com>
> ---
> 
>  Changes in v4:
>    Reposting after validating that patch still applies cleanly on
>    linux-omap master [46966f1]
> 
>    Changed the subject as suggested by Jarkko. Since the subject
>    has changed, i have omitted v4.
> 
>  Changes in v3::
>    None. Reposting[1] after subscribing to alsa-devel list
> 
>  Changes in v2:
>    1) Added one more check to the changes.
>    2) Updated commit message to use plurals.
> 
> 

Hi,

I removed all but the linux-omap list for my question.

I am trying to get the beagleboardxm to work with an external codec. I
am trying to use a mcbsp1 via the trainer board where it level shifts to
5 volts. I have applied this patch (I am on 2.6.39rc4), but still no
joy. I have a small analyzer attached to the I/O pins and important
things like the bit clock does not wiggle.

First a side question. In the arch/arm/mach-omap2/Kconfig when I select
BEAGLE, it selects OMAP_PACKAGE_CBB - but my bbxm system reference
manual says "The BeagleBoard-xM processor is the DM3730CBP 1GHz version"
which to me implies the proper package selection should be
OMAP_PACKAGE_CBP. The platform file mux34xx.c has different tables for
them, but I cant quickly tell the difference. Does this matter for mcbspx?

Here is a console dump where I try to aplay a file:
[ 1565.773712] omap_mcbsp_dai_startup: omap-mcbsp-dai.0 bus_id=0 active 0
[ 1565.781829] omap_pcm_open: ret 1
[ 1565.785491] asoc: HiFi <-> omap-mcbsp-dai.0 info:
[ 1565.790527] asoc: rate mask 0x7fe
[ 1565.794006] asoc: min ch 1 max ch 2
[ 1565.797760] asoc: min rate 8000 max rate 96000
[ 1565.826721] bbxm_hw_params: codec_dai=dfbbb9c0 clk 12288000
[ 1565.832702] bbxm_hw_params 2: codec_dai=dfbbb9c0 clk 12288000
[ 1565.838867] omap_mcbsp_dai_set_dai_fmt: configured 0
[ 1565.844146] bbxm_hw_params 3: codec_dai=dfbbb9c0 clk 12288000
[ 1565.850219] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5b8 in_freq 0
[ 1565.857299] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5b8 in_freq 0
[ 1565.864379] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5b8
in_freq 2048000
[ 1565.877319] max98095 4-0010: read 2a => 10
[ 1565.884277] max98095 4-0010: read 27 => 1
[ 1565.891143] max98095 4-0010: read 2a => 10
[ 1565.898956] max98095 4-0010: read 2e => 0
[ 1565.903198] omap_mcbsp_dai_hw_params: format 1
[ 1565.907958] omap_mcbsp_dai_hw_params: stream Audio Playback
[ 1565.913909] omap_mcbsp_dai_hw_params: framesize 32 in_freq=2048000
div=8 rate=8000
[ 1565.921936] omap-mcbsp omap-mcbsp.1: Configuring McBSP1  phys_base:
0x48074000
[ 1565.929565] omap_pcm_hw_params: ret 0
[ 1565.934722] omap_pcm_prepare: dma_data bf00d4a0
[ 1565.945831] max98095 4-0010: read 91 => 0
[ 1565.950347] max98095 4-0010: write 91 = 3
[ 1565.958618] max98095 4-0010: read 91 => 3
[ 1565.963195] max98095 4-0010: write 91 = c3
[ 1565.972351] snd_pcm_lib_write1: state 2 size 1000
[ 1565.977691] snd_pcm_lib_write1: offset 0
[ 1565.981842] snd_pcm_update_state: stream=0 avail=3000
buffer_size=4000 twake=0 tsleep=1
[ 1565.992706] snd_pcm_lib_write1: state 2 size 1000
[ 1565.997985] snd_pcm_lib_write1: offset 0
[ 1566.002227] snd_pcm_update_state: stream=0 avail=2000
buffer_size=4000 twake=0 tsleep=1
[ 1566.011810] snd_pcm_lib_write1: state 2 size 1000
[ 1566.017120] snd_pcm_lib_write1: offset 0
[ 1566.021270] snd_pcm_update_state: stream=0 avail=1000
buffer_size=4000 twake=0 tsleep=1
[ 1566.033050] snd_pcm_lib_write1: state 2 size 1000
[ 1566.038360] snd_pcm_lib_write1: offset 0
[ 1566.042510] snd_pcm_pre_start: state 3
[ 1566.046447] snd_pcm_do_start: state 3
[ 1566.050292] omap_pcm_trigger: cmd 1
[ 1566.053955] omap_start_dma: lch 0
[ 1566.057891] omap-mcbsp omap-mcbsp.1: **** McBSP1 regs ****
[ 1566.063629] omap-mcbsp omap-mcbsp.1: DRR2:  0x0000
[ 1566.068664] omap-mcbsp omap-mcbsp.1: DRR1:  0x0000
[ 1566.073699] omap-mcbsp omap-mcbsp.1: DXR2:  0x0000
[ 1566.078735] omap-mcbsp omap-mcbsp.1: DXR1:  0x0000
[ 1566.083740] omap-mcbsp omap-mcbsp.1: SPCR2: 0x02f5
[ 1566.088775] omap-mcbsp omap-mcbsp.1: SPCR1: 0x0030
[ 1566.093811] omap-mcbsp omap-mcbsp.1: RCR2:  0x8041
[ 1566.098846] omap-mcbsp omap-mcbsp.1: RCR1:  0x0040
[ 1566.103851] omap-mcbsp omap-mcbsp.1: XCR2:  0x8041
[ 1566.108886] omap-mcbsp omap-mcbsp.1: XCR1:  0x0040
[ 1566.113922] omap-mcbsp omap-mcbsp.1: SRGR2: 0x101f
[ 1566.118927] omap-mcbsp omap-mcbsp.1: SRGR1: 0x0f07
[ 1566.123962] omap-mcbsp omap-mcbsp.1: PCR0:  0x0f0f
[ 1566.128997] omap-mcbsp omap-mcbsp.1: ***********************
[ 1566.134918] snd_pcm_post_start: state 3
[ 1566.138977] snd_pcm_update_state: stream=0 avail=0 buffer_size=4000
twake=0 tsleep=1
[ 1566.148681] snd_pcm_lib_write1: state 3 size 1000
[ 1566.153625] omap_pcm_pointer: offset 64
[ 1566.157653] snd_pcm_update_hw_ptr0: old_hw_ptr=0 pos=64 in_int=0
[ 1566.163970] snd_pcm_update_hw_ptr0: stream=0 new_hw_ptr=64 silence_size=0
[ 1566.171081] snd_pcm_update_state: stream=0 avail=64 buffer_size=4000
twake=1000 tsleep=1
[ 1566.180145] snd_pcm_lib_write1: offset 0
[ 1566.184295] snd_pcm_lib_write1: state 3 size 936
[ 1566.189147] omap_pcm_pointer: offset 64
[ 1566.193176] snd_pcm_update_hw_ptr0: old_hw_ptr=64 pos=64 in_int=0
[ 1576.194274] ALSA sound/core/pcm_lib.c:1795: playback write error (DMA
or IRQ trouble?)
[ 1576.304199] snd_pcm_lib_write1: state 3 size 936
[ 1576.309051] omap_pcm_pointer: offset 64
[ 1576.313079] snd_pcm_update_hw_ptr0: old_hw_ptr=64 pos=64 in_int=0
[ 1586.319274] ALSA sound/core/pcm_lib.c:1795: playback write error (DMA
or IRQ trouble?)
[ 1586.337554] omap_pcm_trigger: cmd 0
[ 1591.342651] pop wq checking: HiFi Playback status: inactive waiting: yes
[ 1591.351898] max98095 4-0010: read 91 => c3
[ 1591.356231] max98095 4-0010: write 91 = 3
[ 1591.362030] max98095 4-0010: read 91 => 3
[ 1591.366424] max98095 4-0010: write 91 = 0
[ 1591.373229] max98095 4-0010: read 90 => c

^ permalink raw reply	[flat|nested] 31+ messages in thread

* RE: [alsa-devel] [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type
  2011-05-11 18:16 ` [alsa-devel] " Steve Calfee
@ 2011-05-11 19:19   ` Premi, Sanjeev
  2011-05-11 21:31   ` beagleboardxm 2.6.39rc4 mcbsp problems Steve Calfee
  1 sibling, 0 replies; 31+ messages in thread
From: Premi, Sanjeev @ 2011-05-11 19:19 UTC (permalink / raw)
  To: Steve Calfee; +Cc: linux-omap, Girdwood, Liam

From: Steve Calfee [stevecalfee@gmail.com]
> Sent: Wednesday, May 11, 2011 11:46 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org; Girdwood, Liam
> Subject: Re: [alsa-devel] [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type
> 

[snip]...[snip]

> 
> Hi,
> 
> I removed all but the linux-omap list for my question.

[sp] Using a separate thread for this issues would have gotten more eyes!

> 
> I am trying to get the beagleboardxm to work with an external codec. I
> am trying to use a mcbsp1 via the trainer board where it level shifts to
> 5 volts. I have applied this patch (I am on 2.6.39rc4), but still no
> joy. I have a small analyzer attached to the I/O pins and important
> things like the bit clock does not wiggle.
> 
> First a side question. In the arch/arm/mach-omap2/Kconfig when I select
> BEAGLE, it selects OMAP_PACKAGE_CBB - but my bbxm system reference
> manual says "The BeagleBoard-xM processor is the DM3730CBP 1GHz version"
> which to me implies the proper package selection should be
> OMAP_PACKAGE_CBP. The platform file mux34xx.c has different tables for
> them, but I cant quickly tell the difference. Does this matter for mcbspx?

[sp] Check this page to find the differences:
     http://processors.wiki.ti.com/index.php/OMAP35x_To_AM37x_Hardware_Migration_Guide

~sanjeev

[snip]...[snip]

^ permalink raw reply	[flat|nested] 31+ messages in thread

* beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-11 18:16 ` [alsa-devel] " Steve Calfee
  2011-05-11 19:19   ` Premi, Sanjeev
@ 2011-05-11 21:31   ` Steve Calfee
  2011-05-12  6:25     ` Jarkko Nikula
  1 sibling, 1 reply; 31+ messages in thread
From: Steve Calfee @ 2011-05-11 21:31 UTC (permalink / raw)
  To: Sanjeev Premi; +Cc: linux-omap, Liam Girdwood

On 05/11/11 11:16, Steve Calfee wrote:
New title, more appropriate to the topic.

I was replying to the fix posted by Sanjeev fixing
a/sound/soc/omap/omap-mcbsp.c

I am pretty near the cutting edge kernel, trying to use the latest alsa
changes. I cannot get bbxm to talk to an external codec via mcbsp1.

Has anyone been able to use mcbsp1 on a recent linux-next.

More below.

> Hi,
> 
> I removed all but the linux-omap list for my question.
> 
> I am trying to get the beagleboardxm to work with an external codec. I
> am trying to use a mcbsp1 via the trainer board where it level shifts to
> 5 volts. I have applied this patch (I am on 2.6.39rc4), but still no
> joy. I have a small analyzer attached to the I/O pins and important
> things like the bit clock does not wiggle.
> 
> First a side question. In the arch/arm/mach-omap2/Kconfig when I select
> BEAGLE, it selects OMAP_PACKAGE_CBB - but my bbxm system reference
> manual says "The BeagleBoard-xM processor is the DM3730CBP 1GHz version"
> which to me implies the proper package selection should be
> OMAP_PACKAGE_CBP. The platform file mux34xx.c has different tables for
> them, but I cant quickly tell the difference. Does this matter for mcbspx?
> 
Sanjeev pointed me to:
 Check this page to find the differences:
http://processors.wiki.ti.com/index.php/OMAP35x_To_AM37x_Hardware_Migration_Guide

Where it appears TI has some new chip naming scheme and maybe the bbxm
is a am3730? In any case it doesn't seem that mcbsp is affected by the
package change.

> Here is a console dump where I try to aplay a file:
> [ 1565.773712] omap_mcbsp_dai_startup: omap-mcbsp-dai.0 bus_id=0 active 0
> [ 1565.781829] omap_pcm_open: ret 1
> [ 1565.785491] asoc: HiFi <-> omap-mcbsp-dai.0 info:
> [ 1565.790527] asoc: rate mask 0x7fe
> [ 1565.794006] asoc: min ch 1 max ch 2
> [ 1565.797760] asoc: min rate 8000 max rate 96000
> [ 1565.826721] bbxm_hw_params: codec_dai=dfbbb9c0 clk 12288000
> [ 1565.832702] bbxm_hw_params 2: codec_dai=dfbbb9c0 clk 12288000
> [ 1565.838867] omap_mcbsp_dai_set_dai_fmt: configured 0
> [ 1565.844146] bbxm_hw_params 3: codec_dai=dfbbb9c0 clk 12288000
> [ 1565.850219] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5b8 in_freq 0
> [ 1565.857299] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5b8 in_freq 0
> [ 1565.864379] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5b8
> in_freq 2048000
> [ 1565.877319] max98095 4-0010: read 2a => 10
> [ 1565.884277] max98095 4-0010: read 27 => 1
> [ 1565.891143] max98095 4-0010: read 2a => 10
> [ 1565.898956] max98095 4-0010: read 2e => 0
> [ 1565.903198] omap_mcbsp_dai_hw_params: format 1
> [ 1565.907958] omap_mcbsp_dai_hw_params: stream Audio Playback
> [ 1565.913909] omap_mcbsp_dai_hw_params: framesize 32 in_freq=2048000
> div=8 rate=8000
> [ 1565.921936] omap-mcbsp omap-mcbsp.1: Configuring McBSP1  phys_base:
> 0x48074000
> [ 1565.929565] omap_pcm_hw_params: ret 0
> [ 1565.934722] omap_pcm_prepare: dma_data bf00d4a0
> [ 1565.945831] max98095 4-0010: read 91 => 0
> [ 1565.950347] max98095 4-0010: write 91 = 3
> [ 1565.958618] max98095 4-0010: read 91 => 3
> [ 1565.963195] max98095 4-0010: write 91 = c3
> [ 1565.972351] snd_pcm_lib_write1: state 2 size 1000
> [ 1565.977691] snd_pcm_lib_write1: offset 0
> [ 1565.981842] snd_pcm_update_state: stream=0 avail=3000
> buffer_size=4000 twake=0 tsleep=1
> [ 1565.992706] snd_pcm_lib_write1: state 2 size 1000
> [ 1565.997985] snd_pcm_lib_write1: offset 0
> [ 1566.002227] snd_pcm_update_state: stream=0 avail=2000
> buffer_size=4000 twake=0 tsleep=1
> [ 1566.011810] snd_pcm_lib_write1: state 2 size 1000
> [ 1566.017120] snd_pcm_lib_write1: offset 0
> [ 1566.021270] snd_pcm_update_state: stream=0 avail=1000
> buffer_size=4000 twake=0 tsleep=1
> [ 1566.033050] snd_pcm_lib_write1: state 2 size 1000
> [ 1566.038360] snd_pcm_lib_write1: offset 0
> [ 1566.042510] snd_pcm_pre_start: state 3
> [ 1566.046447] snd_pcm_do_start: state 3
> [ 1566.050292] omap_pcm_trigger: cmd 1
> [ 1566.053955] omap_start_dma: lch 0
> [ 1566.057891] omap-mcbsp omap-mcbsp.1: **** McBSP1 regs ****
> [ 1566.063629] omap-mcbsp omap-mcbsp.1: DRR2:  0x0000
> [ 1566.068664] omap-mcbsp omap-mcbsp.1: DRR1:  0x0000
> [ 1566.073699] omap-mcbsp omap-mcbsp.1: DXR2:  0x0000
> [ 1566.078735] omap-mcbsp omap-mcbsp.1: DXR1:  0x0000
> [ 1566.083740] omap-mcbsp omap-mcbsp.1: SPCR2: 0x02f5
> [ 1566.088775] omap-mcbsp omap-mcbsp.1: SPCR1: 0x0030
> [ 1566.093811] omap-mcbsp omap-mcbsp.1: RCR2:  0x8041
> [ 1566.098846] omap-mcbsp omap-mcbsp.1: RCR1:  0x0040
> [ 1566.103851] omap-mcbsp omap-mcbsp.1: XCR2:  0x8041
> [ 1566.108886] omap-mcbsp omap-mcbsp.1: XCR1:  0x0040
> [ 1566.113922] omap-mcbsp omap-mcbsp.1: SRGR2: 0x101f
> [ 1566.118927] omap-mcbsp omap-mcbsp.1: SRGR1: 0x0f07
> [ 1566.123962] omap-mcbsp omap-mcbsp.1: PCR0:  0x0f0f
> [ 1566.128997] omap-mcbsp omap-mcbsp.1: ***********************
> [ 1566.134918] snd_pcm_post_start: state 3
> [ 1566.138977] snd_pcm_update_state: stream=0 avail=0 buffer_size=4000
> twake=0 tsleep=1
> [ 1566.148681] snd_pcm_lib_write1: state 3 size 1000
> [ 1566.153625] omap_pcm_pointer: offset 64
> [ 1566.157653] snd_pcm_update_hw_ptr0: old_hw_ptr=0 pos=64 in_int=0
> [ 1566.163970] snd_pcm_update_hw_ptr0: stream=0 new_hw_ptr=64 silence_size=0
> [ 1566.171081] snd_pcm_update_state: stream=0 avail=64 buffer_size=4000
> twake=1000 tsleep=1
> [ 1566.180145] snd_pcm_lib_write1: offset 0
> [ 1566.184295] snd_pcm_lib_write1: state 3 size 936
> [ 1566.189147] omap_pcm_pointer: offset 64
> [ 1566.193176] snd_pcm_update_hw_ptr0: old_hw_ptr=64 pos=64 in_int=0
> [ 1576.194274] ALSA sound/core/pcm_lib.c:1795: playback write error (DMA
> or IRQ trouble?)
> [ 1576.304199] snd_pcm_lib_write1: state 3 size 936
> [ 1576.309051] omap_pcm_pointer: offset 64
> [ 1576.313079] snd_pcm_update_hw_ptr0: old_hw_ptr=64 pos=64 in_int=0
> [ 1586.319274] ALSA sound/core/pcm_lib.c:1795: playback write error (DMA
> or IRQ trouble?)
> [ 1586.337554] omap_pcm_trigger: cmd 0
> [ 1591.342651] pop wq checking: HiFi Playback status: inactive waiting: yes
> [ 1591.351898] max98095 4-0010: read 91 => c3
> [ 1591.356231] max98095 4-0010: write 91 = 3
> [ 1591.362030] max98095 4-0010: read 91 => 3
> [ 1591.366424] max98095 4-0010: write 91 = 0
> [ 1591.373229] max98095 4-0010: read 90 => c

Regards, Steve

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-11 21:31   ` beagleboardxm 2.6.39rc4 mcbsp problems Steve Calfee
@ 2011-05-12  6:25     ` Jarkko Nikula
  2011-05-12 11:01       ` Peter Ujfalusi
  0 siblings, 1 reply; 31+ messages in thread
From: Jarkko Nikula @ 2011-05-12  6:25 UTC (permalink / raw)
  To: Steve Calfee; +Cc: Sanjeev Premi, linux-omap, Liam Girdwood

On Wed, 11 May 2011 14:31:46 -0700
Steve Calfee <stevecalfee@gmail.com> wrote:

> On 05/11/11 11:16, Steve Calfee wrote:
> New title, more appropriate to the topic.
> 
> I was replying to the fix posted by Sanjeev fixing
> a/sound/soc/omap/omap-mcbsp.c
> 
> I am pretty near the cutting edge kernel, trying to use the latest alsa
> changes. I cannot get bbxm to talk to an external codec via mcbsp1.
> 
> Has anyone been able to use mcbsp1 on a recent linux-next.
> 
This sounds like that those expansion connector pins are not muxed to
mcbsp1 but e.g. to gpio by the bootloader. Are you able to see clock
activity on CLKX if you enable CONFIG_OMAP_MUX=y and add following
lines to board_mux table in arch/arm/mach-omap2/board-omap3beagle.c?

Of course for this you need to use omap as a master and codec as a
slave. One example for this is sound/soc/omap/omap3pandora.c.

 static struct omap_board_mux board_mux[] __initdata = {
+	OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+	OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+	OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+	OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+
 	{ .reg_offset = OMAP_MUX_TERMINATOR },

-- 
Jarkko

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-12  6:25     ` Jarkko Nikula
@ 2011-05-12 11:01       ` Peter Ujfalusi
  2011-05-12 18:43         ` Steve Calfee
  0 siblings, 1 reply; 31+ messages in thread
From: Peter Ujfalusi @ 2011-05-12 11:01 UTC (permalink / raw)
  To: Jarkko Nikula; +Cc: Steve Calfee, Premi, Sanjeev, linux-omap, Girdwood, Liam

On Thursday 12 May 2011 09:25:55 Jarkko Nikula wrote:
> Of course for this you need to use omap as a master and codec as a
> slave. One example for this is sound/soc/omap/omap3pandora.c.
> 
>  static struct omap_board_mux board_mux[] __initdata = {
> +	OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
> +	OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
> +	OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
> +	OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
> +

I think the CLKX, FSX need to be input, since the config suggests,t that 
McBSP1 is the slave port:

> [ 1566.123962] omap-mcbsp omap-mcbsp.1: PCR0:  0x0f0f

-- 
Péter
--
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] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-12 11:01       ` Peter Ujfalusi
@ 2011-05-12 18:43         ` Steve Calfee
  2011-05-13  5:59           ` Peter Ujfalusi
  0 siblings, 1 reply; 31+ messages in thread
From: Steve Calfee @ 2011-05-12 18:43 UTC (permalink / raw)
  To: Peter Ujfalusi; +Cc: Jarkko Nikula, Premi, Sanjeev, linux-omap, Girdwood, Liam

On 05/12/11 04:01, Peter Ujfalusi wrote:
> On Thursday 12 May 2011 09:25:55 Jarkko Nikula wrote:
>> Of course for this you need to use omap as a master and codec as a
>> slave. One example for this is sound/soc/omap/omap3pandora.c.
>>
>>  static struct omap_board_mux board_mux[] __initdata = {
>> +	OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
>> +	OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
>> +	OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
>> +	OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
>> +
> 
> I think the CLKX, FSX need to be input, since the config suggests,t that 
> McBSP1 is the slave port:
> 
>> [ 1566.123962] omap-mcbsp omap-mcbsp.1: PCR0:  0x0f0f
> 

Hi, thanks for trying to help.

I already tried that, but it still did not xmit. Now I wonder about
master/slave. I thought that the omap is set up as a master. I looked at
PCR0 docs in the tech ref manual and I get:

11 FSXM Transmit Frame-Synchronization Mode RW 0x0
0x0: Frame-synchronization signal derived from an
external source
0x1: Frame synchronization is determined by the SRG
frame-synchronization mode bit FSGM in SRGR2.
10 FSRM Receive Frame-Synchronization Mode RW 0x0
0x0: Frame-Synchronization pulses generated by an
external device. FSR is an input pin.
0x1: Frame synchronization generated internally by SRG.
FSR is an output pin except when GSYNC=1 in SRGR.
Etc.

Since it is set to 0xF0F, doesn't this set it as master?

Also, spelunking the kernel sources, I cannot seem to find the source
for mcbsp_data->regs -- do you know where it gets set initially?



^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-12 18:43         ` Steve Calfee
@ 2011-05-13  5:59           ` Peter Ujfalusi
  2011-05-14  2:47             ` Steve Calfee
  0 siblings, 1 reply; 31+ messages in thread
From: Peter Ujfalusi @ 2011-05-13  5:59 UTC (permalink / raw)
  To: Steve Calfee; +Cc: Jarkko Nikula, Premi, Sanjeev, linux-omap, Girdwood, Liam

On Thursday 12 May 2011 21:43:20 Steve Calfee wrote:
> Since it is set to 0xF0F, doesn't this set it as master?

Sorry, that is correct, McBSP is configured as msater.

> Also, spelunking the kernel sources, I cannot seem to find the source
> for mcbsp_data->regs -- do you know where it gets set initially?

They configured within sound/soc/omap/omap-pcm.c

Have you configured the clk source, and divider correctly for McBSP port from 
the machine driver (with snd_soc_dai_set_sysclk)?

-- 
Péter
--
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] 31+ messages in thread

* Re: [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type
  2011-05-11 13:55 ` Sanjeev Premi
@ 2011-05-13 12:13   ` Liam Girdwood
  -1 siblings, 0 replies; 31+ messages in thread
From: Liam Girdwood @ 2011-05-13 12:13 UTC (permalink / raw)
  To: Premi, Sanjeev; +Cc: alsa-devel, linux-omap, linux-arm-kernel, Mark Brown

On 11/05/11 14:55, Premi, Sanjeev wrote:
> Current checks for cpu type were too restrictive leading
> to failures for other silicons in same family.
> 
> The problem was found while testing audio playback on
> AM37x and AM35x processors. But should exist on OMAP36xx
> as well.
> 
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> cc: Liam Girdwood <lrg@ti.com>
> cc: Jarkko Nikula <jhnikula@gmail.com>
> ---
> 
>  Changes in v4:
>    Reposting after validating that patch still applies cleanly on
>    linux-omap master [46966f1]
> 
>    Changed the subject as suggested by Jarkko. Since the subject
>    has changed, i have omitted v4.
> 
>  Changes in v3::
>    None. Reposting[1] after subscribing to alsa-devel list
> 
>  Changes in v2:
>    1) Added one more check to the changes.
>    2) Updated commit message to use plurals.
> 
> 
> 
Applied.

Thanks

Liam

^ permalink raw reply	[flat|nested] 31+ messages in thread

* [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type
@ 2011-05-13 12:13   ` Liam Girdwood
  0 siblings, 0 replies; 31+ messages in thread
From: Liam Girdwood @ 2011-05-13 12:13 UTC (permalink / raw)
  To: linux-arm-kernel

On 11/05/11 14:55, Premi, Sanjeev wrote:
> Current checks for cpu type were too restrictive leading
> to failures for other silicons in same family.
> 
> The problem was found while testing audio playback on
> AM37x and AM35x processors. But should exist on OMAP36xx
> as well.
> 
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> cc: Liam Girdwood <lrg@ti.com>
> cc: Jarkko Nikula <jhnikula@gmail.com>
> ---
> 
>  Changes in v4:
>    Reposting after validating that patch still applies cleanly on
>    linux-omap master [46966f1]
> 
>    Changed the subject as suggested by Jarkko. Since the subject
>    has changed, i have omitted v4.
> 
>  Changes in v3::
>    None. Reposting[1] after subscribing to alsa-devel list
> 
>  Changes in v2:
>    1) Added one more check to the changes.
>    2) Updated commit message to use plurals.
> 
> 
> 
Applied.

Thanks

Liam

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-13  5:59           ` Peter Ujfalusi
@ 2011-05-14  2:47             ` Steve Calfee
  2011-05-16  8:54               ` Peter Ujfalusi
  0 siblings, 1 reply; 31+ messages in thread
From: Steve Calfee @ 2011-05-14  2:47 UTC (permalink / raw)
  To: Peter Ujfalusi; +Cc: Jarkko Nikula, Premi, Sanjeev, linux-omap, Girdwood, Liam

On Thu, May 12, 2011 at 10:59 PM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> On Thursday 12 May 2011 21:43:20 Steve Calfee wrote:
>> Since it is set to 0xF0F, doesn't this set it as master?
>
> Sorry, that is correct, McBSP is configured as msater.
>
>> Also, spelunking the kernel sources, I cannot seem to find the source
>> for mcbsp_data->regs -- do you know where it gets set initially?
>
> They configured within sound/soc/omap/omap-pcm.c
>
> Have you configured the clk source, and divider correctly for McBSP port from
> the machine driver (with snd_soc_dai_set_sysclk)?
>

Hi, Thanks for the suggestions.

I think I have it correct. I was able to load the original
sound/soc/beagleboard.c and the codec/twl4030 and play a wav file. I
have been copying that to try and get my new codec driver to work. One
immediate difference is that the system sets up the twl4030 as the
master i2s device on the bus. So I changed my codec over to do that
too. Now the mcbsp register dump matches the working setup.

I put in a few debug statements. It appears that my DMA never gets
started. I know it can work with a different machine and codec driver,
but not mine. I don't see any explicit DMA init, but that must be the
problem.  Any more ideas?

Thanks, Steve

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-14  2:47             ` Steve Calfee
@ 2011-05-16  8:54               ` Peter Ujfalusi
  2011-05-16 18:07                 ` Steve Calfee
  0 siblings, 1 reply; 31+ messages in thread
From: Peter Ujfalusi @ 2011-05-16  8:54 UTC (permalink / raw)
  To: Steve Calfee; +Cc: Jarkko Nikula, Premi, Sanjeev, linux-omap, Girdwood, Liam

On Saturday 14 May 2011 05:47:33 Steve Calfee wrote:
> I put in a few debug statements. It appears that my DMA never gets
> started. I know it can work with a different machine and codec driver,
> but not mine. I don't see any explicit DMA init, but that must be the
> problem.  Any more ideas?

You mean neither omap_pcm_hw_params nor omap_pcm_trigger got called?
Could you post the output of dmesg related to ASoC? Does the connection 
between the CPU and codec DAI correct?
Does McBSP part got initialized (for example does omap_mcbsp_dai_hw_params, 
omap_mcbsp_dai_trigger got called)?

-- 
Péter
--
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] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-16  8:54               ` Peter Ujfalusi
@ 2011-05-16 18:07                 ` Steve Calfee
  2011-05-17  6:37                   ` Jarkko Nikula
  2011-05-17 10:42                   ` Peter Ujfalusi
  0 siblings, 2 replies; 31+ messages in thread
From: Steve Calfee @ 2011-05-16 18:07 UTC (permalink / raw)
  To: Peter Ujfalusi; +Cc: Jarkko Nikula, Premi, Sanjeev, linux-omap, Girdwood, Liam

On 05/16/11 01:54, Peter Ujfalusi wrote:
> On Saturday 14 May 2011 05:47:33 Steve Calfee wrote:
>> I put in a few debug statements. It appears that my DMA never gets
>> started. I know it can work with a different machine and codec driver,
>> but not mine. I don't see any explicit DMA init, but that must be the
>> problem.  Any more ideas?
> 
> You mean neither omap_pcm_hw_params nor omap_pcm_trigger got called?
> Could you post the output of dmesg related to ASoC? Does the connection 
> between the CPU and codec DAI correct?
> Does McBSP part got initialized (for example does omap_mcbsp_dai_hw_params, 
> omap_mcbsp_dai_trigger got called)?
> 
No, they get called. I just don't get the clock on the bclk pin.

I think I have the mcbsp1 set up correctly - I explictly set the MUX:

static struct omap_board_mux board_mux[] __initdata = {
#if 1
	/* McBSP 1 */
	OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
	OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
	OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
	OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
#endif
	{ .reg_offset = OMAP_MUX_TERMINATOR },
};

And elsewhere I set the mcbsp to use a 4 pin interface:
	/* configure mcbsp1 to just use 4 pins */
	ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_CLKR_SRC_CLKX, 0,
				SND_SOC_CLOCK_IN);
	if (ret < 0) {
		printk(KERN_ERR "can't set CPU system clock OMAP_MCBSP_CLKR_SRC_CLKX\n");
		//return ret;
	}

	ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_FSR_SRC_FSX, 0,
				SND_SOC_CLOCK_IN);
	if (ret < 0) {
		printk(KERN_ERR "can't set CPU system clock OMAP_MCBSP_FSR_SRC_FSX\n");
		//return ret;
	}


Here is some hopefully relevant console output. Note that where I added
debug printk's I also printed the __func__.

# cat /proc/asound/cards
 0 [bbxm           ]:  - bbxm
                      bbxm
# lsmod
Module                  Size  Used by    Not tainted
snd_soc_max98095       26314  1
snd_soc_omap3beaglexm     4818  0
snd_soc_omap_mcbsp      7148  1
gpio_i2cmux             1699  0
i2c_mux                 1408  1 gpio_i2cmux
# aplay /newmail2.wav
[  262.129882] omap_mcbsp_dai_startup: omap-mcbsp-dai.0 bus_id=0 active 0
[  262.137847] omap-mcbsp omap-mcbsp.1: omap_mcbsp_request:
tx_irq_completion t=59 r=60
[  262.146972] omap_mcbsp_dai_startup: rules omap-mcbsp-dai.0 bus_id=0
active 0
[  262.155090] omap_pcm_open: ret 1
[  262.158752] asoc: HiFi <-> omap-mcbsp-dai.0 info:
[  262.163757] asoc: rate mask 0x7fe
[  262.167327] asoc: min ch 1 max ch 2
[  262.170989] asoc: min rate 8000 max rate 96000
Playing WAVE '/newmail2.wav' : Signed 16 bit Little Endian, Rate 8000
Hz, Stereo
[  262.188537] bbxm_hw_params: codec_dai=dfbb9ac0 clk 12288000
[  262.194519] bbxm_hw_params 2: codec_dai=dfbb9ac0 clk 12288000
[  262.200683] omap_mcbsp_dai_set_dai_fmt: configured 0
[  262.205932] bbxm_hw_params 3: codec_dai=dfbb9ac0 clk 12288000
[  262.212036] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5f8 in_freq 0
[  262.219116] omap_mcbsp_dai_set_dai_sysclk: mcbsp_data=bf00d5f8 in_freq 0
[  262.227752] max98095 4-0010: read 2a => 90
[  262.234832] max98095 4-0010: read 27 => 1
[  262.240875] max98095 4-0010: read 2a => 90
[  262.245300] max98095 4-0010: write 28 = 7
[  262.252044] max98095 4-0010: write 29 = 8f
[  262.261779] max98095 4-0010: read 2e => 0
[  262.266265] omap_mcbsp_dai_hw_params: format 1
[  262.270996] omap_mcbsp_dai_hw_params: stream Audio Playback
[  262.276977] omap-mcbsp omap-mcbsp.1: Configuring McBSP1  phys_base:
0x48074000
[  262.284606] omap_pcm_hw_params: ret 0
[  262.290008] omap_pcm_prepare: dma_data bf00d4e0
[  262.298980] max98095 4-0010: read 91 => 0
[  262.303558] max98095 4-0010: write 91 = 3
[  262.311798] max98095 4-0010: read 91 => 3
[  262.316345] max98095 4-0010: write 91 = c3
[  262.326690] snd_pcm_lib_write1: state 2 size 1000
[  262.332031] snd_pcm_lib_write1: offset 0
[  262.336181] snd_pcm_update_state: stream=0 avail=3000
buffer_size=4000 twake=0 tsleep=1
[  262.345825] snd_pcm_lib_write1: state 2 size 1000
[  262.351165] snd_pcm_lib_write1: offset 0
[  262.355346] snd_pcm_update_state: stream=0 avail=2000
buffer_size=4000 twake=0 tsleep=1
[  262.364929] snd_pcm_lib_write1: state 2 size 1000
[  262.370269] snd_pcm_lib_write1: offset 0
[  262.374420] snd_pcm_update_state: stream=0 avail=1000
buffer_size=4000 twake=0 tsleep=1
[  262.383972] snd_pcm_lib_write1: state 2 size 1000
[  262.389312] snd_pcm_lib_write1: offset 0
[  262.393463] snd_pcm_pre_start: state 3
[  262.397399] snd_pcm_do_start: state 3
[  262.401245] omap_pcm_trigger: cmd 1
[  262.404907] omap_start_dma: lch 0
[  262.408843] omap-mcbsp omap-mcbsp.1: **** McBSP1 regs ****
[  262.414581] omap-mcbsp omap-mcbsp.1: DRR2:  0x0000
[  262.419616] omap-mcbsp omap-mcbsp.1: DRR1:  0x0000
[  262.424652] omap-mcbsp omap-mcbsp.1: DXR2:  0x0000
[  262.429656] omap-mcbsp omap-mcbsp.1: DXR1:  0x0000
[  262.434692] omap-mcbsp omap-mcbsp.1: SPCR2: 0x0235
[  262.439727] omap-mcbsp omap-mcbsp.1: SPCR1: 0x0030
[  262.444763] omap-mcbsp omap-mcbsp.1: RCR2:  0x8041
[  262.449768] omap-mcbsp omap-mcbsp.1: RCR1:  0x0040
[  262.454803] omap-mcbsp omap-mcbsp.1: XCR2:  0x8041
[  262.459838] omap-mcbsp omap-mcbsp.1: XCR1:  0x0040
[  262.464843] omap-mcbsp omap-mcbsp.1: SRGR2: 0x001f
[  262.469879] omap-mcbsp omap-mcbsp.1: SRGR1: 0x0f00
[  262.474914] omap-mcbsp omap-mcbsp.1: PCR0:  0x000f
[  262.479919] omap-mcbsp omap-mcbsp.1: ***********************
[  262.485870] snd_pcm_post_start: state 3
[  262.489898] snd_pcm_update_state: stream=0 avail=0 buffer_size=4000
twake=0 tsleep=1
[  262.500854] snd_pcm_lib_write1: state 3 size 1000
[  262.505828] omap_pcm_pointer: offset 64
[  262.509857] snd_pcm_update_hw_ptr0: old_hw_ptr=0 pos=64 in_int=0
[  262.516143] snd_pcm_update_hw_ptr0: stream=0 new_hw_ptr=64 silence_size=0
[  262.523284] snd_pcm_update_state: stream=0 avail=64 buffer_size=4000
twake=1000 tsleep=1
[  262.532226] snd_pcm_lib_write1: offset 0
[  262.536407] snd_pcm_lib_write1: state 3 size 936
[  262.541259] omap_pcm_pointer: offset 64
[  262.545288] snd_pcm_update_hw_ptr0: old_hw_ptr=64 pos=64 in_int=0
[  272.549896] ALSA sound/core/pcm_lib.c:1795: playback write error (DMA
or IRQ trouble?)
[  272.659851] snd_pcm_lib_write1: state 3 size 936
[  272.664703] omap_pcm_pointer: offset 64
[  272.668731] snd_pcm_update_hw_ptr0: old_hw_ptr=64 pos=64 in_int=0
[  282.674957] ALSA sound/core/pcm_lib.c:1795: playback write error (DMA
or IRQ trouble?)
aplay: pcm_write[  282.686767] omap_pcm_trigger: cmd 0
:1682: write error: Input/output error
# [  287.706268] pop wq checking: HiFi Playback status: inactive
waiting: yes
[  287.715148] max98095 4-0010: read 91 => c3
[  287.719726] max98095 4-0010: write 91 = 3
[  287.725585] max98095 4-0010: read 91 => 3
[  287.729980] max98095 4-0010: write 91 = 0
[  287.736785] max98095 4-0010: read 90 => c


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-16 18:07                 ` Steve Calfee
@ 2011-05-17  6:37                   ` Jarkko Nikula
  2011-05-19  1:06                     ` Steve Calfee
  2011-05-17 10:42                   ` Peter Ujfalusi
  1 sibling, 1 reply; 31+ messages in thread
From: Jarkko Nikula @ 2011-05-17  6:37 UTC (permalink / raw)
  To: Steve Calfee; +Cc: Peter Ujfalusi, Premi, Sanjeev, linux-omap, Girdwood, Liam

Hi

On Mon, 16 May 2011 11:07:40 -0700
Steve Calfee <stevecalfee@gmail.com> wrote:

> On 05/16/11 01:54, Peter Ujfalusi wrote:
> > On Saturday 14 May 2011 05:47:33 Steve Calfee wrote:
> >> I put in a few debug statements. It appears that my DMA never gets
> >> started. I know it can work with a different machine and codec driver,
> >> but not mine. I don't see any explicit DMA init, but that must be the
> >> problem.  Any more ideas?
> > 
> > You mean neither omap_pcm_hw_params nor omap_pcm_trigger got called?
> > Could you post the output of dmesg related to ASoC? Does the connection 
> > between the CPU and codec DAI correct?
> > Does McBSP part got initialized (for example does omap_mcbsp_dai_hw_params, 
> > omap_mcbsp_dai_trigger got called)?
> > 
> No, they get called. I just don't get the clock on the bclk pin.
> 
> I think I have the mcbsp1 set up correctly - I explictly set the MUX:
> 
> static struct omap_board_mux board_mux[] __initdata = {
> #if 1
> 	/* McBSP 1 */
> 	OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
> 	OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
> 	OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
> 	OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
> #endif
> 	{ .reg_offset = OMAP_MUX_TERMINATOR },
> };
> 
Did you try to run OMAP as an I2S master like what omap3pandora.c is
doing?

Missing clock in codec master configuration suggests that reason
is in codec side and reversed roles during development makes easier to
hunt it further as then OMAP can play data out independently of is the
codec correctly configured or not.

You could run OMAP as a master by specifying SND_SOC_DAIFMT_CBS_CFS
as a DAI format for both codec and OMAP and by setting McBSP to use
internal 96 MHz clock as a master clock. Something like below might work
for testing purposes:

snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLKS_FCLK,
		       96000000, SND_SOC_CLOCK_IN);

snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV,
		       62); /* 96M / 48k*32 */

-- 
Jarkko

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-16 18:07                 ` Steve Calfee
  2011-05-17  6:37                   ` Jarkko Nikula
@ 2011-05-17 10:42                   ` Peter Ujfalusi
  2011-05-19  0:30                     ` Steve Calfee
  1 sibling, 1 reply; 31+ messages in thread
From: Peter Ujfalusi @ 2011-05-17 10:42 UTC (permalink / raw)
  To: Steve Calfee; +Cc: Jarkko Nikula, Premi, Sanjeev, linux-omap, Girdwood, Liam

Hi,

On Monday 16 May 2011 21:07:40 Steve Calfee wrote:
> No, they get called. I just don't get the clock on the bclk pin.

OK.
Could you try to disconnect the CLKX, and FSX lines from OMAP, and see that 
you have the clocks on the codec side?
If in this way you still can not see the clocks, than your codec (max98095 ?) 
is not generating the clocks.
Could you also post from your machine driver how you configure the formats for 
cpu/codec DAI (snd_soc_dai_set_fmt call)?

While the clock lines are not physically connected, you can try to configure 
either side to generate the correct clocks on the lines. When you see that, 
you can connect them together, and see (hear) if it works.

-- 
Péter
--
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] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-17 10:42                   ` Peter Ujfalusi
@ 2011-05-19  0:30                     ` Steve Calfee
  2011-05-19 11:28                       ` Peter Ujfalusi
  0 siblings, 1 reply; 31+ messages in thread
From: Steve Calfee @ 2011-05-19  0:30 UTC (permalink / raw)
  To: Peter Ujfalusi; +Cc: Jarkko Nikula, Premi, Sanjeev, linux-omap, Girdwood, Liam

On 05/17/11 03:42, Peter Ujfalusi wrote:
> Hi,
> 
> On Monday 16 May 2011 21:07:40 Steve Calfee wrote:
>> No, they get called. I just don't get the clock on the bclk pin.
> 
> OK.
> Could you try to disconnect the CLKX, and FSX lines from OMAP, and see that 
> you have the clocks on the codec side?
> If in this way you still can not see the clocks, than your codec (max98095 ?) 
> is not generating the clocks.
> Could you also post from your machine driver how you configure the formats for 
> cpu/codec DAI (snd_soc_dai_set_fmt call)?
> 
> While the clock lines are not physically connected, you can try to configure 
> either side to generate the correct clocks on the lines. When you see that, 
> you can connect them together, and see (hear) if it works.
> 
Hi,

Good suggestion. After switching to my codec as master, I could see the
clocks. But one problem was the beagleboardxm trainer has level
shifters, but they are one directional, and not correct for my use. So I
reconnected to the expansion port pins (and re-did the voltage
requirement of the codec to 1.8 volts). Now I get some sound.

One problem remains and is a mystery to me. My omap setup with the
max98095 codec is identical to the on board twl4030 device. The twl4030
works find, but my codec only plays one channel.

I hooked up a logic analyzer and discovered that my codec sends 32 bit
clocks per fsx or what we call lrclk. The twl4030 sends 16 bit clocks
per lrclk. I think that more than 16 bits is supposed to be ok and
someone here said some of the high end audio test equipment only sends
64 bitclock per lrclock and that seems to be within the standard. I
think the I2S protocol says data bits are aligned with the lrclk, so
what should be happening is the omap slave should send 16 bits of audio
followed by 16 bits of null, then the lrclk switches and it should send
the other channel of audio followed by null.

The data being sent by the omap is actually 32 bits in the first lrclk
phase, comprising the left 16 bits and the right 16 bits. The second
lrclk phase gets null sent for all 32 bits. My 32 bits has the same data
(from the same .wav file) that was sent to the twl4030 as two 16 bit
channels.

Here is the mcbsp register dump (the same from both twl4030 and max98095
runs).

[   54.391174] omap_pcm_trigger: cmd 1
[   54.395111] omap_start_dma: lch 0
[   54.399047] omap-mcbsp omap-mcbsp.1: **** McBSP1 regs ****
[   54.404815] omap-mcbsp omap-mcbsp.1: DRR2:  0x2000100
[   54.410125] omap-mcbsp omap-mcbsp.1: DRR1:  0x0000
[   54.415130] omap-mcbsp omap-mcbsp.1: DXR2:  0x0000
[   54.420166] omap-mcbsp omap-mcbsp.1: DXR1:  0x0000
[   54.425201] omap-mcbsp omap-mcbsp.1: SPCR2: 0x0235
[   54.430206] omap-mcbsp omap-mcbsp.1: SPCR1: 0x0030
[   54.435241] omap-mcbsp omap-mcbsp.1: RCR2:  0x8041
[   54.440277] omap-mcbsp omap-mcbsp.1: RCR1:  0x0040
[   54.445281] omap-mcbsp omap-mcbsp.1: XCR2:  0x8041
[   54.450317] omap-mcbsp omap-mcbsp.1: XCR1:  0x0040
[   54.455352] omap-mcbsp omap-mcbsp.1: SRGR2: 0x001f
[   54.460388] omap-mcbsp omap-mcbsp.1: SRGR1: 0x0f00
[   54.465393] omap-mcbsp omap-mcbsp.1: PCR0:  0x000f
[   54.470428] omap-mcbsp omap-mcbsp.1: ***********************
[   54.476379] snd_pcm_post_start: state 3

My codec cannot be set to use only 16 bits per phase. Is there a way to
setup the omap so that data is sent to both channels? As you can see
above the xphase bit is one saying dual channels. Is this a dma setup
problem?

Thanks for your help.

Regards, Steve

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-17  6:37                   ` Jarkko Nikula
@ 2011-05-19  1:06                     ` Steve Calfee
  2011-05-20  0:58                       ` Steve Calfee
  0 siblings, 1 reply; 31+ messages in thread
From: Steve Calfee @ 2011-05-19  1:06 UTC (permalink / raw)
  To: Jarkko Nikula; +Cc: Peter Ujfalusi, Premi, Sanjeev, linux-omap, Girdwood, Liam

On 05/16/11 23:37, Jarkko Nikula wrote:
> Hi
> 
> On Mon, 16 May 2011 11:07:40 -0700
> Steve Calfee <stevecalfee@gmail.com> wrote:
> 
>> On 05/16/11 01:54, Peter Ujfalusi wrote:
>>> On Saturday 14 May 2011 05:47:33 Steve Calfee wrote:
>>>> I put in a few debug statements. It appears that my DMA never gets
>>>> started. I know it can work with a different machine and codec driver,
>>>> but not mine. I don't see any explicit DMA init, but that must be the
>>>> problem.  Any more ideas?
>>>
>>> You mean neither omap_pcm_hw_params nor omap_pcm_trigger got called?
>>> Could you post the output of dmesg related to ASoC? Does the connection 
>>> between the CPU and codec DAI correct?
>>> Does McBSP part got initialized (for example does omap_mcbsp_dai_hw_params, 
>>> omap_mcbsp_dai_trigger got called)?
>>>
>> No, they get called. I just don't get the clock on the bclk pin.
>>
>> I think I have the mcbsp1 set up correctly - I explictly set the MUX:
>>
>> static struct omap_board_mux board_mux[] __initdata = {
>> #if 1
>> 	/* McBSP 1 */
>> 	OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
>> 	OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
>> 	OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
>> 	OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
>> #endif
>> 	{ .reg_offset = OMAP_MUX_TERMINATOR },
>> };
>>
> Did you try to run OMAP as an I2S master like what omap3pandora.c is
> doing?
> 
> Missing clock in codec master configuration suggests that reason
> is in codec side and reversed roles during development makes easier to
> hunt it further as then OMAP can play data out independently of is the
> codec correctly configured or not.
> 
> You could run OMAP as a master by specifying SND_SOC_DAIFMT_CBS_CFS
> as a DAI format for both codec and OMAP and by setting McBSP to use
> internal 96 MHz clock as a master clock. Something like below might work
> for testing purposes:
> 
> snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLKS_FCLK,
> 		       96000000, SND_SOC_CLOCK_IN);
> 
> snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV,
> 		       62); /* 96M / 48k*32 */
> 
Hi,

The hunt for clock continues. I redid my board-omap3beaglexm.c to as
closely match what board-omap3pandora.c is doing as I can. Like pandora,
I don't explicitly set the mux pin directions, I guess mcbsp master is
the default.

I also tried to get as close as I could to the soc/omap/omap3pandora.c
machine driver with my omap3beaglexm.c machine driver. Specifically in
the *_hw_params init routines.

But when I start things up (even with the codec disconnected from the
bclk line), I don't get any movement on the CLK and fsx. And of course
the dma doesn't send anything.

Thanks for the suggestion.

Regards, Steve


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-19  0:30                     ` Steve Calfee
@ 2011-05-19 11:28                       ` Peter Ujfalusi
  2011-05-19 23:58                         ` Steve Calfee
  0 siblings, 1 reply; 31+ messages in thread
From: Peter Ujfalusi @ 2011-05-19 11:28 UTC (permalink / raw)
  To: Steve Calfee
  Cc: Jarkko Nikula, Premi, Sanjeev, linux-omap, Girdwood, Liam, Peter Hsiang

Hi,

On Thursday 19 May 2011 03:30:51 Steve Calfee wrote:
> On 05/17/11 03:42, Peter Ujfalusi wrote:
> Good suggestion. After switching to my codec as master, I could see the
> clocks. But one problem was the beagleboardxm trainer has level
> shifters, but they are one directional, and not correct for my use. So I
> reconnected to the expansion port pins (and re-did the voltage
> requirement of the codec to 1.8 volts). Now I get some sound.

Great, we are getting closer.

...

> My codec cannot be set to use only 16 bits per phase. Is there a way to
> setup the omap so that data is sent to both channels? As you can see
> above the xphase bit is one saying dual channels. Is this a dma setup
> problem?

I can not find datasheet for the max98095...
So you can not configure the codec to use 2x16 number of bit clocks. when it 
is configured to receive/send 16bit stereo samples?
Is this the case (that the codec all the time have 32 clock cycles per 
channel)? 

If this is the case, than it is kind of tricky to get around this, but you can 
try the following (warning: hack):

In the codec driver:
create/add a startup callback function for the dais (snd_soc_dai_ops):

static int max98095_startup(struct snd_pcm_substream *substream,
			   struct snd_soc_dai *dai)
{
	snd_pcm_hw_constraint_msbits(substream->runtime, 0, 32, 16);

	return 0;
}

Modify the MAX98095_FORMATS to only support S32_LE (remove the other formats 
for now)

In the hw_params calls handle the S32_LE in a same way as you handle the 
S16_LE.

To explain what we are doing:
Configure the codec to support only S32_LE format, but tell ALSA, that out of 
the 32 bit only the first 16bit is valid.
So the driver will be opened with S32_LE mode, but only the first 16 bits will 
have audio data:
0-15: Left audio
16-31: zero (padding on left channel)
32-47: Right audio
48-63: zero (padding on right channel)

Use aplay -Dplughw:0,0 -v <some sample> to play audio, and see, if the HW has 
been opened with S32_LE.

You should have full stereo sound now.

I have CC-d the author of the wm98095 codec driver, hi might be able to help 
you with the codec setup...

-- 
Péter
--
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] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-19 11:28                       ` Peter Ujfalusi
@ 2011-05-19 23:58                         ` Steve Calfee
  2011-05-20  6:56                           ` Peter Ujfalusi
  0 siblings, 1 reply; 31+ messages in thread
From: Steve Calfee @ 2011-05-19 23:58 UTC (permalink / raw)
  To: Peter Ujfalusi
  Cc: Jarkko Nikula, Premi, Sanjeev, linux-omap, Girdwood, Liam, Peter Hsiang

On 05/19/11 04:28, Peter Ujfalusi wrote:
...
> 
>> My codec cannot be set to use only 16 bits per phase. Is there a way to
>> setup the omap so that data is sent to both channels? As you can see
>> above the xphase bit is one saying dual channels. Is this a dma setup
>> problem?
> 
> I can not find datasheet for the max98095...
> So you can not configure the codec to use 2x16 number of bit clocks. when it 
> is configured to receive/send 16bit stereo samples?
Correct, I can set bit clock to 64*lrclk, 48*lrclk, 128*lrclk, 17*lrclk,
and 18*lrclk. The audio folks here think that it is normal to send more
than required bit clocks, data is sent first so just ignore the rest.

It would appear that the mcbsp doesn't really use the lrclk (I think
called FSX), it just uses a positive transition to start the bit
shifting for all the requested bits. The falling edge does not start the
right channel, the shifter keeps going until all requested l/r counts
have been sent.

Or maybe something in the mcbsp has not been set up correctly?

> Is this the case (that the codec all the time have 32 clock cycles per 
> channel)? 
> 
> If this is the case, than it is kind of tricky to get around this, but you can 
> try the following (warning: hack):
> 
> In the codec driver:
> create/add a startup callback function for the dais (snd_soc_dai_ops):
> 
> static int max98095_startup(struct snd_pcm_substream *substream,
> 			   struct snd_soc_dai *dai)
> {
> 	snd_pcm_hw_constraint_msbits(substream->runtime, 0, 32, 16);
> 
> 	return 0;
> }
> 
> Modify the MAX98095_FORMATS to only support S32_LE (remove the other formats 
> for now)
> 
> In the hw_params calls handle the S32_LE in a same way as you handle the 
> S16_LE.
> 
> To explain what we are doing:
> Configure the codec to support only S32_LE format, but tell ALSA, that out of 
> the 32 bit only the first 16bit is valid.
> So the driver will be opened with S32_LE mode, but only the first 16 bits will 
> have audio data:
> 0-15: Left audio
> 16-31: zero (padding on left channel)
> 32-47: Right audio
> 48-63: zero (padding on right channel)
> 
> Use aplay -Dplughw:0,0 -v <some sample> to play audio, and see, if the HW has 
> been opened with S32_LE.
> 
> You should have full stereo sound now.
>
I do, thanks. I am truly amazed that I was able to follow your
instructions and get it to work first time. You must really know your
alsa machine implementation.


The problem is that now I cannot run 44.1Khz audio, I get underruns. I
am guessing that software is expanding the samples from 16 bits to 32?
Without your hack 44.1Khz audio works fine (but only audible in the
first channel).


> I have CC-d the author of the wm98095 codec driver, hi might be able to help 
> you with the codec setup...
> 

I talk to Peter every day. He brought up the codec, I am trying to use
the Beagleboardxm as a generic Linux platform for new codec bringups and
for following kernel and alsa cutting edge software.

Regards, Steve

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-19  1:06                     ` Steve Calfee
@ 2011-05-20  0:58                       ` Steve Calfee
  2011-05-20  6:29                         ` Jarkko Nikula
  0 siblings, 1 reply; 31+ messages in thread
From: Steve Calfee @ 2011-05-20  0:58 UTC (permalink / raw)
  To: Jarkko Nikula; +Cc: Peter Ujfalusi, Premi, Sanjeev, linux-omap, Girdwood, Liam

On 05/18/11 18:06, Steve Calfee wrote:
> On 05/16/11 23:37, Jarkko Nikula wrote:
>>>
>> Did you try to run OMAP as an I2S master like what omap3pandora.c is
>> doing?
>>
>> Missing clock in codec master configuration suggests that reason
>> is in codec side and reversed roles during development makes easier to
>> hunt it further as then OMAP can play data out independently of is the
>> codec correctly configured or not.
>>
>> You could run OMAP as a master by specifying SND_SOC_DAIFMT_CBS_CFS
>> as a DAI format for both codec and OMAP and by setting McBSP to use
>> internal 96 MHz clock as a master clock. Something like below might work
>> for testing purposes:
>>
>> snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_SYSCLK_CLKS_FCLK,
>> 		       96000000, SND_SOC_CLOCK_IN);
>>
>> snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV,
>> 		       62); /* 96M / 48k*32 */
>>
> Hi,
> 
> The hunt for clock continues. I redid my board-omap3beaglexm.c to as
> closely match what board-omap3pandora.c is doing as I can. Like pandora,
> I don't explicitly set the mux pin directions, I guess mcbsp master is
> the default.
> 
> I also tried to get as close as I could to the soc/omap/omap3pandora.c
> machine driver with my omap3beaglexm.c machine driver. Specifically in
> the *_hw_params init routines.
> 
> But when I start things up (even with the codec disconnected from the
> bclk line), I don't get any movement on the CLK and fsx. And of course
> the dma doesn't send anything.
> 

I have gotten mcbsp1 to work as a slave (sort-of) with Peter's help. I
havent been able to get it to clock as a master. So now I try with
mcbsp3, still no luck.

More missing mcbsp bit clock. I am trying on mcbsp3. I am trying to get
master mode working. Here is the register dump from the console (I have
some debug printouts on).

[   30.039978] snd_pcm_do_start: state 3
[   30.043823] omap_pcm_trigger: cmd 1
[   30.047760] omap_start_dma: lch 0
[   30.051696] omap-mcbsp omap-mcbsp.3: **** McBSP3 regs ****
[   30.057464] omap-mcbsp omap-mcbsp.3: DRR2:  0x2820d81
[   30.062774] omap-mcbsp omap-mcbsp.3: DRR1:  0x0000
[   30.067779] omap-mcbsp omap-mcbsp.3: DXR2:  0x0000
[   30.072814] omap-mcbsp omap-mcbsp.3: DXR1:  0x0000
[   30.077850] omap-mcbsp omap-mcbsp.3: SPCR2: 0x02f5
[   30.082885] omap-mcbsp omap-mcbsp.3: SPCR1: 0x0030
[   30.087890] omap-mcbsp omap-mcbsp.3: RCR2:  0x80a1
[   30.092926] omap-mcbsp omap-mcbsp.3: RCR1:  0x00a0
[   30.097961] omap-mcbsp omap-mcbsp.3: XCR2:  0x80a1
[   30.102966] omap-mcbsp omap-mcbsp.3: XCR1:  0x00a0
[   30.108001] omap-mcbsp omap-mcbsp.3: SRGR2: 0x10c0
[   30.113037] omap-mcbsp omap-mcbsp.3: SRGR1: 0x5f3d
[   30.118041] omap-mcbsp omap-mcbsp.3: PCR0:  0x0f0f
[   30.123077] omap-mcbsp omap-mcbsp.3: ***********************




My BSP sets up the mux for mcbsp3:

#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
#if 1
	/* McBSP 1 slave */
	OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
	OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
	OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
	OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
#else
	/* McBSP 1 master */
	OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
	OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
	OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
	OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
#endif
	/* McBSP 3 master */
	OMAP3_MUX(MCBSP3_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
	OMAP3_MUX(MCBSP3_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
	OMAP3_MUX(MCBSP3_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
	OMAP3_MUX(MCBSP3_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
	{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif

And with the mcbsp 4 pins not connected to anything but the scope, I
don't see any bitclock movement. I think others used u-boot to setup the
mcbspx, but has anyone successfully used linux to set up the pins?

Thanks, Steve

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-20  0:58                       ` Steve Calfee
@ 2011-05-20  6:29                         ` Jarkko Nikula
  2011-05-20  7:03                           ` Peter Ujfalusi
  2011-05-21  0:55                           ` Steve Calfee
  0 siblings, 2 replies; 31+ messages in thread
From: Jarkko Nikula @ 2011-05-20  6:29 UTC (permalink / raw)
  To: Steve Calfee; +Cc: Peter Ujfalusi, Premi, Sanjeev, linux-omap, Girdwood, Liam

On Thu, 19 May 2011 17:58:56 -0700
Steve Calfee <stevecalfee@gmail.com> wrote:

> > I also tried to get as close as I could to the soc/omap/omap3pandora.c
> > machine driver with my omap3beaglexm.c machine driver. Specifically in
> > the *_hw_params init routines.
> > 
> > But when I start things up (even with the codec disconnected from the
> > bclk line), I don't get any movement on the CLK and fsx. And of course
> > the dma doesn't send anything.
> > 
> 
> I have gotten mcbsp1 to work as a slave (sort-of) with Peter's help. I
> havent been able to get it to clock as a master. So now I try with
> mcbsp3, still no luck.
> 
This very likely sounds that in master mode the master clock to McBSP is
missing if there is no DMA running. Did you try to use internal 96 MHz
from my example or did you try to use external CLKS what Pandora is
using? That CLKS setup in Pandora requires that there is a clock coming
to McBSP CLKS pin.

But as you got codec slave mode working it seems that pin multiplexing
is ok so there is no need to try with master mode. In problematic cases
the master mode is a good start since then only McBSP clock setup and
pin multiplexing can affect if there are no clock and data signals
visible.

> And with the mcbsp 4 pins not connected to anything but the scope, I
> don't see any bitclock movement. I think others used u-boot to setup the
> mcbspx, but has anyone successfully used linux to set up the pins?
> 
Yep, in a couple omap boards. Remember that for kernel based
multiplexing the CONFIG_OMAP_MUX=y must be set.

-- 
Jarkko

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-19 23:58                         ` Steve Calfee
@ 2011-05-20  6:56                           ` Peter Ujfalusi
  0 siblings, 0 replies; 31+ messages in thread
From: Peter Ujfalusi @ 2011-05-20  6:56 UTC (permalink / raw)
  To: Steve Calfee
  Cc: Jarkko Nikula, Premi, Sanjeev, linux-omap, Girdwood, Liam, Peter Hsiang

On Friday 20 May 2011 02:58:30 Steve Calfee wrote:
> On 05/19/11 04:28, Peter Ujfalusi wrote:
> Correct, I can set bit clock to 64*lrclk, 48*lrclk, 128*lrclk, 17*lrclk,
> and 18*lrclk.

Strange, that there is no option for 32*lrclk.

> The audio folks here think that it is normal to send more
> than required bit clocks, data is sent first so just ignore the rest.

Yes, it is allowed. The rest should be ignored.
But I'm afraid, OMAP McBSP can not handle this in a way you (and me) wanted 
to.

> It would appear that the mcbsp doesn't really use the lrclk (I think
> called FSX), it just uses a positive transition to start the bit
> shifting for all the requested bits. The falling edge does not start the
> right channel, the shifter keeps going until all requested l/r counts
> have been sent.

Yeah, McBSP only cares about the start condition, it does not care about the 
right channel FSX transition.
This is the reason it is not possible to handle the scenario you are aiming 
for.
At start condition, it just start to send the data stream (frame1 followed by 
frame2 in dual-phase mode - in single phase mode it can send up to 128 
frames).
Having said that, there might be a way to actually work this around with 
McBSP's multichannel mode. Configuring it for 4 slots, and only shift data for 
slot 0, and 2 in case of your setup (16bit data within 32 bitclocks).
It is a long shot, I can not promise that I can take a look right away, but if 
you have time.... ;)

> > You should have full stereo sound now.
> 
> I do, thanks.

Cool :D

> I am truly amazed that I was able to follow your
> instructions and get it to work first time. You must really know your
> alsa machine implementation.

Thanks, I try.

> The problem is that now I cannot run 44.1Khz audio, I get underruns. I
> am guessing that software is expanding the samples from 16 bits to 32?
> Without your hack 44.1Khz audio works fine (but only audible in the
> first channel).

Hmm. I have used similar mode with twl4030, and tlv320dac33 (S32_LE with 
24msbits) without issues with underrun. Let's see.
Can you check /sys/devices/platform/omap-mcbsp.X/dma_op_mode, max_tx_thres for 
your McBSP port?
I would suggest to switch the dma_op_mode to threshold mode in any port.

When you play audio try to use bigger periods, something like 10ms:
aplay -Dplughw:0,0 --period-time=10000 -v <your sample>

Replace the -Dplughw:0,0 to point to the wm98095 PCM.

Could you post the output of aplay?

> I talk to Peter every day. He brought up the codec, I am trying to use
> the Beagleboardxm as a generic Linux platform for new codec bringups and
> for following kernel and alsa cutting edge software.

Make sense..

-- 
Péter
--
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] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-20  6:29                         ` Jarkko Nikula
@ 2011-05-20  7:03                           ` Peter Ujfalusi
  2011-05-21  0:55                           ` Steve Calfee
  1 sibling, 0 replies; 31+ messages in thread
From: Peter Ujfalusi @ 2011-05-20  7:03 UTC (permalink / raw)
  To: Jarkko Nikula; +Cc: Steve Calfee, Premi, Sanjeev, linux-omap, Girdwood, Liam

Hi,

On Friday 20 May 2011 09:29:11 Jarkko Nikula wrote:
> This very likely sounds that in master mode the master clock to McBSP is
> missing if there is no DMA running.

If the clock setup is correct for McBSP, than it runs the clocks, and shifts 
out data.

> Did you try to use internal 96 MHz
> from my example or did you try to use external CLKS what Pandora is
> using? That CLKS setup in Pandora requires that there is a clock coming
> to McBSP CLKS pin.

Really good point. PRCM/CORE (depending on the McBSP port) 96M_FCLK must be 
used here.

-- 
Péter
--
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] 31+ messages in thread

* Re: beagleboardxm 2.6.39rc4 mcbsp problems.
  2011-05-20  6:29                         ` Jarkko Nikula
  2011-05-20  7:03                           ` Peter Ujfalusi
@ 2011-05-21  0:55                           ` Steve Calfee
  1 sibling, 0 replies; 31+ messages in thread
From: Steve Calfee @ 2011-05-21  0:55 UTC (permalink / raw)
  To: Jarkko Nikula; +Cc: Peter Ujfalusi, Premi, Sanjeev, linux-omap, Girdwood, Liam

On 05/19/11 23:29, Jarkko Nikula wrote:
> On Thu, 19 May 2011 17:58:56 -0700
> Steve Calfee <stevecalfee@gmail.com> wrote:
> 
...
>>
> This very likely sounds that in master mode the master clock to McBSP is
> missing if there is no DMA running. Did you try to use internal 96 MHz
> from my example or did you try to use external CLKS what Pandora is
> using? That CLKS setup in Pandora requires that there is a clock coming
> to McBSP CLKS pin.
> 
> But as you got codec slave mode working it seems that pin multiplexing
> is ok so there is no need to try with master mode. In problematic cases
> the master mode is a good start since then only McBSP clock setup and
> pin multiplexing can affect if there are no clock and data signals
> visible.
> 

OK, you called this correctly. Apparently the beagle does not by default
have a clock on the clks pin. When I correctly followed your suggestion
and changed to the internal 96,000,000 clock I do get transitions on the
mcbsp1 clk and fsx pins.

The problem is 96M is pretty big. the only divisor I see is 8 bits, your
suggested division (else where of 62) only brings the bit clock rate to
about 15Mhz. the frame clock did get set very near the 8Khz for the
sample playback. So about 1900 bit clocks are sent per frame.

This would be ok, but since the mcbsp does not respect the l/r clock
(FSX) for shifting out data, I am back to getting audio on only one ear.
I was hoping that in master mode I could configure the mcbsp to only
send 16 bit clocks per frame. It looks like the clocks are not that
configurable.

The external clks pin is supposed to be connect to an external TPS65950
chip which divides down the source 26Mhz clock by 256. I'll have to
investigate why I was not seeing that clock.

Regards, Steve

^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2011-05-21  0:55 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-11 13:55 [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type Sanjeev Premi
2011-05-11 13:55 ` Sanjeev Premi
2011-05-11 13:57 ` Mark Brown
2011-05-11 13:57   ` Mark Brown
2011-05-11 14:44 ` Peter Ujfalusi
2011-05-11 14:44   ` [alsa-devel] " Peter Ujfalusi
2011-05-11 15:38 ` Jarkko Nikula
2011-05-11 15:38   ` Jarkko Nikula
2011-05-11 18:16 ` [alsa-devel] " Steve Calfee
2011-05-11 19:19   ` Premi, Sanjeev
2011-05-11 21:31   ` beagleboardxm 2.6.39rc4 mcbsp problems Steve Calfee
2011-05-12  6:25     ` Jarkko Nikula
2011-05-12 11:01       ` Peter Ujfalusi
2011-05-12 18:43         ` Steve Calfee
2011-05-13  5:59           ` Peter Ujfalusi
2011-05-14  2:47             ` Steve Calfee
2011-05-16  8:54               ` Peter Ujfalusi
2011-05-16 18:07                 ` Steve Calfee
2011-05-17  6:37                   ` Jarkko Nikula
2011-05-19  1:06                     ` Steve Calfee
2011-05-20  0:58                       ` Steve Calfee
2011-05-20  6:29                         ` Jarkko Nikula
2011-05-20  7:03                           ` Peter Ujfalusi
2011-05-21  0:55                           ` Steve Calfee
2011-05-17 10:42                   ` Peter Ujfalusi
2011-05-19  0:30                     ` Steve Calfee
2011-05-19 11:28                       ` Peter Ujfalusi
2011-05-19 23:58                         ` Steve Calfee
2011-05-20  6:56                           ` Peter Ujfalusi
2011-05-13 12:13 ` [PATCH] ASoC: omap-mcbsp: Remove restrictive checks for cpu type Liam Girdwood
2011-05-13 12:13   ` Liam Girdwood

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.