diff mbox

recording problem in beagleboard-mcbsp

Message ID CAES_P+-5vgq1LxSsUQLua4j06M4U8+ogLgnEK5KJ-4QPJs1vJQ@mail.gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

noman pouigt April 9, 2015, 11:02 p.m. UTC
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

> 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

Comments

Peter Ujfalusi April 10, 2015, 7:13 a.m. UTC | #1
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
noman pouigt April 10, 2015, 5:53 p.m. UTC | #2
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.
>
>>
>>> 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
noman pouigt April 10, 2015, 10:58 p.m. UTC | #3
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
Peter Ujfalusi April 13, 2015, 3:14 p.m. UTC | #4
On 04/10/2015 02:02 AM, noman pouigt wrote:
>> 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)
> +                >;
> +        };

Should be:
mcbsp3_pins: pinmux_mcbsp3_pins {
	pinctrl-single,pins = <
		OMAP3_CORE1_IOPAD(0x2172, PIN_INPUT | MUX_MODE0) /* FSX */
		OMAP3_CORE1_IOPAD(0x2178, PIN_INPUT | MUX_MODE1) /* CLKX */
		OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* DX */
		OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1) /* DR */
	>;
};

Based on the schematics.

But for some reason I did not got capture working with this for the first try.
Then my MicroSD card decided that it is now in Write Protected mode and can
not recover it, no matter how I try (MicroSD does not have physical switch).

Have you tried to attach the codec to McBSP2? There is a P18 on the backside
of the xM (near to the MicroSD slot, 4 pin square c onnector) with
FSX/CLKX/DR/DX of McBSP2. You will need smaller pins to connect the line to
this header

The strange thing is that McBSP2 and 3 are mostly identical (they only have
different FIFO size) and McBSP3 is used in N9 to connect with twl5030 codec
while the McBSP2 is used with tlv320dac33. I know they work(ed) since I wrote
the audio support for the phone back in the days.

I need to find a spare MicrSD card now to boot the board, which I do not have ATM.

In any ways right now I have no idea why McBSP1 is not working as it should,
it is odd never the less.
Peter Ujfalusi April 14, 2015, 9:39 a.m. UTC | #5
On 04/13/2015 06:14 PM, Peter Ujfalusi wrote:
> On 04/10/2015 02:02 AM, noman pouigt wrote:
>>> 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)
>> +                >;
>> +        };
> 
> Should be:
> mcbsp3_pins: pinmux_mcbsp3_pins {
> 	pinctrl-single,pins = <
> 		OMAP3_CORE1_IOPAD(0x2172, PIN_INPUT | MUX_MODE0) /* FSX */
> 		OMAP3_CORE1_IOPAD(0x2178, PIN_INPUT | MUX_MODE1) /* CLKX */
> 		OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* DX */
> 		OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1) /* DR */
> 	>;
> };

> 
> Based on the schematics.
> 
> But for some reason I did not got capture working with this for the first try.
> Then my MicroSD card decided that it is now in Write Protected mode and can
> not recover it, no matter how I try (MicroSD does not have physical switch).
> 
> Have you tried to attach the codec to McBSP2? There is a P18 on the backside
> of the xM (near to the MicroSD slot, 4 pin square c onnector) with
> FSX/CLKX/DR/DX of McBSP2. You will need smaller pins to connect the line to
> this header
> 
> The strange thing is that McBSP2 and 3 are mostly identical (they only have
> different FIFO size) and McBSP3 is used in N9 to connect with twl5030 codec
> while the McBSP2 is used with tlv320dac33. I know they work(ed) since I wrote
> the audio support for the phone back in the days.
> 
> I need to find a spare MicrSD card now to boot the board, which I do not have ATM.
> 
> In any ways right now I have no idea why McBSP1 is not working as it should,
> it is odd never the less.


OK, got another SD card.
McBSP3 in master mode works (no codec connected) playback and capture as well.

