linux-kernel - Re: [PATCH] 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: <CAMuHMdXEH9koVnSS3EWjyUiiSOOOU3EdcT9JHAWNpfmVWQ2opQ@mail.gmail.com>
Date:	Tue, 5 Aug 2014 10:16:37 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:	Dan Williams <dan.j.williams@...el.com>,
	Vinod Koul <vinod.koul@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>, dmaengine@...r.kernel.org,
	Russell King <linux@....linux.org.uk>,
	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>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Ludovic Desroches <ludovic.desroches@...el.com>,
	Gregory Clement <gregory.clement@...e-electrons.com>,
	Nicolas Ferre <nicolas.ferre@...el.com>
Subject: Re: [PATCH] Documentation: dmaengine: Add a documentation for the dma
 controller API

Hi Maxime,

On Wed, Jul 30, 2014 at 6:03 PM, Maxime Ripard
<maxime.ripard@...e-electrons.com> wrote:
> The dmaengine is neither trivial nor properly documented at the moment, which
> means a lot of trial and error development, which is not that good for such a
> central piece of the system.
>
> Attempt at making such a documentation.

Great, thanks!

> +Our dma_device structure has a field called caps_mask that holds the
> +various type of transaction supported, and you need to modify this

types of transactions

> +mask using the dma_cap_set function, with various flags depending on
> +transaction types you support as an argument.

> +  * DMA_SLAVE
> +    - The device can handle device to memory transfers, including
> +      scatter-gather transfers.
> +    - While in the mem2mem case we were having two distinct type to

types

> +      deal with a single chunk to copy or a collection of them, here,
> +      we just have a single transaction type that is supposed to
> +      handle both.

> +  * DMA_INTERLEAVE
> +    - The device support interleaved transfer. Those transfers usually

supports

> +      involve an interleaved set of data, with chunks a few bytes
> +      wide, where a scatter-gather transfer would be quite
> +      inefficient.

> +The functions that we have to fill in there, and hence have to
> +implement, obviously depend on the transaction type you reported as

types

> +supported.

> +   * device_issue_pending
> +     - Takes the first descriptor in the pending queue, and start the

starts

> +       transfer. Whenever that transfer is done, it should move to the
> +       next transaction in the list.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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/