From patchwork Wed Jan 13 14:45:56 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Arnaud Mouiche X-Patchwork-Id: 8026151 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 DD1059F1CC for ; Wed, 13 Jan 2016 14:46:23 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D886220515 for ; Wed, 13 Jan 2016 14:46:22 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) by mail.kernel.org (Postfix) with ESMTP id 0D76420513 for ; Wed, 13 Jan 2016 14:46:13 +0000 (UTC) Received: by alsa0.perex.cz (Postfix, from userid 1000) id 939082617B5; Wed, 13 Jan 2016 15:46:11 +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=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, NO_DNS_FOR_FROM,RCVD_IN_DNSWL_NONE,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=no version=3.3.1 Received: from alsa0.perex.cz (localhost [127.0.0.1]) by alsa0.perex.cz (Postfix) with ESMTP id BB53D260447; Wed, 13 Jan 2016 15:46:07 +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 294D6260447; Wed, 13 Jan 2016 15:46:06 +0100 (CET) Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by alsa0.perex.cz (Postfix) with ESMTP id C66852604D8 for ; Wed, 13 Jan 2016 15:45:59 +0100 (CET) Received: by mail-wm0-f41.google.com with SMTP id f206so297268735wmf.0 for ; Wed, 13 Jan 2016 06:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=invoxia-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=h3kqBQbRqXZIa+u4iOlYOm4IBeuQWt56I6VHkdmqX9c=; b=Wl9kpFbSBRZC2gdcQhb0OdvQevf9RSCp/ln0W57mci/TUSwk6YEdAHqSV4iW5bC7ac EpKA1JAYT35EZIC071ghdEz5dX5GcQrEZNExQ8vw6SbVn9+QCUZ/xDoCAn1J4w4v4CeD LTd2JaGV2eP/vqBBj8RXT8RL5ko7U2oUuhn1s1bE9S2HdjwjUx/NEuFU67WnaRvR8XFK ClBtZUdgrape/o1Yy6pccPB6kiSrwQ9A+lW5VKkc5Q+y+3M5cz2K8aQXZmmbrB7CsK4d 5QgqrAjWq3LtJYm+7vcdIdsU2qpWPM6O7Ub7aFJXWzwUJKvXBUyGIKnERKLMKJiKMOyz 8tAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=h3kqBQbRqXZIa+u4iOlYOm4IBeuQWt56I6VHkdmqX9c=; b=mBGYYJmT2XuDu0ar3Y/rMQhcxMYeyDIdmpSVuxtmOFxcDe3jsCJ9QYRTN5wuV2gJ42 cblLiyAgMHThX0vPPxC7tc2oICTVuXCh0OGhAm+CBk7YxmVYpk6VXBOhmuocFh74IBeY BmiVuPPtkpufSejgkjRmU57vBKJ9OQWOaYHV3XPjBdeAA+jPJOw8N1/+/dr4vkg+bA04 jaRiT4tRx8vOLvFBQjaiz6O6YexxlUF5JuLZs4RjhVyDbR1PDiVGfF6owkc+uv/xmd/c QImCBCLuRMkg3TiC5o97UlGeB9a5lepSTcg7iN6P2pTn9WWhZ8NAL91jq1HPnoiUqf+3 W/0g== X-Gm-Message-State: ALoCoQn811liPDwxDl6LIA5jzes2YxJdQKZBwxdMH6/rJbfkJU7mgYQb+kHG2eS+mA7KzXHNxiLuMPxWWrje5OCdMnV2EYd+Ig== X-Received: by 10.28.21.19 with SMTP id 19mr24954416wmv.43.1452696359284; Wed, 13 Jan 2016 06:45:59 -0800 (PST) Received: from [192.168.65.102] (AAnnecy-653-1-87-247.w90-41.abo.wanadoo.fr. [90.41.34.247]) by smtp.googlemail.com with ESMTPSA id c26sm22666864wmi.21.2016.01.13.06.45.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jan 2016 06:45:57 -0800 (PST) To: Caleb Crome References: <1448546842-4584-1-git-send-email-arnaud.mouiche@invoxia.com> <5690E8CF.8070700@invoxia.com> From: "arnaud.mouiche@invoxia.com" Message-ID: <56966324.8090409@invoxia.com> Date: Wed, 13 Jan 2016 15:45:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Cc: Fabio Estevam , "alsa-devel@alsa-project.org" , Liam Girdwood , Markus Pargmann , Mark Brown , Roberto Fichera , "shawn.guo@linaro.org" Subject: Re: [alsa-devel] [PATCH 0/5] ASoC: fsl_ssi: Fixing various channel slips and bad samples insertions 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 Le 12/01/2016 00:44, Caleb Crome a écrit : > On Sat, Jan 9, 2016 at 3:02 AM, arnaud.mouiche@invoxia.com > wrote: >> Hello Caleb >> >> Le 09/01/2016 01:47, Caleb Crome a écrit : >>> [...] >>> >>> Hello Arnaud, >>> I have finally gotten to test your patches, and I'm still having >>> trouble with channel slips. >>> >>> I applied your v2 patch set, along with your changes for using a dummy >>> codec. >>> >>> The full changes are here: >>> https://github.com/ccrome/linux-caleb-dev/tree/v4.4-rc8-armv7-x3 >>> >>> This ignores most of my previous patches, and uses your code to bring >>> up the SSI (without a codec) on a wandboard. >>> >>> I am using SSI3, and doing a hardware loopback between TX and RX. >>> >>> Here's what I run: >>> ./atest -r 16000 -c 8 -p 2048 -D default play >>> >>> which plays continuously. >>> >>> and in another shell: >>> ./atest -r 16000 -c 8 -p 2048 -D default -d 10 capture >>> >>> which captures for 10 seconds. >>> >>> >>> The first time I run the capture command, it succeeds, no problem. >>>> dbg: dev: 'default' >>>> dbg: default: capture_start >>>> dbg: start a 10 seconds duration timer >>>> warn: First valid frame >>>> warn: 3400 3401 3402 3403 3404 3405 3406 3407 >>>> dbg: end of tests >>>> total number of sequence errors: 0 >>>> global tests exit status: OK >>> But the second and all subsequent captures, it fails with channel slips: >>> >>>> dbg: dev: 'default' >>>> dbg: default: capture_start >>>> dbg: start a 10 seconds duration timer >>>> err: invalid frame after 0 null frames >>>> err: d2a1 d2a2 d2a3 d2a4 d2a5 d2a6 d2a7 d2c0 >>>> err: d2c1 d2c2 d2c3 d2c4 d2c5 d2c6 d2c7 78e0 >>>> dbg: end of tests >>>> total number of sequence errors: 430080 >>>> global tests exit status: OK >> >> Can you use -I option to get a little more log of the error >> $ ./atest -r 16000 -c 8 -p 2048 -D default -d 10 -I 10 capture >> >> Just to know if the wrong frames comes from the previous record session, >> meaning the RX fifo was not cleared correctly, >> as if the CCSR_SSI_SOR_RX_CLR bit is not working as we might expect. >> (ie. d2a1 .. d2c7 may come from the previous recording, and 78e0 .. may be >> the start of the new recording session) > That does appear to be what's happening. I read the SFCSR before and > after you update the SOR register (SOR_RX_CLR), and in both cases the > rx buffer is full on the second enablement. > > I can't seem to empty that buffer, either by using the SOR_RX_CLR or > by reading the SRX0 register. This is another one of those cases where > there you cannot modify the register (i.e. fifo or RX0) when RE is > disabled. > > So, instead of clearing on enable, I'm clearing on shutdown and on > enable. I attempted using the SOR_RX_CLR, but it doesn't seem to work > on the MX6. Rather, I clear the fifo by reading all the words in a > loop, just before RE is disabled. so the imx6.sl SSI behaves differently from the imx6.solo SSI ... Or some things have changes between 4.3 and 4.4. May be SOR_RX_CLR and/or RX0 registers can't be read on 'solo' because de the SRCR.RFEN0 [or1] are not enabled yet. In fact, clearing the fifos at the end may still introduce a race since the RX path is still enabled when your read from fifo, and Samples may still be received in the meantime... Also, I see that the CCSR_SSI_SOR register is not in the regmap fsl_ssi_volatile_reg() list (line 140). May be there is an implication of some caching mechanism ? Can you try to move the the fifo clearing part just before the write in CCSR_SSI_SIER with the following change in top of my patches ? Also may be you can additionally add the RX0 / RX1 reading from clearing mechanism at the same place. On my side, I will check the 4.4 tree on imx6sl Regards, Arnaud /* * Clear RX or TX FIFO to remove samples from the previous * stream session which may be still present in the FIFO and @@ -435,9 +438,6 @@ static void fsl_ssi_config(struct fsl_ssi_private *ssi_private, int enable, regmap_update_bits(regs, CCSR_SSI_SOR, CCSR_SSI_SOR_TX_CLR, CCSR_SSI_SOR_TX_CLR); } - - regmap_update_bits(regs, CCSR_SSI_SRCR, vals->srcr, vals->srcr); - regmap_update_bits(regs, CCSR_SSI_STCR, vals->stcr, vals->stcr); regmap_update_bits(regs, CCSR_SSI_SIER, vals->sier, vals->sier); } else { u32 sier; diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index 0277097..bd163b2 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -420,6 +420,9 @@ static void fsl_ssi_config(struct fsl_ssi_private *ssi_private, int enable, * (online configuration) */ if (enable) { + + regmap_update_bits(regs, CCSR_SSI_SRCR, vals->srcr, vals->srcr); + regmap_update_bits(regs, CCSR_SSI_STCR, vals->stcr, vals->stcr);