Re: recording problem in beagleboard-mcbsp

[Peter Ujfalusi <peter.ujfalusi@ti.com>]

On 04/09/2015 02:44 AM, noman pouigt wrote:
>> 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.

So McBSP does not detect start condition on the FS line.

>> 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!

This is because you dump the registers and it read the DDR register. The FIFO
is empty and you try to read data out.

> 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?

Hrm, McBSP1 is kind of problematic port since it has 6pin config by default.
It might worth a try to do something like:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/113058.html
has removed.
Or to switch to use McBSP3.

But for some reason now I can not get the recording working via McBSP1 either.
I remember that it worked not that long time ago...

-- 
Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel