Re: recording problem in beagleboard-mcbsp

From: noman pouigt <variksla@gmail.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"broonie@kernel.org" <broonie@kernel.org>
Subject: Re: recording problem in beagleboard-mcbsp
Date: Wed, 8 Apr 2015 16:44:09 -0700	[thread overview]
Message-ID: <CAES_P+8oJ0xDJ-2w02Q0pZmgQyY9tyaRB=+_PqMhTdwuYNRShw@mail.gmail.com> (raw)
In-Reply-To: <5524FA51.9060606@ti.com>

On Wed, Apr 8, 2015 at 2:52 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> On 04/07/2015 09:33 PM, noman pouigt wrote:
>> In my setup codec(max98090) is master and mcbsp is slave. I used above
>> command and got below error:
>> arecord: set_params:1233: Sample format non available
>> Available formats:
>> - S16_LE
>
> The codec only supports S16_LE or S24_LE.
>
>> So i changed the format to S16_LE and got below error:
>> arecord: pcm_read:2031: read error: Input/output error
>>
>> I checked the dmesg and found out that interrupt triggered only
>> once and after some time all widgets gets powered down.
>> Below is part of the dmesg.
>>
>> [  174.186431] snd_pcm_lib_read
>> [  174.186462] snd_pcm_lib_read1
>> [  174.187042] omap-mcbsp 48074000.mcbsp: **** McBSP255 regs ****
>> [  174.187072] omap-mcbsp 48074000.mcbsp: DRR2:  0xedd0abce
>> [  174.187103] omap-mcbsp 48074000.mcbsp: DRR1:  0x0000
>> [  174.187133] omap-mcbsp 48074000.mcbsp: DXR2:  0x0000
>> [  174.187164] omap-mcbsp 48074000.mcbsp: DXR1:  0x0000
>> [  174.187194] omap-mcbsp 48074000.mcbsp: SPCR2: 0x0230
>> [  174.187225] omap-mcbsp 48074000.mcbsp: SPCR1: 0x0031
>> [  174.187255] omap-mcbsp 48074000.mcbsp: RCR2:  0x8041
>> [  174.187286] omap-mcbsp 48074000.mcbsp: RCR1:  0x0040
>> [  174.187316] omap-mcbsp 48074000.mcbsp: XCR2:  0x8041
>> [  174.187347] omap-mcbsp 48074000.mcbsp: XCR1:  0x0040
>> [  174.187377] omap-mcbsp 48074000.mcbsp: SRGR2: 0x001f
>> [  174.187408] omap-mcbsp 48074000.mcbsp: SRGR1: 0x0f00
>> [  174.187438] omap-mcbsp 48074000.mcbsp: PCR0:  0x000f
>> [  174.187469] omap-mcbsp 48074000.mcbsp: ***********************
>> [  174.187499] snd_pcm_update_hw_ptr0
>>
>> May i know where am i going wrong?
>
> First check the /proc/asound/card0/pcm0c/sub0/status while the capture is
> running and look at the hw_ptr if it has moved at all.

It has not moved at all.
>
> Enable more interrupts in sound/soc/omap/mcbsp.c:omap_mcbsp_config(), like
> RUNDFLEN, ROVFLEN and see if you have overflow in McBSP.

I did enable the interrupt but all i am getting is below for both
playback and capture
usecase:
omap-mcbsp 48074000.mcbsp: RX Buffer Underflow!

Remember playback is working in both the slave and master mode (codec slave
and codec master).
>
> If the DMA has not moved it means that McBSP does not received the FS which
> would indicate the frame start, thus it will not sample data in, thus it will
> not trigger the DMA to read the data out.

Used scope to check FS and Bit clock and found below (running arecord
with 44100):
bit clock is running at 1.420 MHz and FS at 44100 kHz. Configured MCBsp
in master mode this time.

>
> Since the capture is working on McBSP2 in McBSP slave (and master also) the
> only thing which can be wrong is the way the max98090 is wired up or some mux
> issue again as it was before for you.

Below is the mux setting which i did and because of which playback is working:
MCBsp in master mode
configured mcbsp1_clkx, mcbsp1_fsx, mcbsp1_dx and mcbsp1_dr
+
+       mcbsp1_pins: pinmux_mcbsp1_pins {
+                pinctrl-single,pins = <
+                        OMAP3_CORE1_IOPAD(0x2196, PIN_OUTPUT | MUX_MODE0)
+                        OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE0)
+                        OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0)
+                        OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0)
+                        OMAP3_CORE1_IOPAD(0x218C, PIN_OUTPUT | MUX_MODE0)
+                >;
+        };
 };

Even if MCBSP_DR is not connected properly it should record atleast noise.

I also tried Thomas Niederprüm below advice when running McBsp in slave mode
shorten the CLKR and CLKX pins and mux the CLKR pin as INPUT in your
dts. Then your
bitclock would enter through CLKR as well as CLKX.
But this also didn't work.

Found out only below register changes between playback and capture:
In playback
SPCR2: 0x02f5
SPCR1: 0x0030
In capture:
SPCR2: 0x02f0
SPCR1: 0x0031

There are no difference between any other register. I think mcbsp
registers are fine
but can you confirm if there should be any more differences?
Please advice what might be going wrong?
>
> --
> Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel