Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Serge Semin <fancer.lancer@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>,
	Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>,
	Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Arnd Bergmann <arnd@arndb.de>, Feng Tang <feng.tang@intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Rob Herring <robh+dt@kernel.org>, <linux-mips@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	linux-spi <linux-spi@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 03/16] spi: dw: Locally wait for the DMA transactions completion
Date: Fri, 29 May 2020 11:12:04 +0300	[thread overview]
Message-ID: <20200529081204.e2j5unvvfikr2y7v@mobilestation> (raw)
In-Reply-To: <CAHp75VcT2zKnuRW3uxCQtbF0A65cbS20OFpz9sX0hftbjFp1hA@mail.gmail.com>

On Fri, May 29, 2020 at 10:55:32AM +0300, Andy Shevchenko wrote:
> On Fri, May 29, 2020 at 7:02 AM Serge Semin
> <Sergey.Semin@baikalelectronics.ru> 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

  reply	other threads:[~2020-05-29  8:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-29  3:58 [PATCH v5 00/16] spi: dw: Add generic DW DMA controller support Serge Semin
2020-05-29  3:58 ` [PATCH v5 01/16] spi: dw: Set xfer effective_speed_hz Serge Semin
2020-05-29  8:49   ` Sergei Shtylyov
2020-05-29  9:49     ` Serge Semin
2020-05-29  3:59 ` [PATCH v5 02/16] spi: dw: Return any value retrieved from the dma_transfer callback Serge Semin
2020-05-29  3:59 ` [PATCH v5 03/16] spi: dw: Locally wait for the DMA transactions completion Serge Semin
2020-05-29  7:55   ` Andy Shevchenko
2020-05-29  8:12     ` Serge Semin [this message]
2020-05-29  9:26       ` Andy Shevchenko
2020-05-29  9:56         ` Serge Semin
2020-05-29  3:59 ` [PATCH v5 04/16] spi: dw: Add SPI Tx-done wait method to DMA-based transfer Serge Semin
2020-05-29  3:59 ` [PATCH v5 05/16] spi: dw: Add SPI Rx-done " Serge Semin
2020-05-29  9:46   ` Andy Shevchenko
2020-05-29 10:13     ` Serge Semin
2020-05-29 10:20       ` Andy Shevchenko
2020-05-29  3:59 ` [PATCH v5 06/16] spi: dw: Parameterize the DMA Rx/Tx burst length Serge Semin
2020-05-29  3:59 ` [PATCH v5 07/16] spi: dw: Use DMA max burst to set the request thresholds Serge Semin
2020-05-29  3:59 ` [PATCH v5 08/16] spi: dw: Fix Rx-only DMA transfers Serge Semin
2020-05-29  3:59 ` [PATCH v5 09/16] spi: dw: Add core suffix to the DW APB SSI core source file Serge Semin
2020-05-29  3:59 ` [PATCH v5 10/16] spi: dw: Move Non-DMA code to the DW PCIe-SPI driver Serge Semin
2020-05-29  3:59 ` [PATCH v5 11/16] spi: dw: Remove DW DMA code dependency from DW_DMAC_PCI Serge Semin
2020-05-29  3:59 ` [PATCH v5 12/16] spi: dw: Add DW SPI DMA/PCI/MMIO dependency on the DW SPI core Serge Semin
2020-05-29  3:59 ` [PATCH v5 13/16] spi: dw: Cleanup generic DW DMA code namings Serge Semin
2020-05-29  3:59 ` [PATCH v5 14/16] spi: dw: Add DMA support to the DW SPI MMIO driver Serge Semin
2020-05-29  3:59 ` [PATCH v5 15/16] spi: dw: Use regset32 DebugFS method to create regdump file Serge Semin
2020-05-29  3:59 ` [PATCH v5 16/16] dt-bindings: spi: Convert DW SPI binding to DT schema Serge Semin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200529081204.e2j5unvvfikr2y7v@mobilestation \
    --to=sergey.semin@baikalelectronics.ru \
    --cc=Alexey.Malahov@baikalelectronics.ru \
    --cc=Georgy.Vlasov@baikalelectronics.ru \
    --cc=Ramil.Zaripov@baikalelectronics.ru \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=fancer.lancer@gmail.com \
    --cc=feng.tang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=tsbogend@alpha.franken.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox