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]

Date:	Thu, 28 Jul 2011 23:40:38 +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 Thu, Jul 28, 2011 at 11:24:12PM +0530, Jaswinder Singh wrote:
> On 28 July 2011 02:07, Russell King <rmk@....linux.org.uk> wrote:
> >
> >> On a serious note, my proposal, and the reply, shows the possibility
> >> of having :-
> >> a) Client drivers that are truly platform agnostic -- no platform_data
> >> poking for
> >>       channel selection
> >
> > I really doubt that's even possible.  Take this setup:
> 
> I don't want to suggest anything wrong just because I didn't understand
> your h/w.
> I hope you will be kind enough to help me better understand your setup,
> so that I have a fair chance to present my proposal.
> 
> A simple 'yes' or a 'no'(with clarification) is all I ask.
> 
> >
> > MMCI ---> DMAC
> >
> > where the DMAC has 32 request signals, and 8 channels.
> The DMAC is similar to PL330.

That coincidence is merely that.

> Only max 8 request-signals can be active at any time.
> Is my understanding right ?

Correct.

> > The MMCI is connected to two of them.
> I don't know anything about MMCI.
> So I assume it is just another third party MMC controller.
> It simply needs 2 dma channels(for RX, TX each) - be it from a DMAC
> that has a programmable RequestSignal->Peripheral map or a fixed map.
> Is my understanding right ?

Correct.

> > The DMAC can supply any of its physical channels for MMCI.
> The RequestSignal->Peripheral map is decided during board design
> and can not be changed later.
> Is my understanding right ?

No.  See the board#3 case..

> > Board 1 has the MMCI connected to request signals #1 and #3.
> > Board 2 has the MMCI connected to request signals #8 and #22.
> Say,
>  Board1
>      MMCI_RX  -> #1
>      MMCI_TX  -> #3
> 
>  Board2
>      MMCI_RX  -> #8
>      MMCI_TX  -> #22
> 
> > 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.)

-- 
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/