From patchwork Mon Oct 19 15:55:38 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Caleb Crome X-Patchwork-Id: 7438211 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.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id DBBF4BEEA4 for ; Mon, 19 Oct 2015 15:56:17 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E759820784 for ; Mon, 19 Oct 2015 15:56:16 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) by mail.kernel.org (Postfix) with ESMTP id 67719205EA for ; Mon, 19 Oct 2015 15:56:15 +0000 (UTC) Received: by alsa0.perex.cz (Postfix, from userid 1000) id 76F54265832; Mon, 19 Oct 2015 17:56:13 +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=-2.6 required=5.0 tests=BAYES_00,NO_DNS_FOR_FROM, RCVD_IN_DNSWL_LOW, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from alsa0.perex.cz (localhost [IPv6:::1]) by alsa0.perex.cz (Postfix) with ESMTP id 8D6AA265ADF; Mon, 19 Oct 2015 17:56:04 +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 A3215265AFF; Mon, 19 Oct 2015 17:56:03 +0200 (CEST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by alsa0.perex.cz (Postfix) with ESMTP id 766B22654BA for ; Mon, 19 Oct 2015 17:55:58 +0200 (CEST) Received: by wicfv8 with SMTP id fv8so12544965wic.0 for ; Mon, 19 Oct 2015 08:55:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=AYO4cZ7yjwVQCB68/pGQwND+pmhtV+/7LWFmi56eFKY=; b=iSa7pjcr0VD4IDSNCD7aUeSbylsT+Xr5Pv6zjlkAVo3B4kpc1thZtQ0pNGNT82qw6T eWU/T29+NB9jksg2tJETW67CFdk2evWqPNjG6xEmnu9psls3f+NiOjRnUGKEPiWYdvun Ewcjecx73IVwKKtYb95hUPYcZqLYTXMOzIqTyXvLJ3kV95raAyzFTk56SLitgewduAQn Ni+0gTpi1LJrHhgceTKGGxsPhmVeBjCiHv2el0EseOBlC23ra3GE//gctWUAzRElQWrb QLJpgtmqBsd/Te/QUZtRu03OtkNKULL/WFXrLYppKufJeUPXTTwqwYqVZXQ2BnaV22YW Kwgw== X-Gm-Message-State: ALoCoQkIKyQSiX/vGRMyyxaGwfwbk6YfPImJfA4+Nkmf6ghvH0ibP4hlo2vi1vwtcGR7mQnlnPBi X-Received: by 10.194.178.196 with SMTP id da4mr39499184wjc.41.1445270158061; Mon, 19 Oct 2015 08:55:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.90.139 with HTTP; Mon, 19 Oct 2015 08:55:38 -0700 (PDT) From: Caleb Crome Date: Mon, 19 Oct 2015 08:55:38 -0700 Message-ID: To: Arnaud Mouiche , "alsa-devel@alsa-project.org" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Subject: [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 Hello Arnaud, all, I'm trying to get the i.MX6 SSI working in 16-channel TDM mode. FYI, I'm working with the stock 4.3 kernel at https://github.com/torvalds/linux. When I apply the patch below, the SSI does all configure properly and even starts streaming properly with all the bits in the right place on the SSI pins. However, given a little bit of time and/or IO to the SD card, the bit-stream slips by 1 slot, causing all of the channels to be misaligned. My changes to the SSI driver are very minimal (shown below), and amount to forcing it into network (TDM) mode, and changing the maximum channels, and setting the STCCR DC mask. There is no indication from user space that anything has slipped, so the data stream just continues on shifted by 1 slot. You (Arnaud) mentioned in a previous thread ("Multiple codecs on one sound card for multi-channel sound card"), that I should just have to set channels_max (and presumably the other changes I mentioned), and it'll work mostly. However, it's very unreliable at the moment. Any thoughts to how I can diagnose this problem would be greatly appreciated! So, what happens is this: The SSI Starts sending data like this: SLOT 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 DATA 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 But then after time, something slips and without warning it goes to: SLOT 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 DATA 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ssi_private->dma_params_tx.addr = ssi_private->ssi_phys + CCSR_SSI_STX0; ssi_private->dma_params_rx.addr = ssi_private->ssi_phys + CCSR_SSI_SRX0; Thanks, -Caleb 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 * 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, }, Another thing I have tried is changing the watermark level for the fifo to give the DMA interrupt some extra time. The problem still happens, but seems to be a bit better. The fifo watermark change is this: diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index 73778c2..7c2e4b0 100644 --- a/sound/soc/fsl/fsl_ssi.c +++ b/sound/soc/fsl/fsl_ssi.c @@ -54,6 +54,8 @@ #include "fsl_ssi.h" #include "imx-pcm.h" +#define WATERMARK 8 + /** * FSLSSI_I2S_RATES: sample rates supported by the I2S * @@ -943,7 +950,7 @@ static int _fsl_ssi_set_dai_fmt(struct device *dev, * size. */ if (ssi_private->use_dma) - wm = ssi_private->fifo_depth - 2; + wm = ssi_private->fifo_depth - WATERMARK; else wm = ssi_private->fifo_depth; @@ -1260,8 +1267,8 @@ static int fsl_ssi_imx_probe(struct platform_device *pdev, * We have burstsize be "fifo_depth - 2" to match the SSI * watermark setting in fsl_ssi_startup(). */ - ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth - 2; - ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth - 2; + ssi_private->dma_params_tx.maxburst = ssi_private->fifo_depth - WATERMARK; + ssi_private->dma_params_rx.maxburst = ssi_private->fifo_depth - WATERMARK;