From patchwork Mon Jul 16 21:42:26 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: CF Adad X-Patchwork-Id: 1202491 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id 3AE4DE0038 for ; Mon, 16 Jul 2012 21:43:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753562Ab2GPVnF (ORCPT ); Mon, 16 Jul 2012 17:43:05 -0400 Received: from nm17-vm1.bullet.mail.ne1.yahoo.com ([98.138.91.34]:36383 "HELO nm17-vm1.bullet.mail.ne1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753849Ab2GPVm2 convert rfc822-to-8bit (ORCPT ); Mon, 16 Jul 2012 17:42:28 -0400 Received: from [98.138.90.48] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jul 2012 21:42:27 -0000 Received: from [98.138.89.167] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jul 2012 21:42:27 -0000 Received: from [127.0.0.1] by omp1023.mail.ne1.yahoo.com with NNFMP; 16 Jul 2012 21:42:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 185335.71475.bm@omp1023.mail.ne1.yahoo.com Received: (qmail 93095 invoked by uid 60001); 16 Jul 2012 21:42:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rocketmail.com; s=s1024; t=1342474947; bh=zfoWCuw//F4C32VytwzFIRLKWWpR7sqlPYPOVxxeyAQ=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=3LLS3bjUKn0kW6SssKJlgzBlcaU7JiqUe50+eW+BYazqeeVw5ivsbevcL6HLMtL+UR3LlTG+MDa4P2unzA8/V5vQbjEwvhF9IPuX+ku3d1w4aPwsmvp9CStODp/QakIIvZhlrs5xjzPUU3IuYteXHL7vY5Y7A1M5l31Byhr5nuc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rocketmail.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CWo3buubcdjZCDImrV4oA4jDYiyr0WnMFEHOlxBUgYi4EJzlSCv3IBUrq2jZWm2IB42YOYBD4ZY24bpIbe9FFMy6WYD+wxMkxBP0mnFZX+tFiejPdvs02BVAWeNtv0KcGE0uB4kpyIm5TWcOYkymqQSc2u5fn49wBpDCe9sav3A=; X-YMail-OSG: _lYv7DMVM1ng75.e53mIb.ED4WOHiyM6_70JX180t5MW5L. 1iQVESplY3s0grercVqgFCRynVQLxJ8nvSL53vZpzMdvahoW7sbrc_MTSrae Muj_SzT8kMEozT05cQ4rGBiV.1ycc8RyI9j1nbxB4wqIcf1jwC5D2RYzb3VB llIHRFuTDF0Bw0iR4v2iMVN2h5O8Dza3qhgLdih8uQuHL2NXgDs5.znqgEcT UFUmEkFGrMl2qNGN8eiNCbLGkS.L.h4xupS3jpCJBX8wO412Njk.6kbi3kv3 9RDhv7I1h6JMRhmSUjPKLXrfGTw2mMLwAvLRu7bE3rdE3p5JxJ9Rdo6fX5hs vBwLhLyNWv.tbnCFljInPkby02ERDMa9lnCxnKWiIUu7aoqyXrwjU.6lHMME BUSPXqFLwUu5HoIFmDE0208eguCdyjUn82evofo_xTWpjJT89zCAIM8glxDi ylD0OSq0WAvMgNXG8cC8iL.eE3VCj.R4AbirXKXTPdFOaRYk27_S0gZHJl70 K_ZiBCJS1w_lvvaRXDOhhnvlgkVvhqqhtR5zI8BZnHrinl_mXEyz2PuGVAka X6jYMPbzse739ijMdRPX86FsLZlj4aXC0tjdbedHiBMExirAQ7KLCWUnPhT. SVn5XFdm7V_W_AbsVxk9Ckjj4E.33ir2CajHCcuD5nFhzuWWYBjLz86lbO4n CjT7E1a2Obg-- Received: from [71.127.51.115] by web125204.mail.ne1.yahoo.com via HTTP; Mon, 16 Jul 2012 14:42:26 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <1341961350.32611.YahooMailNeo@web125202.mail.ne1.yahoo.com> <1342459273.74158.YahooMailNeo@web125201.mail.ne1.yahoo.com> <1342461393.69195.YahooMailNeo@web125205.mail.ne1.yahoo.com> Message-ID: <1342474946.72910.YahooMailNeo@web125204.mail.ne1.yahoo.com> Date: Mon, 16 Jul 2012 14:42:26 -0700 (PDT) From: CF Adad Reply-To: CF Adad Subject: Re: "Broken" McBSP1 on AM3517? To: "linux-omap@vger.kernel.org" In-Reply-To: <1342461393.69195.YahooMailNeo@web125205.mail.ne1.yahoo.com> MIME-Version: 1.0 Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org I was able to determine it was a bug in the OMAP McBSP code.  The following patch fixed it for me. ----- 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 --- 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) {