From patchwork Thu Jul 16 18:36:49 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Geert Uytterhoeven X-Patchwork-Id: 6810471 Return-Path: X-Original-To: patchwork-dmaengine@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 94E56C05AC for ; Thu, 16 Jul 2015 18:36:54 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 867DE20674 for ; Thu, 16 Jul 2015 18:36:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 81ECA205C6 for ; Thu, 16 Jul 2015 18:36:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751874AbbGPSgw (ORCPT ); Thu, 16 Jul 2015 14:36:52 -0400 Received: from andre.telenet-ops.be ([195.130.132.53]:48613 "EHLO andre.telenet-ops.be" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751434AbbGPSgv (ORCPT ); Thu, 16 Jul 2015 14:36:51 -0400 Received: from ayla.of.borg ([84.193.93.87]) by andre.telenet-ops.be with bizsmtp id t6cp1q00Z1t5w8s016cpS2; Thu, 16 Jul 2015 20:36:50 +0200 Received: from geert (helo=localhost) by ayla.of.borg with local-esmtp (Exim 4.82) (envelope-from ) id 1ZFo1Z-0000Fg-LU; Thu, 16 Jul 2015 20:36:49 +0200 Date: Thu, 16 Jul 2015 20:36:49 +0200 (CEST) From: Geert Uytterhoeven To: Laurent Pinchart cc: dmaengine@vger.kernel.org, linux-sh@vger.kernel.org Subject: Issues with rcar-dmac and sh-sci Message-ID: User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham 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 Hi Laurent, While working on DMA for R-Car Gen2 using the sh-sci serial driver with rcar-dmac, I ran into two issues: 1. Unlike the old shdmac DMA engine driver, the new rcar-dmac DMA engine driver does not support resubmitting a DMA descriptor. I first tried the patch below, until I ran into the race condition, after which I changed sh-sci to not reuse DMA descriptors. 2. rcar_dmac_chan_get_residue() has: static unsigned int rcar_dmac_chan_get_residue(struct rcar_dmac_chan *chan, dma_cookie_t cookie) { struct rcar_dmac_desc *desc = chan->desc.running; ... /* * If the cookie doesn't correspond to the currently running transfer * then the descriptor hasn't been processed yet, and the residue is * equal to the full descriptor size. */ if (cookie != desc->async_tx.cookie) return desc->size; If the cookie doesn't correspond to the currently running transfer, it returns the full descriptor size of the _currently running transfer_, not the transfer the cookie corresponds to. I believe this the reason why the sh-sci driver once thought DMA transfered 4294967265 (= -31) bytes (for SCIF, descriptor lengths are either 1 or 32 bytes, and (length) 1 - (residue) 32 = (transfered) -31). Thanks for your comments! From 589dbd908a59dba6efc2a78fca24645962235ec2 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 14 Jul 2015 11:27:14 +0200 Subject: [PATCH] [RFC] dmaengine: rcar-dmac: Allow resubmission of DMA descriptors Unlike the old shdmac DMA engine driver, the new rcar-dmac DMA engine driver does not support resubmitting a DMA descriptor. If a DMA slave resubmits a descriptor, the descriptor will be added to the "pending list", while it wasn't removed from the "wait" list. This will cause list corruption, leading to an infinite loop in rcar_dmac_chan_reinit(). Find out if the descriptor is reused by looking at the current cookie valie, and remove it from the other list if needed: - cookie is initialized to -EBUSY (by rcar-dma) for fresh and properly recycled descriptors, - cookie is set to a strict-positive value by dma_cookie_assign() (in core dmaengine code) on submission, - cookie is reset to zero by dma_cookie_complete() (in core dmaengine code) on completion, Fix this by removing it from a list if the cookie is not -EBUSY. FIXME Unfortunately this is racy: the recycled descriptors are not part of a list while the DMA descriptor callback is running. Signed-off-by: Geert Uytterhoeven --- drivers/dma/sh/rcar-dmac.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c index 11e5003a6cc27b40..92a8fddb025e6729 100644 --- a/drivers/dma/sh/rcar-dmac.c +++ b/drivers/dma/sh/rcar-dmac.c @@ -437,8 +437,20 @@ static dma_cookie_t rcar_dmac_tx_submit(struct dma_async_tx_descriptor *tx) unsigned long flags; dma_cookie_t cookie; + spin_lock_irqsave(&chan->lock, flags); + if (desc->async_tx.cookie != -EBUSY) { + /* + * If the descriptor is reused, it's currently part of a list. + * Hence it must be removed from that list first, before it can + * be added to the list of pending requests. + */ + dev_dbg(chan->chan.device->dev, "chan%u: resubmit active desc %p\n", + chan->index, desc); + list_del(&desc->node); + } + cookie = dma_cookie_assign(tx); dev_dbg(chan->chan.device->dev, "chan%u: submit #%d@%p\n",