McBSP Linux Configuration

I should note that I have confirmed connectivity to the OMAP pin and that the pin mux configuration is OMAP_PIN_INPUT | OMAP_MUX_MODE0.

Hi Chris,

Did you ever solve this issue?  We're experiencing a similar issue with an AM3517 and McBSP2.  We have playback (from the AM) working, but our record is just silence.  We're hoping it's a simple config issue, but try as we might we've yet to stumble across the issue.

Our post is here:  http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/165965.aspx#604986

Thanks!

We did solve it, but I don't have fine enough granularity in the commits to the change management system to really understand what made it work.  I do note that I am using padconf values for FSX, DR, and CLKX as inputs with pullups, and for DX as output, which is different than I stated in my last post above.

Also, here are some code snippets:

        ret = snd_soc_dai_set_fmt(codec_dai,
                                  SND_SOC_DAIFMT_I2S | // was: SND_SOC_DAIFMT_DSP_B | // was: SND_SOC_DAIFMT_I2S |
                                  SND_SOC_DAIFMT_CONT |
                                  SND_SOC_DAIFMT_IB_IF |
                                  SND_SOC_DAIFMT_CBM_CFM);

        ret = snd_soc_dai_set_fmt(cpu_dai,
                                  SND_SOC_DAIFMT_I2S | // was: SND_SOC_DAIFMT_DSP_B | // was: SND_SOC_DAIFMT_I2S |
                                  SND_SOC_DAIFMT_CONT |
                                  SND_SOC_DAIFMT_IB_IF |
                                  SND_SOC_DAIFMT_CBM_CFM);

        ret = snd_soc_dai_set_sysclk(codec_dai,
                                        0,
                                        2048000,
                                        SND_SOC_CLOCK_IN);

        ret = snd_soc_dai_set_sysclk(cpu_dai,
                                        OMAP_MCBSP_NONE, // was: OMAP_MCBSP_SYSCLK_CLKX_EXT,
                                        2048000,
                                        SND_SOC_CLOCK_IN);


Hope that helps,

Chris

Hi Chris,

Thanks so much for replying.  We tried the pull-ups rather than pull-downs, and I also tried the OMAP_MCBSP_NONE flag, but it gave me a compile error.  (Perhaps this one was custom to your application?  It does not appear to exist in our kernel.)  We are working with a 3.2 kernel at the moment because we need some of its newer features, but have bounced back to 2.6.37 once in a while just to check for consistency.

Unfortunately, those 2 things did not correct our issue.

At the moment, I believe one of the following is happening (though I've yet to prove it):

1. We don't yet have McBSP2 on the AM3517 setup for the right external CLK and FS lines on the receive side.  These should be identical to the ones setup for transmit.
2. Perhaps our receive side clocking is off.  I have noticed that both full-cycle and half-cycle receiving has a 1-bit delay built-in (due I suppose to the falling edge?).  The audio device we're talking with starts immediately.  So, perhaps we're losing a bit?
3. Internal mute on record?  We have no controls defined.  We're very much like the Bluetooth PCM devices out there.  So, I doubt this is the case, but...
4. Power management issue?  Is it possible for PM to be disabling receive but not transmit?

Thanks again for your help!

<<Edited to fix spelling/grammar errors.  That's what i get for rushing this out before a conference call.>>

I was using 2.6.32.  Good luck!  - Chris