From patchwork Wed Oct 28 14:24:57 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Caleb Crome X-Patchwork-Id: 7512141 Return-Path: X-Original-To: patchwork-alsa-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 2DCD59F40A for ; Wed, 28 Oct 2015 14:25:41 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0A1B62081E for ; Wed, 28 Oct 2015 14:25:40 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) by mail.kernel.org (Postfix) with ESMTP id 9637A20662 for ; Wed, 28 Oct 2015 14:25:38 +0000 (UTC) Received: by alsa0.perex.cz (Postfix, from userid 1000) id 2E663261AE0; Wed, 28 Oct 2015 15:25:32 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, NO_DNS_FOR_FROM,RCVD_IN_DNSWL_LOW,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from alsa0.perex.cz (localhost [127.0.0.1]) by alsa0.perex.cz (Postfix) with ESMTP id 64457261A80; Wed, 28 Oct 2015 15:25:23 +0100 (CET) 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 1E0AC2619FA; Wed, 28 Oct 2015 15:25:22 +0100 (CET) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by alsa0.perex.cz (Postfix) with ESMTP id 67C8B2619FA for ; Wed, 28 Oct 2015 15:25:17 +0100 (CET) Received: by wicfx6 with SMTP id fx6so200307841wic.1 for ; Wed, 28 Oct 2015 07:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crome_org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/TQao5ShCiym4avUKONCCOswiz4dDU2KTcmOU+ul1OA=; b=d02L6wvxhgk2lytmijriIJExZaUZnI+SLN5XGGYuTqsmeFzqZ3EDCEZJ8xoIucT4/f 2vh37GmcObauihwJabmnGnulohaH8gPL7Dp8PfX/Aby0H2s5nxmYh7Cjns5AIzmwCK0i kU/KKOyuYGJbfj2upKB95WuiDxZKb5yKm2RT/Sp1Sy0dXPQysE5EmhLlha0BqWXAOcUj +vppY4gGP9VBNv/q2Ggimpr5XCQTMEsBKGX9aMfHkUOlsUfQ3XRnDyhQAa8uv5vM+cnx FpyHiFSHILAWED7nhDSIMQJ7xuRnTK5vdlFu84qKR0sbgcUDZ0vB2pCiK+meIbtZdjHR 1rjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/TQao5ShCiym4avUKONCCOswiz4dDU2KTcmOU+ul1OA=; b=CfO3SUrmoYJH7xSM5N9ziryoq/HBuetn5+BlGeSusD8PgkhaKnJyH91++qFm6OP8cW kjvOF0LwCs495jJOOhuuNf3Og/QbvUiwQt1NSrOi+3Z12m43ieU1aruaUSjiGLgj5Xr2 HzRZhge5rfkUQ4z54PLPiixBId0zXaaxxl2DCaZMIP//JWkdTzl7MtrRaMNwBw//sEwy 3vcNBrxO49zcv0fd8Mmmel63TG/bQMIoJ9tSu82Jd3ZRUVoVPXYInX8iXkvWLh4/t1oQ sBfj1TyS5UMCT5RmXNgOcO2xyTAwzyFIaVwhZUtoOfDQVlgfauf8pgBvB05INm8GIEFt CDyA== X-Gm-Message-State: ALoCoQmQ7ysCCYUOtwKLi5QIy0itSSqcShuf/Pj7GSW/zy/3aiRXUtP+PLzb3jbVHeFeALWZvNIS X-Received: by 10.194.48.5 with SMTP id h5mr39891341wjn.41.1446042317025; Wed, 28 Oct 2015 07:25:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.90.139 with HTTP; Wed, 28 Oct 2015 07:24:57 -0700 (PDT) In-Reply-To: <5630D61E.3030101@tekno-soft.it> References: <5625EF02.30602@invoxia.com> <56273F75.2040702@invoxia.com> <20151027071344.GC25728@pengutronix.de> <5630833B.10309@tekno-soft.it> <5630D61E.3030101@tekno-soft.it> From: Caleb Crome Date: Wed, 28 Oct 2015 07:24:57 -0700 Message-ID: To: Roberto Fichera Cc: Fabio Estevam , "alsa-devel@alsa-project.org" , Shengjiu Wang , Nicolin Chen , "arnaud.mouiche@invoxia.com" , Markus Pargmann , "shawn.guo@linaro.org" , Fabio Estevam Subject: Re: [alsa-devel] fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) 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 On Wed, Oct 28, 2015 at 7:05 AM, Roberto Fichera wrote: > On 10/28/2015 02:59 PM, Caleb Crome wrote: >> On Wed, Oct 28, 2015 at 1:11 AM, Roberto Fichera wrote: >>> On 10/27/2015 07:57 PM, Fabio Estevam wrote: >>>> [Adding Roberto in the thread as he is also trying to get SSI TDM support/ >>> Thanks Fabio, >>> >>> I'm also having the same issue but employing SSI in TDM master mode against a SLIC Si32178 >>> using its PCM mode. PCLK is at 2048KHz, FSYNC is 8KHz slot length is 32 bits (SSI wants >>> this since when in master mode) but valid data set to be 8bits in the SSI register. >>> >>> My Current situation is that I've a custom fsl_ssi.c driver to control the SSI in TDM master mode >>> both PCLK and FSYNC works perfectly fine, the SLIC has a register that I can check via SPI for >>> such purpose, I can see the clocking status from its side. The main problem I've is exactly the same >>> Caleb is having, after a certain amount of SDMA transfers, roughly 1000 or so, everything stops >>> without any apparent reason. >> My problem is that the channels randomly slip a slot and all words end >> up in the wrong slot. I suspect this is a DMA issue, but I really >> haven't diagnosed it yet. I don't get a full stop on the data. > > Ah! Ok! > >> FYI, I'm using a very recent 4.3 kernel from linus's repo, but 4.2 >> behaved the same. > > Can you please post the code you are using to setup the SSI, what PCLK and FSYNC rates? My codec is generating the clocks and the MX6 is in slave mode. PCLK (I assume that's the bit clock or BCLK in my workld) is 12.288MHz, and the FSYNC is 48kHz. 16 channels/frame, 16 bits/channel. I hardly changed the SSI driver at all. It's goofy now for sure because I force it to 16 slots/frame no matter what, so beware. Other than that, I also set the STCCR for 16 channels and set channels_max to 16. * modified while the SSI is enabled. The only time this can @@ -863,6 +866,15 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev, return -EINVAL; } scr |= ssi_private->i2s_mode; + // Set to 16 slots/frame + regmap_update_bits(regs, CCSR_SSI_STCCR, + CCSR_SSI_SxCCR_DC_MASK, + CCSR_SSI_SxCCR_DC(16)); + + regmap_update_bits(regs, CCSR_SSI_SRCCR, + CCSR_SSI_SxCCR_DC_MASK, + CCSR_SSI_SxCCR_DC(16)); + /* DAI clock inversion */ switch (fmt & SND_SOC_DAIFMT_INV_MASK) { @@ -1084,14 +1099,14 @@ static struct snd_soc_dai_driver fsl_ssi_dai_template = { .playback = { .stream_name = "CPU-Playback", .channels_min = 1, - .channels_max = 2, + .channels_max = 16, .rates = FSLSSI_I2S_RATES, .formats = FSLSSI_I2S_FORMATS, }, .capture = { .stream_name = "CPU-Capture", .channels_min = 1, - .channels_max = 2, + .channels_max = 16, .rates = FSLSSI_I2S_RATES, .formats = FSLSSI_I2S_FORMATS, }, There are other changes I've tried, including watermark changes (check out the alsa-dev archives on this thread for what I did before). This morning I am about to try the watermark changes suggested by Nicolin Chen. > Did you have your own DMA handling? Nope, I don't really know how to do that. I'm relying on the built in sdma driver (drivers/dma/imx-sdma.c) + fsl pcm (sound/soc/fsl/imx-pcm-dma.c) and my modified fsl_ssi.c driver. -Caleb > >> >> -Caleb >> >>>> On Tue, Oct 27, 2015 at 2:45 PM, Fabio Estevam wrote: >>>>> On Tue, Oct 27, 2015 at 2:42 PM, Caleb Crome wrote: >>>>>> On Tue, Oct 27, 2015 at 9:10 AM, Fabio Estevam wrote: >>>>>>> On Tue, Oct 27, 2015 at 2:02 PM, Caleb Crome wrote: >>>>>>> >>>>>>>>> Could you please try it without using the external SDMA firmware? >>>>>>>> I do need *some* SDMA firmware, correct? The firmware that I'm using >>>>>>>> ends up in /lib/firmware/imx/sdma/sdma-imx6q.bin and is md5sum >>>>>>>> 5d4584134cc4cba62e1be2f382cd6f3a. >>>>>>> SSI can operate with the ROM SDMA firmware. >>>>>>> >>>>>>> I would like to know if this issue also happens if you don't pass the >>>>>>> external firmware and use the internal ROM SDMA firmware instead. >>>>>> Ah, good to know. Do I just remove reference in the .dtsi file? >>>>>> Remove the file from the filesystem? I'll do both to be doubly sure >>>>>> :-) >>>>> Just remove it from the rootfs. Then you will see a message from the >>>>> kernel saying that no external SDMA firmware could be found and that >>>>> the internal one is going to be used. >>>>> >>>>>>> Also, could you try bumping the SSI and SDMA clock rates at the maximum? >>>>>> Any idea how I do that? I guess it's in the .dtsi file perhaps? I'll >>>>>> poke around. >>>>> You can try to call clk_set_rate() with the maximum allowed frequency >>>>> inside the ssi driver. I don't recall on top of my head what is this >>>>> value though. >>>>> >>>>> Regards, >>>>> >>>>> Fabio Estevam >>>> _______________________________________________ >>>> Alsa-devel mailing list >>>> Alsa-devel@alsa-project.org >>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >>>> >> _______________________________________________ >> Alsa-devel mailing list >> Alsa-devel@alsa-project.org >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >> > diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index 37c5cd4..73778c2 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -749,7 +749,10 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream *substream, CCSR_SSI_SCR_NET | CCSR_SSI_SCR_I2S_MODE_MASK, channels == 1 ? 0 : i2smode); } - + ssi_private->i2s_mode = CCSR_SSI_SCR_I2S_MODE_NORMAL | CCSR_SSI_SCR_NET; + regmap_update_bits(regs, CCSR_SSI_SCR, + CCSR_SSI_SCR_NET | CCSR_SSI_SCR_I2S_MODE_MASK, + ssi_private->i2s_mode); /* * FIXME: The documentation says that SxCCR[WL] should not be