The pins for McBSP3:
OMAP3_CORE1_IOPAD(0x2172, PIN_OUTPUT | MUX_MODE0) /* mcbsp3_fsx.mcbsp3_fsx */
OMAP3_CORE1_IOPAD(0x2178, PIN_OUTPUT | MUX_MODE1) /* uart2_tx.mcbsp3_clkx */
OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* uart2_cts.mcbsp3_dx */
OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1)  /* uart2_rts.mcbsp3_dr */

I still not sure why McBSP1 is not working..
Peter Ujfalusi April 14, 2015, 12:39 p.m. UTC | #6
On 04/14/2015 12:39 PM, Peter Ujfalusi wrote:
> OK, got another SD card.
> McBSP3 in master mode works (no codec connected) playback and capture as well.
> 
> The pins for McBSP3:
> OMAP3_CORE1_IOPAD(0x2172, PIN_OUTPUT | MUX_MODE0) /* mcbsp3_fsx.mcbsp3_fsx */
> OMAP3_CORE1_IOPAD(0x2178, PIN_OUTPUT | MUX_MODE1) /* uart2_tx.mcbsp3_clkx */
> OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* uart2_cts.mcbsp3_dx */
> OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1)  /* uart2_rts.mcbsp3_dr */
> 
> I still not sure why McBSP1 is not working..

This pinctrl setting is not correct for McBSP3. I was changing the registers
on the fly, that's why it was working when I replied.

In McBSP3 master mode, you need:
OMAP3_CORE1_IOPAD(0x2172, PIN_INPUT | MUX_MODE0) /* mcbsp3_fsx.mcbsp3_fsx */
OMAP3_CORE1_IOPAD(0x2178, PIN_INPUT | MUX_MODE1) /* uart2_tx.mcbsp3_clkx */
OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* uart2_cts.mcbsp3_dx */
OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1)  /* uart2_rts.mcbsp3_dr */

Which would work in McBSP3 slave mode as well.
Playback, capture works (McBSP3 master). I have connected DX to DR and
captured whatever I was playing. Came back fine.

As for McBSP1 I think this should get it working:
OMAP3_CORE1_IOPAD(0x2196, PIN_INPUT | MUX_MODE0) /* mcbsp1_fsx.mcbsp1_fsx */
OMAP3_CORE1_IOPAD(0x218e, PIN_INPUT | MUX_MODE0) /* mcbsp1_fsr.mcbsp1_fsr */
OMAP3_CORE1_IOPAD(0x2198, PIN_INPUT | MUX_MODE0) /* mcbsp1_clkx.mcbsp1_clkx */
OMAP3_CORE1_IOPAD(0x218c, PIN_INPUT | MUX_MODE0) /* mcbsp1_clkr.mcbsp1_clkr */
OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0) /* mcbsp1_dx.mcbsp1_dx */
OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0)  /* mcbsp1_dr.mcbsp1_dr */

If McBSP1 is slave, then connect the FS to both FSX and FSR and do the same
for CLK.
noman pouigt April 14, 2015, 4:41 p.m. UTC | #7
> On Apr 14, 2015, at 5:39 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> 
>> On 04/14/2015 12:39 PM, Peter Ujfalusi wrote:
>> OK, got another SD card.
>> McBSP3 in master mode works (no codec connected) playback and capture as well.
>> 
>> The pins for McBSP3:
>> OMAP3_CORE1_IOPAD(0x2172, PIN_OUTPUT | MUX_MODE0) /* mcbsp3_fsx.mcbsp3_fsx */
>> OMAP3_CORE1_IOPAD(0x2178, PIN_OUTPUT | MUX_MODE1) /* uart2_tx.mcbsp3_clkx */
>> OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* uart2_cts.mcbsp3_dx */
>> OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1)  /* uart2_rts.mcbsp3_dr */
>> 
>> I still not sure why McBSP1 is not working..
> 
> This pinctrl setting is not correct for McBSP3. I was changing the registers
> on the fly, that's why it was working when I replied.
> 
> In McBSP3 master mode, you need:
> OMAP3_CORE1_IOPAD(0x2172, PIN_INPUT | MUX_MODE0) /* mcbsp3_fsx.mcbsp3_fsx */
> OMAP3_CORE1_IOPAD(0x2178, PIN_INPUT | MUX_MODE1) /* uart2_tx.mcbsp3_clkx */
> OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* uart2_cts.mcbsp3_dx */
> OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1)  /* uart2_rts.mcbsp3_dr */

