trouble with alsa, wolfson, and TI OMAP35xx McBSP

trouble with alsa, wolfson, and TI OMAP35xx McBSP

[twebb]

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

I'm having difficulties getting a Wolfson codec running on McBSP1 of
an OMAP 35xx.  Here are the particulars:

1) Using Linux kernel 2.6.27-omap1, with an ALSA sound driver ported
from a Wolfson supplied source tree labeled 2.6.29 (“dev” branch)
2) Using the TI OMAP3530 SOC married to a Wolfson WM8978 codec via
McBSP1. I2C control, I2S pcm data.
3) We are running the codec digital block at 1.8V and the analog block at 3.3V
4) The WM8978 codec is synthesizing FCLK and BCLK, codec is the
master. McBsp is the slave.
5) FCLK=44.1KHz, BCLK= 32 * FCLK, MCLK = 13Mhz
6) Framing is I2S stereo, 16 bit word

I'm seeing two main problems:

Problem 1:
The WM8978 sample rate PLL does not seem to be stable while DCVDD =
DBVDD = 1.8V.  FCLK mean = 44.5KHz and jittering. Increasing DCVDD and
DBVDD voltage above 2V increases PLL stability. We have a workaround
for this for now.

Problem 2:
Test tone is being presented by the user application, providing a 1Khz
tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left
channel is quiet. The data seems to slip back and forth from left to
right channel. This is reproducable and verified with a scope trace.

Anybody have any ideas what might be going wrong here?  Traces for
codec reg dump and mcbsp are attached.

Thanks,
twebb

