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 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
    Assuming you have read that, I write hence ...

    A solution to Board-3 would work for Board-1,2 as well.
    Rather this is how every dmac driver should be written, imho.

    For a dmac driver, allocating a channel should be purely a s/w thing i.e, just
    as a way for it to see what features the client needs and inform
    immediately if it is impossible. Successful return of channel must not be
    taken as a guarantee of any successful transfer by the clients.
    Nothing esoteric, but important to keep in mind nonetheless.

    Since Board-3 has fpga-mux routing req-sigs, probably more number
    of peripherals could be reached on board-3. Anyways, the dmac driver would
    get every reachable h/w channel from board via platform and happily
    allot to clients as if every channel is available all the time.

    As a design, your dmac driver should lock as less h/w resources as possible
    during channel allocation - ideally, zero, and it should be possible when
    afterall the dmac-driver can't guarantee success of xfers.

    //Just before starting the xfers.
    if (plat->rs_activate) // NULL for board-1 and 2
    err = plat->rs_activate(DMACd_RSs)
    else
    err = 0;
    ......do xfers .....
    //After xfers-done 'irq'
    if (plat->rs_deactivate) // NULL for board-1 and 2
    plat->rs_deactivate(DMACd_RSs)
    Depending upon time taken by rs_activate, you might want to schedule
    rs_deactivate after sometime rather than calling it immediately.

    This also indicates submitting xfers in batches, a good practice for clients.

    All of the above is to prove that -- Runtime switching isn't as big a deal as
    is made out to be. It should be done _transparently_ to the Client drivers.
    So, shouldn't be a part of the DMAENGINE API.

    So basically your setup should work just as fine as any other
    statically allocated
    req-signals. i.e, from the DMAENGINE API pov.

    Thanks
    --
    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 15:11    [from the cache]
    ©2003-2014 Jasper Spaans. Advertise on this site