From patchwork Tue Feb 24 15:32:57 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Torsten Fleischer X-Patchwork-Id: 5873391 Return-Path: X-Original-To: patchwork-linux-spi@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 7FBB1BF440 for ; Tue, 24 Feb 2015 15:33:19 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 1DED020373 for ; Tue, 24 Feb 2015 15:33:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8F1732037F for ; Tue, 24 Feb 2015 15:33:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752246AbbBXPdI (ORCPT ); Tue, 24 Feb 2015 10:33:08 -0500 Received: from mail-wi0-f173.google.com ([209.85.212.173]:48865 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751436AbbBXPdH (ORCPT ); Tue, 24 Feb 2015 10:33:07 -0500 Received: by mail-wi0-f173.google.com with SMTP id bs8so26412165wib.0 for ; Tue, 24 Feb 2015 07:33:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=8mExHqJl8E8XexsonnQKIMcQWhEm7WuVONku3sc7ufk=; b=Px5VaGVV3YdwqdzfJUX0eHoXUwEmKFzQMbJ86Cw1ibzEQXr64NILo3q64zH9yzV89n B78jWTOzuBjux2yddzZL7u/uMBJpmZ3ZPVa1mjb6f2UR8RdOTX5xC3HmYbP/SRHlbUIm xTUsAnyeuYUFvQ3JR+SEZK0y6Q2aBqxJKZ+pKymvy3D54iTFfRkueVzg7EiM7DzS8zzZ vvxsbmtzigalrjxQKgvCyvXwZqe5YSCFp3TMWIMsztBSkfDS3q4orRcA7Fnk4pA6Bafn rov4PFjDWgzpNwDz+FRlIDyIv32USErRfU3yCJmMTPD1VYQcbtIssyeU8zajrlRujK+M QCTA== X-Received: by 10.180.36.212 with SMTP id s20mr31521507wij.58.1424791985480; Tue, 24 Feb 2015 07:33:05 -0800 (PST) Received: from linux-1fbo.site.Speedport_W723_V_Typ_A_1_01_009 (p5798B0F3.dip0.t-ipconnect.de. [87.152.176.243]) by mx.google.com with ESMTPSA id uc18sm4277036wib.0.2015.02.24.07.33.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 24 Feb 2015 07:33:04 -0800 (PST) From: Torsten Fleischer X-Google-Original-From: Torsten Fleischer To: nicolas.ferre@atmel.com, broonie@kernel.org, linux-spi@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: Torsten Fleischer Subject: [PATCH 1/1] spi: atmel: Fix interrupt setup for PDC transfers Date: Tue, 24 Feb 2015 16:32:57 +0100 Message-Id: <1424791977-2178-1-git-send-email-torfl6749@gmail.com> X-Mailer: git-send-email 2.1.4 Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Torsten Fleischer Additionally to the current DMA transfer the PDC allows to set up a next DMA transfer. This is useful for larger SPI transfers. The driver currently waits for ENDRX as end of the transfer. But ENDRX is set when the current DMA transfer is done (RCR = 0), i.e. it doesn't include the next DMA transfer. Thus a subsequent SPI transfer could be started although there is currently a transfer in progress. This can cause invalid accesses to the SPI slave devices and to SPI transfer errors. This issue has been observed on a hardware with a M25P128 SPI NOR flash. So instead of ENDRX we should wait for RXBUFF. This flag is set if there is no more DMA transfer in progress (RCR = RNCR = 0). Signed-off-by: Torsten Fleischer --- drivers/spi/spi-atmel.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c index 9af7841..06de340 100644 --- a/drivers/spi/spi-atmel.c +++ b/drivers/spi/spi-atmel.c @@ -764,17 +764,17 @@ static void atmel_spi_pdc_next_xfer(struct spi_master *master, (unsigned long long)xfer->rx_dma); } - /* REVISIT: We're waiting for ENDRX before we start the next + /* REVISIT: We're waiting for RXBUFF before we start the next * transfer because we need to handle some difficult timing - * issues otherwise. If we wait for ENDTX in one transfer and - * then starts waiting for ENDRX in the next, it's difficult - * to tell the difference between the ENDRX interrupt we're - * actually waiting for and the ENDRX interrupt of the + * issues otherwise. If we wait for TXBUFE in one transfer and + * then starts waiting for RXBUFF in the next, it's difficult + * to tell the difference between the RXBUFF interrupt we're + * actually waiting for and the RXBUFF interrupt of the * previous transfer. * * It should be doable, though. Just not now... */ - spi_writel(as, IER, SPI_BIT(ENDRX) | SPI_BIT(OVRES)); + spi_writel(as, IER, SPI_BIT(RXBUFF) | SPI_BIT(OVRES)); spi_writel(as, PTCR, SPI_BIT(TXTEN) | SPI_BIT(RXTEN)); }