[-- Attachment #2: codec_regs.txt --]
[-- Type: text/plain, Size: 642 bytes --]

omap2_dma_handle_ch: new DMA IRQ for lch 0
WM8978 registers
 0:    0
 1:  1fd
 2:  1bf
 3:  1ef
 4:   10
 5:    0
 6:  16d
 7:    0
 8:    0
 9:    0
 a:   40
 b:   ff
 c:   ff
 d:    0
 e:  100
 f:   ff
10:   ff
11:    0
12:  12c
13:   2c
14:   2c
15:   2c
16:   2c
17:    0
18:   32
19:    0
1a:    0
1b:    0
1c:    0
1d:    0
1e:    0
1f:    0
20:   38
21:    b
22:   32
23:    0
24:    a
25:   1a
26:  1e8
27:  1bf
28:    0
29:    0
2a:    0
2b:    0
2c:   33
2d:   10
2e:   10
2f:  100
30:  100
31:    2
32:    1
33:    1
34:   39
35:   39
36:   39
37:   39
38:    1
39:    1

[-- Attachment #3: mcbsp_trace.txt --]
[-- Type: text/plain, Size: 4445 bytes --]


<6>omap_mcbsp_dai_startup: cpu_dai_active: 0 cpu_dai:c0351900 c039a71c mcbsp_data->bus_id = 0 err = 0
omap_mcbsp_dai_startup: cpu_dai_active: 0 cpu_dai:c0351900 c039a71c mcbsp_data->bus_id = 0 err = 0
<6>omap_mcbsp_request: id = 0
omap_mcbsp_request: id = 0
<6>omap2_mcbsp_request: id = 0
omap2_mcbsp_request: id = 0
<6>omap_mcbsp_request: returns 0
omap_mcbsp_request: returns 0
wm8978_write: addr: 0x06 (6) val: 16d
wm8978_write: addr: 0x06 (6) val: 16d
wm8978_write: addr: 0x04 (4) val: 010
wm8978_write: addr: 0x04 (4) val: 010
<6>omap_mcbsp_dai_set_fmt: format: 00000000 dai format: SND_SOC_DAIFMT_I2S
omap_mcbsp_dai_set_fmt: format: 00000000 dai format: SND_SOC_DAIFMT_I2S
<6>snd_soc_set_pll: 11289600
snd_soc_set_pll: 11289600
wm8978_write: addr: 0x24 (36) val: 00a
wm8978_write: addr: 0x24 (36) val: 00a
wm8978_write: addr: 0x25 (37) val: 01a
wm8978_write: addr: 0x25 (37) val: 01a
wm8978_write: addr: 0x26 (38) val: 1e8
wm8978_write: addr: 0x26 (38) val: 1e8
wm8978_write: addr: 0x27 (39) val: 1bf
wm8978_write: addr: 0x27 (39) val: 1bf
<6>wm8978_set_dai_clkdiv: div_id = WM8978_MCLKDIV div = 0060
wm8978_set_dai_clkdiv: div_id = WM8978_MCLKDIV div = 0060
wm8978_write: addr: 0x06 (6) val: 16d
wm8978_write: addr: 0x06 (6) val: 16d
<6>wm8978_set_dai_clkdiv: div_id = WM8978_BCLKDIV div = 000c
wm8978_set_dai_clkdiv: div_id = WM8978_BCLKDIV div = 000c
wm8978_write: addr: 0x06 (6) val: 16d
wm8978_write: addr: 0x06 (6) val: 16d
wm8978_write: addr: 0x01 (1) val: 1fd
wm8978_write: addr: 0x01 (1) val: 1fd
<6>wm8978_set_dai_clkdiv: div_id = WM8978_MCLKSEL div = 0100
wm8978_set_dai_clkdiv: div_id = WM8978_MCLKSEL div = 0100
wm8978_write: addr: 0x06 (6) val: 16d
wm8978_write: addr: 0x06 (6) val: 16d
<6>omap_mcbsp_dai_set_dai_sysclk: clk_id = OMAP_MCBSP_SYSCLK_CLKX_EXT
omap_mcbsp_dai_set_dai_sysclk: clk_id = OMAP_MCBSP_SYSCLK_CLKX_EXT
<6>omap_mcbsp_dai_set_clkdiv:
omap_mcbsp_dai_set_clkdiv:
wm8978_write: addr: 0x04 (4) val: 010
wm8978_write: addr: 0x04 (4) val: 010
wm8978_write: addr: 0x07 (7) val: 000
wm8978_write: addr: 0x07 (7) val: 000
<6>omap_mcbsp_dai_hw_params:
omap_mcbsp_dai_hw_params:
<6>omap_mcbsp_dai_hw_params: channels = 2
omap_mcbsp_dai_hw_params: channels = 2
<6>omap_mcbsp_config: id = 0
omap_mcbsp_config: id = 0
<7>omap-mcbsp omap-mcbsp.1: Configuring McBSP1  phys_base: 0x48074000
<4>omap_pcm_prepare: enable irq for dma_ch 0
omap_pcm_prepare: enable irq for dma_ch 0
wm8978_write: addr: 0x01 (1) val: 1fd
wm8978_write: addr: 0x01 (1) val: 1fd
wm8978_write: addr: 0x02 (2) val: 1bf
wm8978_write: addr: 0x02 (2) val: 1bf
wm8978_write: addr: 0x03 (3) val: 1ef
wm8978_write: addr: 0x03 (3) val: 1ef
wm8978_write: addr: 0x0a (10) val: 000
wm8978_write: addr: 0x0a (10) val: 000
<6>omap_mcbsp_dai_trigger: cmd = SNDRV_PCM_TRIGGER_START
omap_mcbsp_dai_trigger: cmd = SNDRV_PCM_TRIGGER_START
<6>omap_mcbsp_start: id = 0
omap_mcbsp_start: id = 0
<7>omap-mcbsp omap-mcbsp.1: **** McBSP1 regs ****
<7>omap-mcbsp omap-mcbsp.1: DRR2:  0xfff7
<7>omap-mcbsp omap-mcbsp.1: DRR1:  0x0000
<7>omap-mcbsp omap-mcbsp.1: DXR2:  0x0000
<7>omap-mcbsp omap-mcbsp.1: DXR1:  0x0000
<7>omap-mcbsp omap-mcbsp.1: SPCR2: 0x02f5
<7>omap-mcbsp omap-mcbsp.1: SPCR1: 0x0037
<7>omap-mcbsp omap-mcbsp.1: RCR2:  0x8041
<7>omap-mcbsp omap-mcbsp.1: RCR1:  0x0040
<7>omap-mcbsp omap-mcbsp.1: XCR2:  0x8041
<7>omap-mcbsp omap-mcbsp.1: XCR1:  0x0040
<7>omap-mcbsp omap-mcbsp.1: SRGR2: 0x201f
<7>omap-mcbsp omap-mcbsp.1: SRGR1: 0x0f01
<7>omap-mcbsp omap-mcbsp.1: PCR0:  0x008f
<7>omap-mcbsp omap-mcbsp.1: ***********************
<6>omap_mcbsp_dai_trigger: return 0
omap_mcbsp_dai_trigger: return 0
<4>__ratelimit: 20 callbacks suppressed
__ratelimit: 20 callbacks suppressed
<4>omap2_dma_handle_ch: new DMA IRQ for lch 0
omap2_dma_handle_ch: new DMA IRQ for lch 0
<4>omap_pcm_dma_irq: dma_ch 0
omap_pcm_dma_irq: dma_ch cbsp_dai_trigger: cmd = SNDRV_PCM_TRIGGER_STOP
omap_mcbsp_dai_trigger: cmd = SNDRV_PCM_TRIGGER_STOP
<6>omap_mcbsp_stop: id = 0
omap_mcbsp_stop: id = 0
<6>omap_mcbsp_dai_trigger: return 0
omap_mcbsp_dai_trigger: return 0
<4>omap2_dma_handle_ch: new DMA IRQ for lch 0
omap2_dma_handle_ch: new DMA IRQ for lch 0
<4>omap_pcm_dma_irq: dma_ch 0
omap_pcm_dma_irq: dma_ch 0
<4>omap_pcm_prepare: enable irq for dma_ch 0
omap_pcm_prepare: enable irq for dma_ch 0
wm8978_write: addr: 0x0a (10) val: 000
wm8978_write: addr: 0x0a (10) val: 000

RE: trouble with alsa, wolfson, and TI OMAP35xx McBSP

[Menon, Nishanth]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of twebb
> Sent: Wednesday, April 22, 2009 12:58 PM

> Problem 2:
> Test tone is being presented by the user application, providing a 1Khz
> tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left
> channel is quiet. The data seems to slip back and forth from left to
> right channel. This is reproducable and verified with a scope trace.
I recollect this issue from years back of OSS driver -> i2s is configured as dual phase - mcbsp sends data on both edges, and if the data write happen on the wrong edge for the wrong phase, we might get mix up.. if I recollect right, configuration for mcbsp was done as a single phase with the right edge as a trigger for transfer, the transfer size was set as 32 bytes (both channels).. this essentially guarentees that mcbsp will never mix up channels.

Regards,
Nishanth Menon

Re: [alsa-devel] trouble with alsa, wolfson, and TI OMAP35xx McBSP

[Mark Brown]

On Wed, Apr 22, 2009 at 01:58:01PM -0400, twebb wrote:

> Problem 1:
> The WM8978 sample rate PLL does not seem to be stable while DCVDD =
> DBVDD = 1.8V.  FCLK mean = 44.5KHz and jittering. Increasing DCVDD and
> DBVDD voltage above 2V increases PLL stability. We have a workaround
> for this for now.

Can I suggest that you contact Wolfson's applications support team
regarding this issue - there's a web form at:

	http://www.wolfsonmicro.com/support/technical/

Looking at the datasheet the PLL is specified as requiring a minimum of
1.9V - see page 6 of:

	http://www.wolfsonmicro.com/uploads/documents/en/WM8978_Rev4.3.pdf

> Problem 2:
> Test tone is being presented by the user application, providing a 1Khz
> tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left
> channel is quiet. The data seems to slip back and forth from left to
> right channel. This is reproducable and verified with a scope trace.

> Anybody have any ideas what might be going wrong here?  Traces for
> codec reg dump and mcbsp are attached.

There have been some recent threads on this list regarding the
configuration of the McBSP port configuration for various formats - it's
probably worth checking the latest changes to the OMAP code in the
topic/asoc branch of:

	git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git

That said, I2S with the CODEC as clock master is one of the most common
configurations for OMAP so I'd expect it to be well tested.  Have you
tried testing recording?

Also CCing in Peter and Jarkko, our resident OMAP audio experts.

Re: trouble with alsa, wolfson, and TI OMAP35xx McBSP

[Jarkko Nikula]

On Wed, 22 Apr 2009 20:05:40 +0200
"ext Menon, Nishanth" <nm@ti.com> wrote:

> > Test tone is being presented by the user application, providing a
> > 1Khz tone sampled at 44.1Khz. The data are S16_LE, right channel
> > only. Left channel is quiet. The data seems to slip back and forth
> > from left to right channel. This is reproducable and verified with
> > a scope trace.
>
Is this slipping happening in middle of playback or between the tracks?

> I recollect this issue from years back of OSS driver -> i2s is
> configured as dual phase - mcbsp sends data on both edges, and if the
> data write happen on the wrong edge for the wrong phase, we might get
> mix up.. if I recollect right, configuration for mcbsp was done as a
> single phase with the right edge as a trigger for transfer, the
> transfer size was set as 32 bytes (both channels).. this essentially
> guarentees that mcbsp will never mix up channels.
> 
Thanks Menon! This is sounds a information we should try out. OMAP2420
in N810 is especially suffering from channel swapping between the
tracks and I haven't found time to look any deeper :-(

I know there is a fix for DaVinci (commit
fb0ef645f2c546f8297b2fbf9b2b8fff4a7455e8) but I would like to find
out are there any other or simpler way to fix it than mixing DMA and DAI
setup.


Jarkko

Re: trouble with alsa, wolfson, and TI OMAP35xx McBSP

[Peter Ujfalusi]

On Wednesday 22 April 2009 20:58:01 ext twebb wrote:
> Problem 2:
> Test tone is being presented by the user application, providing a 1Khz
> tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left
> channel is quiet. The data seems to slip back and forth from left to
> right channel. This is reproducable and verified with a scope trace.
>
> Anybody have any ideas what might be going wrong here?  Traces for
> codec reg dump and mcbsp are attached.

As Jarkko already asked: are you seeing the channel switch while running or is 
it happens on playback start?

AFAIK this phenomena can be also seen on Beagle board.

I have done some investigation regarding to these, but so far I can not say 
that I know what causes it.

BTW: these are separate issues (startup switch and runtime switch).

> Thanks,
> twebb

-- 
Péter

Re: trouble with alsa, wolfson, and TI OMAP35xx McBSP

[Alan Horstmann]

On Thursday 23 April 2009 10:20, Peter Ujfalusi wrote:
> On Wednesday 22 April 2009 20:58:01 ext twebb wrote:
> > Problem 2:
> > Test tone is being presented by the user application, providing a 1Khz
> > tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left
> > channel is quiet. The data seems to slip back and forth from left to
> > right channel. This is reproducable and verified with a scope trace.
> >
> > Anybody have any ideas what might be going wrong here?  Traces for
> > codec reg dump and mcbsp are attached.
>
> As Jarkko already asked: are you seeing the channel switch while running or
> is it happens on playback start?
>
> AFAIK this phenomena can be also seen on Beagle board.
>
> I have done some investigation regarding to these, but so far I can not say
> that I know what causes it.
>
> BTW: these are separate issues (startup switch and runtime switch).

I just want to declare an interest in this investigation.  Many months back I 
was working on a SAM9260 board with wm8731 codec; the project is rather 
'background' at present.  One of the outstanding unresolved (not really 
investigated much either) issues was of channel swapping at start of capture 
or playback.  It never changed during operation, but each start time the 
channels would be randomly correct or swapped.

Does this indicate that the implementation/drivers of i2s has a fundamental 
ambiguity?  Is it not rigidly defined which channel should follow a rising 
edge of L/R clock?

Alan

Re: trouble with alsa, wolfson, and TI OMAP35xx McBSP

[Mark Brown]

On Thu, Apr 23, 2009 at 12:04:05PM +0100, Alan Horstmann wrote:

> Does this indicate that the implementation/drivers of i2s has a fundamental 
> ambiguity?  Is it not rigidly defined which channel should follow a rising 
> edge of L/R clock?

It's clearly defined to be that the left channel follows the falling
edge of LRCLK (ie, the left channel data is transmitted while LRCLK is
low).  However, not all CPUs do a wonderful job of implementing this -
some of the older Samsung chips need a workaround for synchronisation,
for example.

Re: trouble with alsa, wolfson, and TI OMAP35xx McBSP

[Peter Ujfalusi]

On Thursday 23 April 2009 14:04:05 ext Alan Horstmann wrote:
> On Thursday 23 April 2009 10:20, Peter Ujfalusi wrote:
> > On Wednesday 22 April 2009 20:58:01 ext twebb wrote:
> > > Problem 2:
> > > Test tone is being presented by the user application, providing a 1Khz
> > > tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left
> > > channel is quiet. The data seems to slip back and forth from left to
> > > right channel. This is reproducable and verified with a scope trace.
> > >
> > > Anybody have any ideas what might be going wrong here?  Traces for
> > > codec reg dump and mcbsp are attached.
> >
> > As Jarkko already asked: are you seeing the channel switch while running
> > or is it happens on playback start?
> >
> > AFAIK this phenomena can be also seen on Beagle board.
> >
> > I have done some investigation regarding to these, but so far I can not
> > say that I know what causes it.
> >
> > BTW: these are separate issues (startup switch and runtime switch).
>
> I just want to declare an interest in this investigation.  Many months back
> I was working on a SAM9260 board with wm8731 codec; the project is rather
> 'background' at present.  One of the outstanding unresolved (not really
> investigated much either) issues was of channel swapping at start of
> capture or playback.  It never changed during operation, but each start
> time the channels would be randomly correct or swapped.

So in case of OMAP35XX, when the switch happens?

I have a theory, which needs to be checked for the startup switch in OMAP:
I think what is happening, that the McBSP module got enabled earlier then the 
DMA is started. This leads to and underrun situation in McBSP (no data in the 
buffer), so McBSP will transmit _something_ when the start condition for the 
I2S is met. When the DMA starting to push data to McBSP, than valid data will 
be shifted out.
McBSP is shifting word by word manner. So if the first word transmit need to 
be done, when the buffer is empty, it starts to shift the word, than the data 
arrives from the DMA,  the next word will be valid data -> you will have a 
nice channel switch.

Is this makes sense?

>
> Does this indicate that the implementation/drivers of i2s has a fundamental
> ambiguity?  Is it not rigidly defined which channel should follow a rising
> edge of L/R clock?
>
> Alan

-- 
Péter

Re: trouble with alsa, wolfson, and TI OMAP35xx McBSP

[Mark Brown]

On Thu, Apr 23, 2009 at 02:52:24PM +0300, Peter Ujfalusi wrote:

> I have a theory, which needs to be checked for the startup switch in OMAP:
> I think what is happening, that the McBSP module got enabled earlier then the 
> DMA is started. This leads to and underrun situation in McBSP (no data in the 
> buffer), so McBSP will transmit _something_ when the start condition for the 
> I2S is met. When the DMA starting to push data to McBSP, than valid data will 
> be shifted out.
> McBSP is shifting word by word manner. So if the first word transmit need to 
> be done, when the buffer is empty, it starts to shift the word, than the data 
> arrives from the DMA,  the next word will be valid data -> you will have a 
> nice channel switch.

> Is this makes sense?

Sounds entirely plausible to me.

Re: trouble with alsa, wolfson, and TI OMAP35xx McBSP

[Alejandro Blanca G.]

Hi everyone.

We are working with bringing up another audio codec with the Beagle Board.

Probably the issue we are seeing is related: we are having problems
when doing playback and observe that the information corresponding to
2 channels is being sent only through the left channel. We might have
some other problems too, since we are new to this kind of development,
but maybe our observations or yours could be useful to stabilize the
Beagle platform code.

Best regards,

Alex B.

On Thu, Apr 23, 2009 at 4:20 AM, Peter Ujfalusi
<peter.ujfalusi@nokia.com> wrote:
> On Wednesday 22 April 2009 20:58:01 ext twebb wrote:
>> Problem 2:
>> Test tone is being presented by the user application, providing a 1Khz
>> tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left
>> channel is quiet. The data seems to slip back and forth from left to
>> right channel. This is reproducable and verified with a scope trace.
>>
>> Anybody have any ideas what might be going wrong here?  Traces for
>> codec reg dump and mcbsp are attached.
>
> As Jarkko already asked: are you seeing the channel switch while running or is
> it happens on playback start?
>
> AFAIK this phenomena can be also seen on Beagle board.
>
> I have done some investigation regarding to these, but so far I can not say
> that I know what causes it.
>
> BTW: these are separate issues (startup switch and runtime switch).
>
>> Thanks,
>> twebb
>
> --
> 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
>
--
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

Re: trouble with alsa, wolfson, and TI OMAP35xx McBSP

[Juha Kuikka]

On Thu, Apr 23, 2009 at 2:20 AM, Peter Ujfalusi <peter.ujfalusi@nokia.com>wrote:

> On Wednesday 22 April 2009 20:58:01 ext twebb wrote:
> > Problem 2:
> > Test tone is being presented by the user application, providing a 1Khz
> > tone sampled at 44.1Khz. The data are S16_LE, right channel only. Left
> > channel is quiet. The data seems to slip back and forth from left to
> > right channel. This is reproducable and verified with a scope trace.
> >
> > Anybody have any ideas what might be going wrong here?  Traces for
> > codec reg dump and mcbsp are attached.
>
> As Jarkko already asked: are you seeing the channel switch while running or
> is
> it happens on playback start?
>
> AFAIK this phenomena can be also seen on Beagle board.
>
> I have done some investigation regarding to these, but so far I can not say
> that I know what causes it.
>
> BTW: these are separate issues (startup switch and runtime switch).
>

I have seen the startup switch happening and I investigated it a bit.
The XDISABLE bit solution discussed on the list earlier did not solve the
problem fully, additionally I needed to add check for the FIFO state before
clearing XDISABLE.

Simplified:

1. Set XDISABLE bit
2. Start DMA
3. Start serial port.
4. Wait for the DMA to put data into McBSP FIFO (there is status you can
poll for this)
5. Clear XDISABLE bit.

I found that without step #4 the FIFO would sometimes be empty on step #5
and switching happened because first word sent was bogus and second was the
first audio word.

This was on OMAP2430.

 - Juha

-- 
Madness takes it's toll. Please have exact change.

Re: trouble with alsa, wolfson, and TI OMAP35xx McBSP

[Mark Brown]

On Thu, Apr 23, 2009 at 11:50:25AM -0500, Alejandro Blanca G. wrote:

> Probably the issue we are seeing is related: we are having problems
> when doing playback and observe that the information corresponding to
> 2 channels is being sent only through the left channel. We might have
> some other problems too, since we are new to this kind of development,
> but maybe our observations or yours could be useful to stabilize the
> Beagle platform code.

Please check out the current ASoC branch - as previously mentioned there
has been quite a bit of work recently on the McBSP audio formatting:

	git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6