Re: "Broken" McBSP1 on AM3517?

[CF Adad <cfadad@rocketmail.com>]

I was able to determine it was a bug in the OMAP McBSP code.  The following patch fixed it for me.
--- linux-a/sound/soc/omap/mcbsp.c      2012-06-28 17:11:54.203508660 -0400
+++ linux-b/sound/soc/omap/mcbsp.c      2012-07-16 17:31:52.000000000 -0400
@@ -745,7 +745,7 @@
 {
        const char *signal, *src;

-       if (mcbsp->pdata->mux_signal)
+       if (mcbsp->pdata->mux_signal == NULL)
                return -EINVAL;

        switch (mux) {





----- Original Message -----

I've tried getting this to the alsa-devel list, but have been a bit stymied.  Perhaps it would be relevant here too since this is directly related to the OMAP world.  As noted below, I suspect that recent changes from March in the handling of McBSP1 (6-wire interface) on the omap2/3 are what is causing me issues.  However, I've yet to figure out how to correct it on my platform.  Is detection of AM35xx perhaps part of my issue here?


----- Forwarded Message -----

All,

Over the past several months, we have been successfully interfacing with multiple digital audio devices using McBSPs 2, 3, and 4 on an AM3517 processor using a basic, custom digital audio driver.  (What we're using now is just a newer vesion of to what we shared back in February: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg63844.html.)  Recently we've had an opportunity to try to use McBSP1 as well.  So, I followed our standard formula, added it to our driver and started trying to use it.  What I'm seeing is that my transmit side functions reasonably, but my receive side does not.  I have put an o-scope on it, and I can see data coming back along the receive data line.  So I know there is stuff there.  However, I cannot arecord it.  I've checked my pinmux in u-boot, and:

    MUX_VAL(CP(MCBSP1_CLKR),    (IEN  | PTD | DIS | M0)) \
    MUX_VAL(CP(MCBSP1_FSR),        (IEN  | PTU | DIS | M0)) \
    MUX_VAL(CP(MCBSP1_DX),        (IDIS | PTD | DIS | M0)) \
    MUX_VAL(CP(MCBSP1_DR),        (IEN  | PTD | DIS | M0)) \
    MUX_VAL(CP(MCBSP1_FSX),        (IEN  | PTD | DIS | M0)) \
    MUX_VAL(CP(MCBSP1_CLKX),    (IEN  | PTD | DIS | M0)) \

Since I'm not changing anything in the pinmux in Linux, that should be good.

We are using a very recent linux-omap kernel (3.5.0-rc4), and I'm 99.9999% sure the issue is something simple, likely from the recently patched up omap-mcbsp/mcbsp driver(s).  Our connection is 4-wire only, and I suspect I'm stuck in 6-wire mode.  Historically, folks were instructed to insert the following into their drivers to switch McBSP1 to 4-wire config (http://mailman.alsa-project.org/pipermail/alsa-devel/2009-August/020771.html):


---------------------------------------------------------------------------------------------------------------------------------------------------------------------

    /* set cpu CLKR & FSR as inputs (unused) */
    ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_CLKR_SRC_CLKX, 0,
                SND_SOC_CLOCK_IN);
    if (ret < 0) {
        printk(KERN_ERR "can't set CPU system clock OMAP_MCBSP_CLKR_SRC_CLKX\n");
        return ret;
    }

    ret = snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_FSR_SRC_FSX, 0,
                SND_SOC_CLOCK_IN);
    if (ret < 0) {
        printk(KERN_ERR "can't set CPU system clock OMAP_MCBSP_FSR_SRC_FSX\n");
        return ret;
    }


---------------------------------------------------------------------------------------------------------------------------------------------------------------------
However, when I enable that code now, I now get ret < 0 and the error messages.

I suspect all this has to do with the patches from March of this year, as it appears several changes were incorporated recently to this.  My problem is I cannot figure out what I'm missing.  Digging through the code, it looks to me like I should still be able to make this call.  However, it fails.  If things have changed, what is the new procedure for using McBSP1 on an AM35xx in a 4-pin config?  My driver matches very closely to the sound/soc/omap/am3517evm.c at least in this component.  I notice that it has not been altered.  Is that a "bug", or does it work fine over there?

Any ideas on how to "fix" this, presuming this is the problem I'm having with my record path?

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html