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.028 / U:1.032 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site