From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: noman pouigt <variksla@gmail.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: Fri, 10 Apr 2015 10:13:31 +0300 [thread overview]
Message-ID: <5527781B.10705@ti.com> (raw)
In-Reply-To: <CAES_P+-5vgq1LxSsUQLua4j06M4U8+ogLgnEK5KJ-4QPJs1vJQ@mail.gmail.com>
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
next prev parent reply other threads:[~2015-04-10 7:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-27 20:24 recording problem in beagleboard-mcbsp noman pouigt
2015-03-27 21:20 ` noman pouigt
2015-03-31 18:41 ` noman pouigt
2015-04-01 18:46 ` Peter Ujfalusi
2015-04-07 4:29 ` noman pouigt
2015-04-07 9:22 ` Peter Ujfalusi
2015-04-07 18:33 ` noman pouigt
2015-04-08 9:52 ` Peter Ujfalusi
2015-04-08 23:44 ` noman pouigt
2015-04-09 12:06 ` Peter Ujfalusi
2015-04-09 14:07 ` Peter Ujfalusi
2015-04-09 23:04 ` noman pouigt
2015-04-10 7:11 ` Peter Ujfalusi
2015-04-10 17:54 ` noman pouigt
2015-04-10 21:42 ` noman pouigt
2015-04-09 23:02 ` noman pouigt
2015-04-10 7:13 ` Peter Ujfalusi [this message]
2015-04-10 17:53 ` noman pouigt
2015-04-10 22:58 ` noman pouigt
2015-04-13 15:14 ` Peter Ujfalusi
2015-04-14 9:39 ` Peter Ujfalusi
2015-04-14 12:39 ` Peter Ujfalusi
2015-04-14 16:41 ` Variksla
2015-04-15 6:03 ` Peter Ujfalusi
2015-04-14 22:32 ` noman pouigt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5527781B.10705@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=variksla@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox