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: <CACRpkdZ-dG9pSDdhUB0Vo+v4qt3cX0SvWBECj0P2w1nvnxYBew@mail.gmail.com>
Date:	Wed, 7 Mar 2012 10:55:16 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Guennadi Liakhovetski <g.liakhovetski@....de>,
	Vinod Koul <vinod.koul@...el.com>,
	linux-kernel@...r.kernel.org,
	Jassi Brar <jassisinghbrar@...il.com>,
	Narayanan G <narayanan.gopalakrishnan@...ricsson.com>,
	Per Forlin <per.forlin@...ricsson.com>
Subject: Re: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel()

On Wed, Mar 7, 2012 at 10:30 AM, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:

> The code required to support slave device transfers is very much the same
> for each driver (that's partly because I'm writing my drivers in the same
> way.)  Essentially, slave channels aren't physical channels themselves,
> but virtual channels which get assigned to physical channels at some point.

Actually in the COH901318 driver each device has a dedicated physical
channel. It looks like some hardware engineer took the PL080 VHDL
code and just copy/pasted as many instances of the channel engine as
was needed to provide a unique channel for each device.

I've been scratching my head over that when I've thought about
merging the two drivers, because the register set and LLI is actually
very similar.

> I would really like to see some common infrastructure for handling these
> virtual channels so I don't have to write yet another version of that code,
> and that's something I'll be working on.

Please go ahead with this! We have the same problem in the
DMA40 driver basically, but in this thing the hardware actually takes
care of the virtual-over-physical channel arbitration if you want to,
which makes the "virtual" channels have physical registers and
confusing things a bit.

(However in the DMA40 case it may be some point in actually trying to
just use the physical channels in that driver and have the dmaengine core
arbitrate these under some circumstances, we already have some
special flags to lock down certain physical channels.)

Yours,
Linus Walleij
--
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/