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] [day] [month] [year] [list]
Message-ID: <CAJe_ZheN6zSXXc4NkZPY6QwO+tkjT3BaAbcpVydOkx6oEvTOGQ@mail.gmail.com>
Date:	Sat, 30 Jul 2011 20:30:07 +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 30 July 2011 19:52, Russell King <rmk@....linux.org.uk> wrote:
> 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.
>
Would love to.
But only after Linaro Connect of 1 week.. and then out of time not officially
assigned to it. So it might be soon or late.
--
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/