All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Vinod Koul <vkoul@kernel.org>, Viresh Kumar <vireshk@kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Serge Semin <fancer.lancer@gmail.com>,
	Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
	Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Rob Herring <robh+dt@kernel.org>,
	dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/5] dmaengine: dw: Activate FIFO-mode for memory peripherals only
Date: Thu, 30 Jul 2020 19:24:28 +0300	[thread overview]
Message-ID: <20200730162428.GU3703480@smile.fi.intel.com> (raw)
In-Reply-To: <20200730154545.3965-3-Sergey.Semin@baikalelectronics.ru>

On Thu, Jul 30, 2020 at 06:45:42PM +0300, Serge Semin wrote:
> CFGx.FIFO_MODE field controls a DMA-controller "FIFO readiness" criterion.
> In other words it determines when to start pushing data out of a DW
> DMAC channel FIFO to a destination peripheral or from a source
> peripheral to the DW DMAC channel FIFO. Currently FIFO-mode is set to one
> for all DW DMAC channels. It means they are tuned to flush data out of
> FIFO (to a memory peripheral or by accepting the burst transaction
> requests) when FIFO is at least half-full (except at the end of the block
> transfer, when FIFO-flush mode is activated) and are configured to get
> data to the FIFO when it's at least half-empty.
> 
> Such configuration is a good choice when there is no slave device involved
> in the DMA transfers. In that case the number of bursts per block is less
> than when CFGx.FIFO_MODE = 0 and, hence, the bus utilization will improve.
> But the latency of DMA transfers may increase when CFGx.FIFO_MODE = 1,
> since DW DMAC will wait for the channel FIFO contents to be either
> half-full or half-empty depending on having the destination or the source
> transfers. Such latencies might be dangerous in case if the DMA transfers
> are expected to be performed from/to a slave device. Since normally
> peripheral devices keep data in internal FIFOs, any latency at some
> critical moment may cause one being overflown and consequently losing
> data. This especially concerns a case when either a peripheral device is
> relatively fast or the DW DMAC engine is relatively slow with respect to
> the incoming data pace.
> 
> In order to solve problems, which might be caused by the latencies
> described above, let's enable the FIFO half-full/half-empty "FIFO
> readiness" criterion only for DMA transfers with no slave device involved.

> Thanks to the commit ???????????? ("dmaengine: dw: Initialize channel

See below.

> before each transfer") we can freely do that in the generic
> dw_dma_initialize_chan() method.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Thanks!

> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> 
> ---
> 
> Note the DMA-engine repository git.infradead.org/users/vkoul/slave-dma.git
> isn't accessible. So I couldn't find out the Andy' commit hash to use it in
> the log.

It's dmaengine.git on git.kernel.org.

> ---
>  drivers/dma/dw/dw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/dw/dw.c b/drivers/dma/dw/dw.c
> index 7a085b3c1854..d9810980920a 100644
> --- a/drivers/dma/dw/dw.c
> +++ b/drivers/dma/dw/dw.c
> @@ -14,7 +14,7 @@
>  static void dw_dma_initialize_chan(struct dw_dma_chan *dwc)
>  {
>  	struct dw_dma *dw = to_dw_dma(dwc->chan.device);
> -	u32 cfghi = DWC_CFGH_FIFO_MODE;
> +	u32 cfghi = is_slave_direction(dwc->direction) ? 0 : DWC_CFGH_FIFO_MODE;
>  	u32 cfglo = DWC_CFGL_CH_PRIOR(dwc->priority);
>  	bool hs_polarity = dwc->dws.hs_polarity;
>  
> -- 
> 2.27.0
> 

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2020-07-30 16:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-30 15:45 [PATCH 0/5] dmaengine: dw: Introduce non-mem peripherals optimizations Serge Semin
2020-07-30 15:45 ` [PATCH 1/5] dt-bindings: dma: dw: Add optional DMA-channels mask cell support Serge Semin
2020-07-31 22:42   ` Rob Herring
2020-07-30 15:45 ` [PATCH 2/5] dmaengine: dw: Activate FIFO-mode for memory peripherals only Serge Semin
2020-07-30 16:24   ` Andy Shevchenko [this message]
2020-07-30 16:31     ` Serge Semin
2020-07-30 16:47       ` Andy Shevchenko
2020-07-30 17:13         ` Serge Semin
2020-07-31 16:52           ` Vinod Koul
2020-07-31 16:57             ` Serge Semin
2020-07-30 15:45 ` [PATCH 3/5] dmaengine: dw: Discard dlen from the dev-to-mem xfer width calculation Serge Semin
2020-07-30 16:28   ` Andy Shevchenko
2020-07-30 15:45 ` [PATCH 4/5] dmaengine: dw: Ignore burst setting for memory peripherals Serge Semin
2020-07-30 16:31   ` Andy Shevchenko
2020-07-30 16:37     ` Serge Semin
2020-07-30 15:45 ` [PATCH 5/5] dmaengine: dw: Add DMA-channels mask cell support Serge Semin
2020-07-30 16:41   ` Andy Shevchenko
2020-07-30 17:11     ` 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=20200730162428.GU3703480@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=Alexey.Malahov@baikalelectronics.ru \
    --cc=Pavel.Parkhomenko@baikalelectronics.ru \
    --cc=Sergey.Semin@baikalelectronics.ru \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=fancer.lancer@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter.ujfalusi@ti.com \
    --cc=robh+dt@kernel.org \
    --cc=vireshk@kernel.org \
    --cc=vkoul@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.