From patchwork Thu Sep 18 17:26:11 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Nazzareno Trimarchi X-Patchwork-Id: 4933051 Return-Path: X-Original-To: patchwork-alsa-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 20798BEEA5 for ; Thu, 18 Sep 2014 17:26:43 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0DD892015D for ; Thu, 18 Sep 2014 17:26:42 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) by mail.kernel.org (Postfix) with ESMTP id 0CC3020148 for ; Thu, 18 Sep 2014 17:26:40 +0000 (UTC) Received: by alsa0.perex.cz (Postfix, from userid 1000) id 90C1E261ABB; Thu, 18 Sep 2014 19:26:38 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from alsa0.perex.cz (localhost [IPv6:::1]) by alsa0.perex.cz (Postfix) with ESMTP id 60983261ADC; Thu, 18 Sep 2014 19:26:28 +0200 (CEST) X-Original-To: alsa-devel@alsa-project.org Delivered-To: alsa-devel@alsa-project.org Received: by alsa0.perex.cz (Postfix, from userid 1000) id A01052651D1; Thu, 18 Sep 2014 19:26:26 +0200 (CEST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by alsa0.perex.cz (Postfix) with ESMTP id A0CB9261ABB for ; Thu, 18 Sep 2014 19:26:19 +0200 (CEST) Received: by mail-wi0-f170.google.com with SMTP id em10so7127394wid.1 for ; Thu, 18 Sep 2014 10:26:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Q1fOaoJRqS0gedZfBLlBXzIs+1oVp69qnbdONCcKKxQ=; b=Dzy8SU70w3N1Z7drVTrvSfphcD+SQxxWmYUBUMXlAOWeo2x5xOug4yGm9a4MNz3MWg 6sMtwDF0uvm9pTowRMyhp1QQmdchn7dKH6pnETPMXgVsZ0Tw0OwK81p4aTKmY/M2Dz2C 19f5TSyJSh2gHJVUeQnhvGen+F8ljb8LQhC8PwkfQ2ZJL5j0kLaxkwFeKMixmxcPw2TD cpbxt3b/VrE1KP0iNlyDgmVRscGL5nmiEnos7aeshRZh60LpdZs9eiEGpBmMZbpXdaqs ubCE1V08YA8mj40eYwIicwP1FLjJsXsqwBIoDuK99qCgwqTAj3yN3h4cV65Uc9D4JXmI ouVA== X-Gm-Message-State: ALoCoQlVaE1H+UkzXmwlOeqzMZ3LUHYCvDz2jfDCCrk3mL1FOuoPvFwJdho7jWTIJHUEXu4x0d0I X-Received: by 10.180.14.74 with SMTP id n10mr50116687wic.50.1411061179271; Thu, 18 Sep 2014 10:26:19 -0700 (PDT) Received: from panicking ([91.252.77.34]) by mx.google.com with ESMTPSA id pk9sm26772360wjb.16.2014.09.18.10.26.17 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 18 Sep 2014 10:26:18 -0700 (PDT) Date: Thu, 18 Sep 2014 19:26:11 +0200 From: Michael Trimarchi To: Nicolin Chen Message-ID: <20140918172611.GA17048@panicking> References: <20140918170524.GA6080@Asurada> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140918170524.GA6080@Asurada> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "alsa-devel@alsa-project.org" , Lars-Peter Clausen , Shengjiu Wang , Markus Pargmann , Jean-Michel Hautbois , Fabio Estevam , Shawn Guo Subject: Re: [alsa-devel] =?iso-8859-1?q?No_sound_captured_with_SGTL5000_on_i?= =?iso-8859-1?q?=2EMX6_in_I=B2S_master_mode?= X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org X-Virus-Scanned: ClamAV using ClamSMTP Hi On Thu, Sep 18, 2014 at 10:05:24AM -0700, Nicolin Chen wrote: > On Thu, Sep 18, 2014 at 06:09:50PM +0200, Jean-Michel Hautbois wrote: > > Well, audmux is not getting clock, this is normal I think, the clock I > > was mentionning is the MCLK of SGTL5000 and this one is linked to > > FPGA, but found after all. > > I now had a further look into sound/soc/fsl/fsl_ssi.c and I see this : > > > > sprop = of_get_property(np, "fsl,mode", NULL); > > if (sprop) { > > if (!strcmp(sprop, "ac97-slave")) > > ssi_private->dai_fmt = SND_SOC_DAIFMT_AC97; > > else if (!strcmp(sprop, "i2s-slave")) > > ssi_private->dai_fmt = SND_SOC_DAIFMT_I2S | > > SND_SOC_DAIFMT_CBM_CFM; > > } > > > > I may have missed something, but it seems that i2s-master is not > > parsed, and does not set dai_fmt ? > > Actually this is kind of obsolete property because initially the SSI > driver only supported i2s-slave. We've put an i2s-slave check here is > to limit the driver by excluding other modes. > > But now, the driver has the capability to derive clock from CCM and > output it for external CODEC. So this one could be dropped in fact > rather than adding a new i2s-master case IMO. > > > arecord -v -V stereo -f cd -D hw:0,0 somefile.wav > > Recording WAVE 'somefile.wav' : Signed 16 bit Little Endian, Rate > > 44100 Hz, Stereo > > > arecord: pcm_read:2031: read error: Input/output error > > The problem here should be the AUDMUX configuration issue. The imx- > sgtl5000.c driver only supports CODEC in master mode. So if you try > to switch the CODEC slave mode, you shall also change not only the > CBM_CFM to CBS_CFS but also swap the ext_port and int_port of AUDMUX > (a little confusing approach here as the configuration of AUDMUX is > routing the data and clocks from a source port to a destination port > while each of side, external or internal, might be a source port -- > When using CBM_CFM, the source port should be external port; while > using CBS_CFS, the source port should be the internal port.) > > There may be another topic, however, actually the fsl-asoc-card > driver does handle the master/slave mode supports. So if you are > trying to add the CODEC slave mode support into imx-sgtl5000. I > suggest you to try the fsl-asoc-card instead. Its DT binding's > totally compatible with imx-sgtl5000's. What you need to do is > just enable it (and disable imx-sgtl500) in the menuconfig or > add these enable/disable into imx_v6_v7_defconfig. > bug was reported by Jean-Michel. I don't know if it works because I can not test but seems ok. Do we need this _set_dai_fmt in probe function? code is a bit broken just because panic on probe path if pdev is null [...] /* * If codec-handle property is missing from SSI node, we assume * that the machine driver uses new binding which does not require * SSI driver to trigger machine driver's probe. */ if (!of_get_property(np, "codec-handle", NULL)) goto done; [...] ssi_private->pdev = platform_device_register_data(&pdev->dev, name, 0, NULL, 0); [...] done: if (ssi_private->dai_fmt) _fsl_ssi_set_dai_fmt(ssi_private, ssi_private->dai_fmt); Michael > Nicolin diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index 87eb577..f63bc02 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -758,7 +758,8 @@ static int _fsl_ssi_set_dai_fmt(struct fsl_ssi_private *ssi_private, ssi_private->dai_fmt = fmt; if (fsl_ssi_is_i2s_master(ssi_private) && IS_ERR(ssi_private->baudclk)) { - dev_err(&ssi_private->pdev->dev, "baudclk is missing which is necessary for master mode\n"); + pr_err("baudclk is missing which is necessary" + " for master mode\n"); return -EINVAL; }