linux-kernel - Re: [PATCHv2] DMAEngine: Let dmac drivers to set chan

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: <20110730142221.GA17081@flint.arm.linux.org.uk>
Date:	Sat, 30 Jul 2011 15:22:21 +0100
From:	Russell King <rmk@....linux.org.uk>
To:	Jaswinder Singh <jaswinder.singh@...aro.org>
Cc:	"Koul, Vinod" <vinod.koul@...el.com>,
	"Williams, Dan J" <dan.j.williams@...el.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-kernel@...r.kernel.org, linus.walleij@...ricsson.com,
	per.friden@...ricsson.com, wei.zhang@...escale.com,
	ebony.zhu@...escale.com, iws@...o.caltech.edu,
	s.hauer@...gutronix.de, maciej.sosnowski@...el.com,
	saeed@...vell.com, shawn.guo@...escale.com, yur@...raft.com,
	agust@...x.de, iwamatsu.nobuhiro@...esas.com,
	per.forlin@...ricsson.com, jonas.aberg@...ricsson.com,
	anemo@....ocn.ne.jp
Subject: Re: [PATCHv2] DMAEngine: Let dmac drivers to set chan_id

On Sat, Jul 30, 2011 at 06:39:13PM +0530, Jaswinder Singh wrote:
> On 29 July 2011 04:10, Russell King <rmk@....linux.org.uk> wrote:
> 
> >> > Board 3 has the MMCI connected through an external FPGA mux, which can route the
> >> > MMCI requests to DMA request signals #1, #2 or #3.
> >> Say
> >>  Board3
> >>      MMCI_RX  -> #{1,2,3}
> >>      MMCI_TX  -> #{1,2,3}
> >> And you can't change the route(mapping) after the dmac driver has
> >> been loaded.
> >
> > No.  You have to change it dynamically at run time according to the
> > DMA activity, because DMA request signals #1, #2 and #3 are shared
> > between 6 devices.  To make matters worse, it's not six on any of
> > RQ#1 RQ#2 RQ#3, but some on a couple, some on another couple, and
> > some on all three.
> >
> > BTW, we do support this with Linus W's code (which he's posted to
> > this thread.)
> 
> In case you missed my reply to these runtime switching cases,
> please have a look at https://lkml.org/lkml/2011/7/29/211

Stop pointing me at archives.  I'm not reading links during an email
discussion.  It's bad enough the mass of words that you include in
your replies to work out what you're saying.

And actually now, I'm completely lost over exactly what provides what
with your idea.

Could you please put together a _complete_ example of how you see my
board examples #1, #2 and #3 working, covering your _entire_ idea in
one _single_ _concise_ email with no references elsewhere, covering
in each case:

- how a peripheral device driver obtains, is allocated, or is provided with
  this 'capability' mask.
- how a DMA engine driver is told which 'capability' masks from peripheral
  drivers it is to match.
- how that is translated to a DMA device channels.
- how that translates to DMA request signals attached directly to the DMA
  device.
- how that translates to DMA request signals attached to some kind of MUX
  which in turn is attached to a DMA request signal attached to the DMA
  device.

Better still, do it in pseudo-C code, or real C code if you think that'll
help (there's nothing like seeing the actual code.)

You have for reference:
1. The AMBA drivers in the kernel tree (MMCI, PL011 UART).
	drivers/tty/serial/amba-pl011.c
	drivers/mmc/host/mmci.c
2. The DMA engine code for PL080 in the kernel tree.
	drivers/dma/amba-pl08x.c
3. Linus' example code for the Versatile/Realview platforms.
	(attached to his email.)

This is enough to cover the cases I outlined in boards #1,#2,#3.

To tie this down further, into real hardware, so lets say:
board #1: is Versatile PB926 with an on-board UART0 - so DMA controller
	request signal #14 for receive and DMA controller request signal
	#15 for transmit.

board #2: is Realview EB with an on-board UART1 - so DMA controller
	request signal #12 (RX) and #13 (TX).

board #3: is Versatile PB926 with the FPGA-implemented MMCI1 - so
	DMA controller request signals #0 to #2 inclusive may be used,
	via three separate MUXes (one per request signal) requiring
	the selected mux to be programmed with value '5'.  This same
	channel can be used for either DMA-to-device or DMA-from-device,
	but the MMCI device driver may request two separate 'dma channels'
	if they are available.

	To ensure all cases are covered, please assume that the AACI
	is also using DMA continuously for a long time in this case,
	which may be using any of #0 to #2 via the mux, and so how
	the AACI's in-use DMA device request signal is avoided.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
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/