Weird. If mcbsp3 is master I am wondering why we are configuring fsx and clkx as input. 
> 
> Which would work in McBSP3 slave mode as well.
> Playback, capture works (McBSP3 master). I have connected DX to DR and
> captured whatever I was playing. Came back fine.
> 
> As for McBSP1 I think this should get it working:
> OMAP3_CORE1_IOPAD(0x2196, PIN_INPUT | MUX_MODE0) /* mcbsp1_fsx.mcbsp1_fsx */
> OMAP3_CORE1_IOPAD(0x218e, PIN_INPUT | MUX_MODE0) /* mcbsp1_fsr.mcbsp1_fsr */
> OMAP3_CORE1_IOPAD(0x2198, PIN_INPUT | MUX_MODE0) /* mcbsp1_clkx.mcbsp1_clkx */
> OMAP3_CORE1_IOPAD(0x218c, PIN_INPUT | MUX_MODE0) /* mcbsp1_clkr.mcbsp1_clkr */
> OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0) /* mcbsp1_dx.mcbsp1_dx */
> OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0)  /* mcbsp1_dr.mcbsp1_dr */
> 
> If McBSP1 is slave, then connect the FS to both FSX and FSR and do the same
> for CLK.
> 
> -- 
> Péter
noman pouigt April 14, 2015, 10:32 p.m. UTC | #8
On Tue, Apr 14, 2015 at 5:39 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> On 04/14/2015 12:39 PM, Peter Ujfalusi wrote:
>> OK, got another SD card.
>> McBSP3 in master mode works (no codec connected) playback and capture as well.
>>
>> The pins for McBSP3:
>> OMAP3_CORE1_IOPAD(0x2172, PIN_OUTPUT | MUX_MODE0) /* mcbsp3_fsx.mcbsp3_fsx */
>> OMAP3_CORE1_IOPAD(0x2178, PIN_OUTPUT | MUX_MODE1) /* uart2_tx.mcbsp3_clkx */
>> OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* uart2_cts.mcbsp3_dx */
>> OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1)  /* uart2_rts.mcbsp3_dr */
>>
>> I still not sure why McBSP1 is not working..
>
> This pinctrl setting is not correct for McBSP3. I was changing the registers
> on the fly, that's why it was working when I replied.

Ok great. FINALLY it is working after lots of try and incase it might anyone
who is trying to use below combination is working:

Linux kernel :
VERSION = 3
PATCHLEVEL = 19
SUBLEVEL = 0
EXTRAVERSION =
NAME = Diseased Newt

MCBSB3 in slave mode, max98090 in master mode and mux setting
as below:
> OMAP3_CORE1_IOPAD(0x2172, PIN_INPUT | MUX_MODE0) /* mcbsp3_fsx.mcbsp3_fsx */
> OMAP3_CORE1_IOPAD(0x2178, PIN_INPUT | MUX_MODE1) /* uart2_tx.mcbsp3_clkx */
> OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* uart2_cts.mcbsp3_dx */
> OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1)  /* uart2_rts.mcbsp3_dr */
both recording and playback is working.

MCBSP3 is working also in the case where it is master mode and
codec is in slave mode.

