lkml.org 
[lkml]   [2011]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCHv2] DMAEngine: Let dmac drivers to set chan_id
From
On 30 July 2011 19:52, Russell King <rmk@arm.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@arm.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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2011-07-30 17:03    [W:0.069 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site