Re: recording problem in beagleboard-mcbsp

[noman pouigt <variksla@gmail.com>]

On Fri, Apr 10, 2015 at 10:53 AM, noman pouigt <variksla@gmail.com> wrote:
> On Fri, Apr 10, 2015 at 12:13 AM, Peter Ujfalusi <peter.ujfalusi@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@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.

Anyway i tried adding this hack below
 void __init omap3_ctrl_init(void)
 {
+       int devconf0;
        omap_ctrl_writel(OMAP3430_AUTOIDLE_MASK, OMAP2_CONTROL_SYSCONFIG);

        omap3_ctrl_set_iva_bootmode_idle();

        omap3_ctrl_setup_d2d_padconf();
+devconf0 = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
+devconf0 |=  OMAP2_MCBSP1_CLKR_MASK | OMAP2_MCBSP1_FSR_MASK;
+omap_ctrl_writel(devconf0, OMAP2_CONTROL_DEVCONF0);
 }

and run in codec slave and mcbsp1 master mode. It didn't work. Playback
as you know is already working without this change.

>>
>>>
>>>> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel