[alsa-devel] recording problem in beagleboard-mcbsp

[noman pouigt]

On Thu, Apr 9, 2015 at 5:06 AM, Peter Ujfalusi <peter.ujfalusi at ti.com> wrote:
> 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.
This patch seems pretty old and I am not able to apply it as i am
using latest kernel.
kernel: 3.19

> Or to switch to use McBSP3.

tried this as well but even playback didn't work.
+       mcbsp3_pins: pinmux_mcbsp3_pins {
+                pinctrl-single,pins = <
+                        OMAP3_CORE1_IOPAD(0x216C, PIN_OUTPUT | MUX_MODE1)
+                        OMAP3_CORE1_IOPAD(0x216E, PIN_INPUT | MUX_MODE1)
+                        OMAP3_CORE1_IOPAD(0x2170, PIN_OUTPUT | MUX_MODE1)
+                        OMAP3_CORE1_IOPAD(0x2172, PIN_OUTPUT | MUX_MODE0)
+                >;
+        };

attached patch where i replaced the mcbsp1 to mcbsp3 number in machine file.
do you think this configuration is  right? I tried both master and slave mode
and both didn't work but i was getting right bit clock and FS clock.

>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mcbsp3.patch
Type: text/x-patch
Size: 5599 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20150409/23f99e40/attachment.bin>