Re: recording problem in beagleboard-mcbsp

Peter Ujfalusi
2015-04-10T07:15:07Z

On 04/10/2015 02:02 AM, noman pouigt wrote:
> On Thu, Apr 9, 2015 at 5:06 AM, Peter Ujfalusi <peter.ujfalusi@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

It removed functionality, you might want ton hack something similar back for
testing

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

By default codec is master, so try to set the mux accordingly.

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

--
Péter