lkml.org 
[lkml]   [2011]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@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.

--
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@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 16:25    [from the cache]
©2003-2011 Jasper Spaans