linux-kernel - Re: [PATCH v2] dma: omap-dma: add support for pause of non-cyclic transfers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150807162648.GR7576@n2100.arm.linux.org.uk>
Date:	Fri, 7 Aug 2015 17:26:48 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:	Vinod Koul <vinod.koul@...el.com>,
	Dan Williams <dan.j.williams@...el.com>,
	dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
	nsekhar@...com, linux-omap@...r.kernel.org,
	linux-serial@...r.kernel.org, john.ogness@...utronix.de,
	Peter Ujfalusi <peter.ujfalusi@...com>
Subject: Re: [PATCH v2] dma: omap-dma: add support for pause of non-cyclic
 transfers

On Fri, Aug 07, 2015 at 05:36:05PM +0200, Sebastian Andrzej Siewior wrote:
> +		/*
> +		 * We do not allow DMA_MEM_TO_DEV transfers to be paused.
> +		 * According to RMK the OMAP hardware might prefetch bytes from
> +		 * memory into its FIFO and not send it to the device due to the
> +		 * pause. The bytes in the FIFO are cleared on pause. It is
> +		 * unspecified by how many bytes the source address is updated
> +		 * if at all.

Would you mind rewording the above.

Please take the time to read the manuals for the device you are playing
with.  It's mostly documented in there.  See the OMAP4430 ES2.x TRM,
16.4.18 and 16.4.19.

16.4.19 states that:

 "When a source-synchronized channel is disabled during a transfer...
 "In all other cases, the channel undergoes an abort."

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 you clear the enable bit.

16.4.20.4.6.2 defines what happens when a channel aborts:

 "If an abort trigger occurs, the channel aborts immediately after
  completion of current read/write transactions and then FIFO is
  cleaned up."

It doesn't define what "cleaned up" means, so that's open to some
interpretation.  That's why I contacted TI about this back in 2012:
| What is the behaviour of the OMAP DMA hardware when the DMA4_CCRi[7]
| enable bit is cleared and subsequently set without any additional
| reprogramming?  I'm thinking specifically about memory-to-device DMA
| operations, in particular the UART ports.
| 
| Will this allow a transfer to be temporarily paused, and then
| subsequently resumed with out loss of data in the DMA hardware, as if
| nothing had actually happened?

The answer I received was 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.

The explanation went on to say that if the DMA hardware can't drain
the data in its FIFO to the destination, then data loss "might" occur.

That will occur if we're destination-synchronised (eg) to a UART and
the UART is not accepting any further data.

Due to this, the OMAP DMA engine driver was submitted with this in the
cover note:

"For the OMAP DMAengine driver, there's a few short-comings:

1. pause/resume support is not implemented; it's not clear whether the
   OMAP hardware is capable of supporting this sanely."

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/