I referenced AM/DM37X Multimedia Device Silicon Revision 1.x version
R(public version)
for the mux settings. In this i see MCBSP3_DX as 216c. I think this is not the
right revision.
>
> Which would work in McBSP3 slave mode as well.
> Playback, capture works (McBSP3 master). I have connected DX to DR and
> captured whatever I was playing. Came back fine.
>
> As for McBSP1 I think this should get it working:
> OMAP3_CORE1_IOPAD(0x2196, PIN_INPUT | MUX_MODE0) /* mcbsp1_fsx.mcbsp1_fsx */
> OMAP3_CORE1_IOPAD(0x218e, PIN_INPUT | MUX_MODE0) /* mcbsp1_fsr.mcbsp1_fsr */
> OMAP3_CORE1_IOPAD(0x2198, PIN_INPUT | MUX_MODE0) /* mcbsp1_clkx.mcbsp1_clkx */
> OMAP3_CORE1_IOPAD(0x218c, PIN_INPUT | MUX_MODE0) /* mcbsp1_clkr.mcbsp1_clkr */
> OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0) /* mcbsp1_dx.mcbsp1_dx */
> OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0)  /* mcbsp1_dr.mcbsp1_dr */
>
> If McBSP1 is slave, then connect the FS to both FSX and FSR and do the same
> for CLK.

I didn't test this however as i just wanted any mcbsp connection to work but
i think this should work as well.
>
> --
> Péter
Thanks a ton for helping out!!!
Peter Ujfalusi April 15, 2015, 6:03 a.m. UTC | #9
On 04/14/2015 07:41 PM, Variksla wrote:
>> In McBSP3 master mode, you need:
>> OMAP3_CORE1_IOPAD(0x2172, PIN_INPUT | MUX_MODE0) /* mcbsp3_fsx.mcbsp3_fsx */
>> OMAP3_CORE1_IOPAD(0x2178, PIN_INPUT | MUX_MODE1) /* uart2_tx.mcbsp3_clkx */
>> OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* uart2_cts.mcbsp3_dx */
>> OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1)  /* uart2_rts.mcbsp3_dr */
> 
> Weird. If mcbsp3 is master I am wondering why we are configuring fsx and clkx as input. 

When we configure the pads, we set the input enable bit which will set the pin
to bidirectional mode.
The 4pin McBSP ports will get their FSR/CLKR from the actual pin. If the pin
is set to output only, no signal will come back to McBSP -> capture will not
work. This is why we need to set input enable, so that the signal going out
will be able to get back to McBSP's FSR/CLKR internal line.
diff mbox

Patch

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 25f7b0a..215eb86 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -59,8 +59,8 @@ 
 		compatible = "ti,omap-twl4030";
 		ti,model = "omap3beagle";
 
-		ti,mcbsp = <&mcbsp2>;
-		ti,codec = <&twl_audio>;
+		ti,mcbsp = <&mcbsp3>;
+		ti,codec = <&max98090>;
 	};
 
 	gpio_keys {
@@ -246,6 +246,15 @@ 
 			OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3)   /* dss_data23.dss_data5 */
 		>;
 	};
+
+       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)
+                >;
+        };
 };
 
 &omap3_pmx_core2 {
@@ -292,6 +301,11 @@ 
 
 &i2c2 {
 	clock-frequency = <400000>;
+
+	max98090: max98090@10 {
+		compatible = "maxim,max98090";
+		reg = <0x10>;
+	};
 };
 
 &i2c3 {
@@ -339,6 +353,7 @@ 
 	pinctrl-0 = <&uart3_pins>;
 };
 
+
 &gpio1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&gpio1_pins>;
@@ -363,6 +378,23 @@ 
 	status = "okay";
 };
 
