[alsa-devel] recording problem in beagleboard-mcbsp
noman pouigt
variksla at gmail.com
Fri Apr 10 19:53:34 CEST 2015
On Fri, Apr 10, 2015 at 12:13 AM, Peter Ujfalusi <peter.ujfalusi at ti.com> wrote:
> On 04/10/2015 02:02 AM, noman pouigt wrote:
>> 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
>
> It removed functionality, you might want ton hack something similar back for
> testing
I will give it a try but wouldn't it be nice if i can directly write
to mux registers
to get back the functionality.
>
>>
>>> 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.
I did change the machine driver accordingly as below and sent you the patch
which i used.
anyway below is the change which i did:
+ struct snd_soc_dai *codec_dai = rtd->codec_dai;
+ struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+ int err = 0;
+ int ret = 0;
+int div, clk_id,freq;
switch (params_channels(params)) {
case 2: /* Stereo I2S mode */
fmt = SND_SOC_DAIFMT_I2S |
SND_SOC_DAIFMT_NB_NF |
- SND_SOC_DAIFMT_CBM_CFM;
+ SND_SOC_DAIFMT_CBS_CFS;
break;
case 4: /* Four channel TDM mode */
fmt = SND_SOC_DAIFMT_DSP_A |
SND_SOC_DAIFMT_IB_NF |
- SND_SOC_DAIFMT_CBM_CFM;
+ SND_SOC_DAIFMT_CBS_CFS;
break;
default:
return -EINVAL;
}
- return snd_soc_runtime_set_dai_fmt(rtd, fmt);
+ snd_soc_runtime_set_dai_fmt(rtd, fmt);
+ snd_soc_dai_set_sysclk(codec_dai, 0, 13000000,
+ SND_SOC_CLOCK_IN);
+div = clk_id = freq = 0;
+switch (params_rate(params)) {
+case 44100: /* 44.117 */
+ div = 68;
+ clk_id = OMAP_MCBSP_SYSCLK_CLKS_FCLK;
+ freq = 96000000;
+ break;
+case 48000: /* 48.032 */
+ div = 54;
+ clk_id = OMAP_MCBSP_SYSCLK_CLK;
+ freq = 83000000;
+ break;
+default:
+ printk(KERN_ERR "hw params: unknown rate %d\n",
+ params_rate(params));
+ return -EINVAL;
+}
ret = snd_soc_dai_set_sysclk(cpu_dai, clk_id, freq, SND_SOC_CLOCK_IN);
if (ret < 0) {
printk("what the hell\n");
return -EINVAL;
}
ret = snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV, div);
if (ret < 0) {
printk("what the hell going on\n");
return -EINVAL;
}
return ret;
>
>>
>>>
>>> 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
More information about the Alsa-devel
mailing list