Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp339576ybm; Fri, 29 May 2020 01:14:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0sDV3ffvWFHMlnwkCN6fBGwwHk6Z7c5hmvhgl/iRhaAIrvSfOv8zg8Bwv/DrAneleekFs X-Received: by 2002:a50:fb1a:: with SMTP id d26mr7071305edq.83.1590740054414; Fri, 29 May 2020 01:14:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590740054; cv=none; d=google.com; s=arc-20160816; b=F70Q4lvoA+xdYI/VYE6PmeN+/8mQxJBqFhd3dhjBmpS33xTGveR7LlbKXu2jrtKORh ybfvwX7BG3kci7UGC5bkrqmdRsKnZ9rWyasTL6dlZmm3VXTBB8FVjVnv24BJwCyfXjzI Y+ke0fJL+bwgHXPi0G6vyuNoB/d9Z/Dne+tN1KnuhnCyI4JYzY3MNe57+I8MMideVLV7 msue9/wV1s8WhQ/aYi9/QxDK3+7bKrQtnKqlQtZCfl+C1cSOTEGvv1mqFJXeJCI0dPxz bCdpadym2mgyMxeRdke+YMlolo0YtW6+hDJ/O1o1nwLxsmapfZ+oZXD8EqmN1K3Iz8ob IWjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=UBRNYfwfv9ECT0nK/RIZfGkvMBQB0jbpdN3bVLYpP2M=; b=jglffHBtVqQUubj/l4iXRfrk+wBNaYpDD2kaZxnciIgOAd0fBstKJylcXuDfMx0tE3 po2Y9/HQ/1bZkxHJgjkupjGGW6RuXWA/LNza3MMII9Uyv3IPkP7E79CwiId0wYFiExkk WmUnb0n/F73K3+QLU/fBee/UI26e81+EVNeBp9n5e6vGpolXamMMiUgUuWPMf5nAcB3/ f4KKkbJglp1AGMeY7H69/egX/0laqavZZivqXVd6YvW4F4dj9oPNBXdZ8MWHr6u++4za 8evtQFgz7+yp3lwCUfn8/L2TcDSXgdc9oTHjcBY1Ss4IPJz5rJVntalOdX6OiUW9DP46 T13A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r7si5325918ejr.96.2020.05.29.01.13.50; Fri, 29 May 2020 01:14:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725971AbgE2IMJ (ORCPT + 99 others); Fri, 29 May 2020 04:12:09 -0400 Received: from mail.baikalelectronics.com ([87.245.175.226]:46466 "EHLO mail.baikalelectronics.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725681AbgE2IMJ (ORCPT ); Fri, 29 May 2020 04:12:09 -0400 Received: from localhost (unknown [127.0.0.1]) by mail.baikalelectronics.ru (Postfix) with ESMTP id E447B80307C7; Fri, 29 May 2020 08:12:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at baikalelectronics.ru Received: from mail.baikalelectronics.ru ([127.0.0.1]) by localhost (mail.baikalelectronics.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkI_dr0PXQ-3; Fri, 29 May 2020 11:12:05 +0300 (MSK) Date: Fri, 29 May 2020 11:12:04 +0300 From: Serge Semin To: Andy Shevchenko CC: Serge Semin , Mark Brown , Georgy Vlasov , Ramil Zaripov , Alexey Malahov , Thomas Bogendoerfer , Arnd Bergmann , Feng Tang , Andy Shevchenko , Rob Herring , , devicetree , linux-spi , Linux Kernel Mailing List Subject: Re: [PATCH v5 03/16] spi: dw: Locally wait for the DMA transactions completion Message-ID: <20200529081204.e2j5unvvfikr2y7v@mobilestation> References: <20200529035915.20790-1-Sergey.Semin@baikalelectronics.ru> <20200529035915.20790-4-Sergey.Semin@baikalelectronics.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 29, 2020 at 10:55:32AM +0300, Andy Shevchenko wrote: > On Fri, May 29, 2020 at 7:02 AM Serge Semin > wrote: > > > > Even if DMA transactions are finished it doesn't mean that the SPI > > transfers are also completed. It's specifically concerns the Tx-only > > SPI transfers, since there might be data left in the SPI Tx FIFO after > > the DMA engine notifies that the Tx DMA procedure is done. In order to > > completely fix the problem first the driver has to wait for the DMA > > transaction completion, then for the corresponding SPI operations to be > > finished. In this commit we implement the former part of the solution. > > > > Note we can't just move the SPI operations wait procedure to the DMA > > completion callbacks, since these callbacks might be executed in the > > tasklet context (and they will be in case of the DW DMA). In case of > > slow SPI bus it can cause significant system performance drop. > > I read commit message, I read the code. What's going on here since you > repeated xfer_completion (and its wait routine) from SPI core and I'm > wondering what happened to it? Why we are not calling > spi_finalize_current_transfer()? We discussed that in v4. You complained about using ndelay() for slow SPI bus, which may cause too long atomic context execution. We agreed. Since we can't wait in the tasklet context and using a dedicated kernel thread for waiting would be too much, Me and Mark agreed, that even if it causes us of the local wait-function re-implementation the best approach would be not to use the generic spi_transfer_wait() method, but instead wait for the DMA transactions locally in the DMA driver and just return 0 from the transfer_one callback indicating that the SPI transfer is finished and there is no need for SPI core to wait. As a lot of DMA-based SPI drivers do. If you don't understand what the commit message says, just say so. I'll reformulate it. -Sergey > > ... > > > dws->master->cur_msg->status = -EIO; > > - spi_finalize_current_transfer(dws->master); > > + complete(&dws->dma_completion); > > return IRQ_HANDLED; > > ... > > > +static int dw_spi_dma_wait(struct dw_spi *dws, struct spi_transfer *xfer) > > +{ > > + unsigned long long ms; > > + > > + ms = xfer->len * MSEC_PER_SEC * BITS_PER_BYTE; > > + do_div(ms, xfer->effective_speed_hz); > > + ms += ms + 200; > > + > > + if (ms > UINT_MAX) > > + ms = UINT_MAX; > > + > > + ms = wait_for_completion_timeout(&dws->dma_completion, > > + msecs_to_jiffies(ms)); > > + > > + if (ms == 0) { > > + dev_err(&dws->master->cur_msg->spi->dev, > > + "DMA transaction timed out\n"); > > + return -ETIMEDOUT; > > + } > > + > > + return 0; > > +} > > + > > /* > > * dws->dma_chan_busy is set before the dma transfer starts, callback for tx > > * channel will clear a corresponding bit. > > @@ -155,7 +184,7 @@ static void dw_spi_dma_tx_done(void *arg) > > return; > > > > dw_writel(dws, DW_SPI_DMACR, 0); > > - spi_finalize_current_transfer(dws->master); > > + complete(&dws->dma_completion); > > } > > > > static struct dma_async_tx_descriptor *dw_spi_dma_prepare_tx(struct dw_spi *dws, > > @@ -204,7 +233,7 @@ static void dw_spi_dma_rx_done(void *arg) > > return; > > > > dw_writel(dws, DW_SPI_DMACR, 0); > > - spi_finalize_current_transfer(dws->master); > > + complete(&dws->dma_completion); > > } > > > -- > With Best Regards, > Andy Shevchenko