linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Vinod Koul <vinod.koul@intel.com>,
	peter@hurleysoftware.com, Dan Williams <dan.j.williams@intel.com>,
	dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
	nsekhar@ti.com, linux-omap@vger.kernel.org,
	linux-serial@vger.kernel.org, john.ogness@linutronix.de
Subject: Re: [PATCH v3 3/3] dma: omap-dma: add support for pause of non-cyclic transfers
Date: Tue, 11 Aug 2015 13:30:57 +0100	[thread overview]
Message-ID: <20150811123057.GE7576@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <55C9E464.2060404@ti.com>

On Tue, Aug 11, 2015 at 03:02:44PM +0300, Peter Ujfalusi wrote:
> On 08/07/2015 11:00 PM, Sebastian Andrzej Siewior wrote:
> > +	/*
> > +	 * We do not allow DMA_MEM_TO_DEV transfers to be paused.
> > +	 * From the AM572x TRM, 16.1.4.18 Disabling a Channel During Transfer:
> > +	 * "When a channel is disabled during a transfer, the channel undergoes
> > +	 * an abort, unless it is hardware-source-synchronized …".
> > +	 * A source-synchronised channel is one where the fetching of data is
> > +	 * under control of the device. In other words, a device-to-memory
> > +	 * transfer. So, a destination-synchronised channel (which would be a
> > +	 * memory-to-device transfer) undergoes an abort if the the CCR_ENABLE
> > +	 * bit is cleared.
> > +	 * From 16.1.4.20.4.6.2 Abort: "If an abort trigger occurs, the channel
> > +	 * aborts immediately after completion of current read/write
> > +	 * transactions and then the FIFO is cleaned up." The term "cleaned up"
> > +	 * is not defined. TI recommends to check that RD_ACTIVE and WR_ACTIVE
> > +	 * are both clear _before_ disabling the channel, otherwise data loss
> > +	 * will occur.
> > +	 * The problem is that if the channel is active, then device activity
> > +	 * can result in DMA activity starting between reading those as both
> > +	 * clear and the write to DMA_CCR to clear the enable bit hitting the
> > +	 * hardware. If the DMA hardware can't drain the data in its FIFO to the
> > +	 * destination, then data loss "might" occur (say if we write to an UART
> > +	 * and the UART is not accepting any further data).
> 
> I don't know if you have checked it, but probably the TX DMA could be also
> used when the PRZEFETCH is disabled for the channel? Just a guess

The docs aren't very clear on that... and iirc Santosh's reply didn't
suggest that the prefetch bit had any influence on this behaviour.  Given
the wording in the documentation which seems to be quite explicit about
the conditions, and it omits talking about the prefetch bit, I can only
assume that the prefetch bit has no influence over this behaviour.

For example, what happens if the DMA to the device has started - the
device has raised its DMA request line.  The DMA controller has then gone
to memory and has fetched some data and incremented the source address.
Meanwhile, we've cleared the ENABLE bit.  What happens then?  Does the
DMA controller drain the read data to the device, or does it "clean up"
the FIFO by discarding the data?

Given that the conditions under which the FIFO is drained to the
destination are very specific, and which explicitly excludes destination-
synchronised transfers, the only conclusion that's possible without
knowing the implementation intimately is that the FIFO is "cleaned up"
which suggests that it's discarded rather than drained to the destination.

As this DMA controller is in all of the OMAP devices and similar, I
don't think we can rely on the behaviour of any one implementation
either - we don't know what the differences are between the
implementations in different generations of devices without TI providing
more detailed documentation in this area across their various devices.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

  reply	other threads:[~2015-08-11 12:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-07 20:00 omap-dma + 8250_omap: fix the dmaengine_pause() Sebastian Andrzej Siewior
2015-08-07 20:00 ` [PATCH 1/3] tty: serial: 8250_omap: do not use RX DMA if pause is not supported Sebastian Andrzej Siewior
2015-08-08  0:28   ` Peter Hurley
2015-08-08  9:03     ` Russell King - ARM Linux
2015-08-11  9:57       ` Vinod Koul
2015-08-08  9:32     ` Sebastian Andrzej Siewior
2015-08-08  9:57       ` Russell King - ARM Linux
2015-08-08 15:40       ` Greg KH
2015-08-10 11:54   ` Peter Ujfalusi
2015-08-10 12:19     ` Sebastian Andrzej Siewior
2015-08-10 13:00     ` Peter Hurley
2015-08-10 17:15       ` Russell King - ARM Linux
2015-08-07 20:00 ` [PATCH 2/3] dma: add __must_check annotation for dmaengine_pause() Sebastian Andrzej Siewior
2015-08-08  0:40   ` Peter Hurley
2015-08-11  9:58   ` Vinod Koul
2015-08-11 10:06     ` Russell King - ARM Linux
2015-08-11 12:34       ` Sebastian Andrzej Siewior
2015-08-21  8:32         ` Vinod Koul
2015-08-07 20:00 ` [PATCH v3 3/3] dma: omap-dma: add support for pause of non-cyclic transfers Sebastian Andrzej Siewior
2015-08-11 12:02   ` Peter Ujfalusi
2015-08-11 12:30     ` Russell King - ARM Linux [this message]
2015-08-11 12:43       ` Peter Ujfalusi

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=20150811123057.GE7576@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=bigeasy@linutronix.de \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=nsekhar@ti.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=peter@hurleysoftware.com \
    --cc=vinod.koul@intel.com \
    /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;
as well as URLs for NNTP newsgroup(s).