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:24:12 +0530
From:	Jaswinder Singh <jaswinder.singh@...aro.org>
To:	Russell King <rmk@....linux.org.uk>
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 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.
Only max 8 request-signals can be active at any time.
Is my understanding right ?

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

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

> 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.
Is my understanding right ?
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