From patchwork Fri Oct 16 10:26:17 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Ogness X-Patchwork-Id: 7413441 Return-Path: X-Original-To: patchwork-linux-arm@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 213109F36A for ; Fri, 16 Oct 2015 10:28:43 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3504D20A36 for ; Fri, 16 Oct 2015 10:28:42 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 46BA420A35 for ; Fri, 16 Oct 2015 10:28:41 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Zn2Ds-0005Rk-7P; Fri, 16 Oct 2015 10:26:52 +0000 Received: from galois.linutronix.de ([2001:470:1f0b:db:abcd:42:0:1]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Zn2Dm-0005NO-HE for linux-arm-kernel@lists.infradead.org; Fri, 16 Oct 2015 10:26:49 +0000 Received: from localhost ([127.0.0.1] helo=vostro.local) by Galois.linutronix.de with esmtp (Exim 4.80) (envelope-from ) id 1Zn2DN-0002qj-Dr; Fri, 16 Oct 2015 12:26:21 +0200 From: John Ogness To: linux-kernel@vger.kernel.org Subject: [PATCH v2] ARM: edma: fix residue race for cyclic References: <87io68s931.fsf@linutronix.de> <561F862A.7040106@ti.com> Date: Fri, 16 Oct 2015 12:26:17 +0200 In-Reply-To: <561F862A.7040106@ti.com> (Peter Ujfalusi's message of "Thu, 15 Oct 2015 13:55:38 +0300") Message-ID: <87eggvt8hi.fsf_-_@linutronix.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001, URIBL_BLOCKED=0.001 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20151016_032648_866996_FCB4658A X-CRM114-Status: GOOD ( 21.40 ) X-Spam-Score: -4.2 (----) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: dmaengine@vger.kernel.org, vinod.koul@intel.com, nsekhar@ti.com, linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, 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 When retrieving the residue value for cyclic transfers, the SRC/DST fields of the active PaRAM are read. However, the AM335x Technical Reference Manual states: 11.3.3.6 Parameter Set Updates After the TR is read from the PaRAM (and is in the process of being submitted to the EDMA3TC), the following fields are updated as needed: ... SRC DST This means SRC/DST is incremented even though the DMA transfer may not have started yet or is in progress. Thus if the reader of the residue accesses the DMA buffer too quickly, the CPU is misinformed about the data that has been successfully processed. The CCSTAT.ACTV register is a boolean that is set if any TR is being processed by either the EMDA3CC or EDMA3TC. By polling this register it is possible to ensure that the residue value returned is valid for immediate processing. However, since the DMA engine may be active, polling may never hit a moment where no TR is being processed. To handle this, the SRC/DST is also polled to see if it changes. And as a last resort, a max loop count for the busy waiting exists to avoid an infinite loop. Signed-off-by: John Ogness --- v1-v2 changes . rebased for next-20151016 . added multiple exit conditions for busy wait loop drivers/dma/edma.c | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index 7eefbf1..8d3b3ac 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -24,6 +24,8 @@ #include #include #include +#include +#include #include #include #include @@ -1785,11 +1787,24 @@ static void edma_issue_pending(struct dma_chan *chan) spin_unlock_irqrestore(&echan->vchan.lock, flags); } +#define EDMA_CCSTAT_ACTV (1 << 4) + +/* + * This limit exists to avoid a possible infinite loop when waiting + * for confirmation that a particular transfer is completed. However, + * large bursts to/from slow devices might actually require many + * loops (in which case busy waiting is bad anyway). On an AM335x + * transfering 48 bytes from the UART RX-FIFO, as many as 55 loops + * have been seen. + */ +#define EDMA_MAX_TR_WAIT_LOOPS 10000 + static u32 edma_residue(struct edma_desc *edesc) { bool dst = edesc->direction == DMA_DEV_TO_MEM; struct edma_pset *pset = edesc->pset; dma_addr_t done, pos; + int loop_count = 0; int i; /* @@ -1799,6 +1814,31 @@ static u32 edma_residue(struct edma_desc *edesc) pos = edma_get_position(edesc->echan->ecc, edesc->echan->slot[0], dst); /* + * "pos" may represent a transfer request that is still being + * processed by the EDMACC or EDMATC. We will busy wait until + * one of the situations occurs: + * 1. no transfer requests are active + * 2. a different transfer request is being processed + * 3. we hit the loop limit + */ + while (edma_read(edesc->echan->ecc, EDMA_CCSTAT) & EDMA_CCSTAT_ACTV) { + /* check if a different transfer request is active */ + if (edma_get_position(edesc->echan->ecc, + edesc->echan->slot[0], dst) != pos) { + break; + } + + loop_count++; + if (loop_count == EDMA_MAX_TR_WAIT_LOOPS) { + pr_debug_ratelimited("%s: possibly returning " + "invalid residue\n", __func__); + break; + } + + cpu_relax(); + } + + /* * Cyclic is simple. Just subtract pset[0].addr from pos. * * We never update edesc->residue in the cyclic case, so we