linux-kernel - Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request

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: <20120330103828.GC22981@n2100.arm.linux.org.uk>
Date:	Fri, 30 Mar 2012 11:38:28 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Guennadi Liakhovetski <g.liakhovetski@....de>,
	Vinod Koul <vinod.koul@...el.com>,
	linux-kernel@...r.kernel.org,
	Jassi Brar <jassisinghbrar@...il.com>,
	Magnus Damm <magnus.damm@...il.com>,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH/RFC] dmaengine: add a slave parameter to
	__dma_request_channel()

On Fri, Mar 30, 2012 at 07:44:09AM +0200, Linus Walleij wrote:
> However you're right (in some later mail) that we need to distinguish
> between RX/TX channels at this point, so I can agree we need some
> additional parameter, but that should be very abstract, not containing
> any custom stuff or any void * or something like that.

No you don't.  DMA engines can generally deal with transfers operating in
either direction on a single channel.

Where many of the restrictions come from is the way virtual channels are
bound to request signals.

Take for instance MMC, where that is strictly half-duplex.  You're either
transferring data to the card, or from the card.  Why would you want to
claim two channels _if_ there was some way to properly configure the DMA
engine between those two modes?

That's something which is lacking in the current DMA engine API, and the
reason is that the data required to do that is somewhat platform specific
and therefore nebulous.  Eg, it could require a different DMA handshake
signal, different external MUX selection, or something like that.

As I'm looking at converting OMAP to DMA engine, if we persist with our
current approach, I need 128 virtual DMA channels, one per request
signal.  It would be better to either create these on the fly or sort
out some way that channels can be _properly_ reconfigured between
different handshake lines.

Actually, I think that's the key thing: the handshake lines should be
the data involved in channel selection and nothing else - though as I've
pointed out already, there's the complication for external MUXing between
the DMA engine and the peripheral which makes that non-trivial.
--
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/