+/*&mcbsp1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mcbsp1_pins>;
+
+	status = "okay";
+};*/
+
+&mcbsp1 {
+        status = "disabled";
+};
+
+&mcbsp3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mcbsp3_pins>;
+
+	status = "okay";
+};
 &dss {
 	status = "ok";
 
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index b112b1c..a4c3748 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -1997,6 +1997,10 @@  static int max98090_dai_hw_params(struct snd_pcm_substream *substream,
 		snd_soc_update_bits(codec, M98090_REG_INTERFACE_FORMAT,
 			M98090_WS_MASK, 0);
 		break;
+	case 24:
+		snd_soc_update_bits(codec, M98090_REG_INTERFACE_FORMAT,
+			M98090_WS_MASK, 2);
+		break;
 	default:
 		return -EINVAL;
 	}
@@ -2089,6 +2093,7 @@  static int max98090_dai_trigger(struct snd_pcm_substream *substream, int cmd,
 				struct snd_soc_dai *dai)
 {
 	struct snd_soc_codec *codec = dai->codec;
+	int reg;
 	struct max98090_priv *max98090 = snd_soc_codec_get_drvdata(codec);
 
 	switch (cmd) {
@@ -2589,15 +2594,6 @@  static int max98090_i2c_probe(struct i2c_client *i2c,
 		goto err_enable;
 	}
 
-	ret = devm_request_threaded_irq(&i2c->dev, i2c->irq, NULL,
-		max98090_interrupt, IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
-		"max98090_interrupt", max98090);
-	if (ret < 0) {
-		dev_err(&i2c->dev, "request_irq failed: %d\n",
-			ret);
-		return ret;
-	}
-
 	ret = snd_soc_register_codec(&i2c->dev,
 			&soc_codec_dev_max98090, max98090_dai,
 			ARRAY_SIZE(max98090_dai));
diff --git a/sound/soc/omap/omap-twl4030.c b/sound/soc/omap/omap-twl4030.c
index fb1f6bb..3176f1b 100644
--- a/sound/soc/omap/omap-twl4030.c
+++ b/sound/soc/omap/omap-twl4030.c
@@ -54,6 +54,12 @@  static int omap_twl4030_hw_params(struct snd_pcm_substream *substream,
 {
 	struct snd_soc_pcm_runtime *rtd = substream->private_data;
 	unsigned int fmt;
+	struct snd_soc_dai *codec_dai = rtd->codec_dai;
+	struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+	int err = 0;
+	int ret = 0;
+#if 0
+int div, clk_id,freq;
 
 	switch (params_channels(params)) {
 	case 2: /* Stereo I2S mode */
@@ -70,7 +76,58 @@  static int omap_twl4030_hw_params(struct snd_pcm_substream *substream,
 		return -EINVAL;
 	}
 
+	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;
+#else
+	switch (params_channels(params)) {
+	case 2: /* Stereo I2S mode */
+		fmt =	SND_SOC_DAIFMT_I2S |
+			SND_SOC_DAIFMT_NB_NF |
+			SND_SOC_DAIFMT_CBM_CFM;
+		break;
+	case 4: /* Four channel TDM mode */
+		fmt =	SND_SOC_DAIFMT_DSP_A |
+			SND_SOC_DAIFMT_IB_NF |
+			SND_SOC_DAIFMT_CBM_CFM;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	snd_soc_dai_set_sysclk(codec_dai, 0, 13000000,
+		SND_SOC_CLOCK_IN);
 	return snd_soc_runtime_set_dai_fmt(rtd, fmt);
+#endif
 }
 
 static struct snd_soc_ops omap_twl4030_ops = {
@@ -228,13 +285,12 @@  static int omap_twl4030_card_remove(struct snd_soc_card *card)
 /* Digital audio interface glue - connects codec <--> CPU */
 static struct snd_soc_dai_link omap_twl4030_dai_links[] = {
 	{
-		.name = "TWL4030 HiFi",
-		.stream_name = "TWL4030 HiFi",
-		.cpu_dai_name = "omap-mcbsp.2",
-		.codec_dai_name = "twl4030-hifi",
-		.platform_name = "omap-mcbsp.2",
-		.codec_name = "twl4030-codec",
-		.init = omap_twl4030_init,
+		.name = "max98090 HiFi",
+		.stream_name = "max98090 HiFi",
+		.cpu_dai_name = "omap-mcbsp.3",
+		.codec_dai_name = "HiFi",
+		.platform_name = "omap-mcbsp.3",
+		.codec_name = "max98090.1-0010",
 		.ops = &omap_twl4030_ops,
 	},
 	{