From patchwork Thu Oct 29 22:23:41 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Caleb Crome X-Patchwork-Id: 7521591 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 8F2869F36A for ; Thu, 29 Oct 2015 22:24:20 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9BA61207BE for ; Thu, 29 Oct 2015 22:24:19 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) by mail.kernel.org (Postfix) with ESMTP id 0EA24208E3 for ; Thu, 29 Oct 2015 22:24:18 +0000 (UTC) Received: by alsa0.perex.cz (Postfix, from userid 1000) id 1D8FB2658DC; Thu, 29 Oct 2015 23:24:16 +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 45DA9265558; Thu, 29 Oct 2015 23:24: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 568022657FC; Thu, 29 Oct 2015 23:24:06 +0100 (CET) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by alsa0.perex.cz (Postfix) with ESMTP id 334BC2651A5 for ; Thu, 29 Oct 2015 23:24:01 +0100 (CET) Received: by wicll6 with SMTP id ll6so54252981wic.1 for ; Thu, 29 Oct 2015 15:24:00 -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=eM8MCI27FMumOinM1+wdB2wuLaBpDY8h0PWXx44BmbA=; b=qIb/4Q0Nj7aa4SIrJ8RGyr/E1p2arPSX1mBc3RJdti3SK7Q+I/iq6yn0tbqn1Iv0iT Z37jP9pSQ3KADHI93bj7OfA8vjo6LiCuSGtDNd/nRn4TRnQDTW9iiz88HB2OzRKG+5Nb 0FLdNJ2XPePzrHncFccwTs+pKzgAlESqzlgp54pUvmx/SXKliOfNo5xJKTffxOvQb4dK 8NzyJlVlpggFDFuVJq7J4FlCX3oIR4Ea17I+s0QeAISKHQgckDCJDDnu9dtmqzkpYG1n NpCbjA+amJYI3pS7bF0N1RwpydeFbp8yaNjP/Him45QS81+NNjG5Vcj9/u7lCPWhV4R0 0cIw== 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=eM8MCI27FMumOinM1+wdB2wuLaBpDY8h0PWXx44BmbA=; b=aAnKps3/A7fm7ebi36C93I0uNA4Pjxo5JqypH56uPTlGLvW4fP+jd+Io4HkKaNkP0x lq3dF6WP5rdZLa+iv4vvmhvxoeMJqEHA5SjcoiL239dJbGgTdyjARFqlJGXt/VvA/hen zHBCGBNcWH4zPMt/avj+tp/XX0JjXCZRUbJ2qQxGmmg2qu/UxzPot+kkPfwy+1J0ImQH KTFmju6POwPWtnB+bxL1Hc9zHzD6MPZgYdjOkeSVLsbcgH4bPmEvDyT3HuSWYIsOTf0l Bv//LczVl86RZRF8o34D1TvEI39Z2wjUSwu0XRV4Jr0vogRmin0Roolt+t9vy6Suv5m+ xojA== X-Gm-Message-State: ALoCoQmiiTp5UdCUXl+jeamAhUxBgwZYudVEAZpMoxZ9twZFNrowVEhHizGZqcDiwjQMhj2Pu55i X-Received: by 10.194.61.70 with SMTP id n6mr4767074wjr.81.1446157440880; Thu, 29 Oct 2015 15:24:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.90.139 with HTTP; Thu, 29 Oct 2015 15:23:41 -0700 (PDT) In-Reply-To: <20151029192816.GA43706@Asurada-CZ80> References: <56273F75.2040702@invoxia.com> <20151027071344.GC25728@pengutronix.de> <20151027201101.GA9527@Asurada-CZ80> <20151029045350.GA3374@Asurada-CZ80> <20151029171936.GA3492@Asurada-CZ80> <20151029192816.GA43706@Asurada-CZ80> From: Caleb Crome Date: Thu, 29 Oct 2015 15:23:41 -0700 Message-ID: To: Nicolin Chen Cc: Fabio Estevam , "alsa-devel@alsa-project.org" , Markus Pargmann , "arnaud.mouiche@invoxia.com" , Roberto Fichera , "shawn.guo@linaro.org" 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 Thu, Oct 29, 2015 at 12:28 PM, Nicolin Chen wrote: > On Thu, Oct 29, 2015 at 12:06:16PM -0700, Caleb Crome wrote: > >> This actually is exactly what I'm seeing now. I'm seeing the >> *startup* happening from the trigger starting up slipped. So this >> does make perfect sense to me. > > I saw your problem in the other reply. And I suggested you to let > DMA work first before SSI gets enabled. As SDMA in that case would > transfer one burst length (16 if you applied my patch I sent you) > and pause before SSI gets enabled. Then SSI would have enough data > to send out without any startup issue. Ah ha, you are exactly right. The root cause is that TE and SSIE are enabled at the same regmap write, with no opportunity for delay between the SSIE and TE. DMA can only get going if SSIE is enabled, and the only place SSIE gets enabled is exactly the same line that TE gets enabled. specifically: regmap_update_bits(regs, CCSR_SSI_SCR, vals->scr, vals->scr); I've looked over your emails and I don't see the patch that shows a pause between SSIE enable and TE enable. (I do see the dual-fifo example -- thank you! I'll give that a try -- it may further reduce stress on the system). Here is a patch that solves the issue much more elegantly than my previous one: > >> It occurred to me that perhaps the problem has to do when exactly when >> during the frame-sync period the fsl_ssi_trigger function was called. >> Perhaps, if it's called near the end or beginning of a frame, somehow > > I don't know how you measured if it's before of after. But the frame > should not start until trigger() gets call -- more clearly SSIEN and > TE get enabled. From my point of view, you problem should be caused > by SSI getting enabled without enough data in the FIFO. And that's > what I just described in the previous paragraph and previous reply. Yep, that sure seems to be it. This patch above never seems to have a bad start. Is adding the udelay the best way to put a delay between SSIE and TE enable? Are there any other mechanisms for that? Thanks so much for your attention and help! I think I can finally move forward with the MX6 on a bunch of projects now :-) (well, I still have to test Rx and verify full dulex perfection there too, but this is a great start) -Caleb diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index 73778c2..0bb5e52 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -435,8 +475,27 @@ static void fsl_ssi_config(struct fsl_ssi_private *ssi_private, bool enable, config_done: /* Enabling of subunits is done after configuration */ - if (enable) + if (enable) { + /* + * don't enable TE/RE and SSIEN at the same time. + * enable SSIEN, but delay enabling of TE to + * allow time for DMA buffer to fill. + */ + u32 mask = vals->scr & ~CCSR_SSI_SCR_TE; + if (mask != vals->scr) { + /* enabling TE in this call. don't enable it + * until some delay after SSIE gets + * enabled. */ + if (vals->scr & ~CCSR_SSI_SCR_TE) { + regmap_update_bits(regs, CCSR_SSI_SCR, + mask, vals->scr); + udelay(50); /* give the DMA a chance + * to fill the TX buffer + * after SSIE is enabled. */ + } + } regmap_update_bits(regs, CCSR_SSI_SCR, vals->scr, vals->scr); + } }