linux-kernel - Re: [PATCH v2 2/2] Documentation: dmaengine: Add a documentation for the dma controller API

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: <20141008120757.GT1638@intel.com>
Date:	Wed, 8 Oct 2014 17:37:57 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:	Russell King <linux@....linux.org.uk>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Dan Williams <dan.j.williams@...el.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	dmaengine@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
	Antoine Ténart <antoine@...e-electrons.com>,
	Thomas Petazzoni <thomas@...e-electrons.com>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Boris Brezillon <boris@...e-electrons.com>,
	Matt Porter <matt.porter@...aro.org>,
	Gregory Clement <gregory.clement@...e-electrons.com>
Subject: Re: [PATCH v2 2/2] Documentation: dmaengine: Add a documentation
 for the dma controller API

On Tue, Oct 07, 2014 at 04:52:26PM +0200, Maxime Ripard wrote:
> > >> +Moreover, some DMA controllers, whenever the RAM is involved, can
> > > 
> > > s/the RAM is involved/RAM is used as a source or destination/ ?
> > > 
> > >> +group the reads or writes in memory into a buffer, so instead of
> > >> +having a lot of small memory accesses, which is not really efficient,
> > >> +you'll get several bigger transfers. This is done using a parameter
> > >> +called the burst size, that defines how many single reads/writes it's
> > >> +allowed to do in a single clock cycle.
> > 
> > Yes, here "single" word is used for different concepts and can have
> > several meanings. We usually make the difference between "single"
> > accesses and "burst" accesses.
> 
> Which was kind of what I was explaining, but it was probably not clear
> enough.
The burst can be in multiple clock cycles as well, so any reference to
clocks may not be right across various dma controllers.

Generically burst size is defined as a chunk of data transfer dma
controller would perform in single shot (may happen in 1 or multiple clock
cycles). The dma controller won't break this.

This has a very special meaning wrt slave usages as it involves FIFO (not
much of importance in memory copy ops where you want max burst for
performance). DMA transfer should not push data more than FIFO capacity,
ditto for pull as well.

Consider FIFO of 16 data items (beware not bytes), and burst being 8 and
watermark 8. So we will transfer 8 then 8 and so on.. ensures FIFO is
typically full or half.

> > >> +         + DMA_TERMINATE_ALL
> > >> +           + Aborts all the pending and ongoing transfers on the
> > >> +             channel
> > >> +           + This command should operate synchronously on the channel,
> > >> +             terminating right away all the channels
> > 
> > Is it a strong requirement to "terminate right away" all the transfers
> > on the channel? Must the ongoing transfer be stopped of can it ends its
> > current chunk?
> 
> Since it's blocking, I guess it's fine to wait for the current chunk
> to end as long as you block. But I'm not 100% sure on that. Russell? Vinod?
Typically terminate_all would be called in error or timeout scenario. So
current transfer may not complete, so aborting right away would be the right
approach


-- 
~Vinod

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)