[lkml]   [2012]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH/RFC] dmaengine: add a slave parameter to __dma_request_channel()
    On Wed, Mar 7, 2012 at 10:18 AM, Guennadi Liakhovetski
    <> wrote:
    > [Vinod]
    >> I like the approach outlined by Linus W [1], where we can get the
    >> information from platform (DT, FW,....) and its presented to dmaengine.
    > I still don't see an answer to the very same question, that we've been
    > discussing over multiple threads and mails now: how do we use that, if
    > it's not a 1-to-1 mapping? I.e., many channels on many controllers can be
    > run-time configured for use with different client devices. Also the above
    > idea from Linus W doesn't directly address this.

    True, it's a new problem space.

    However I see nothing wrong in the basic idea that the platform data
    and/or device tree should supply a number of mappings with constraints
    to dmaengine, that eventually helps it to select and enable a proper

    For example in the regulator framework we have voltage constraints on
    the rails, and the subsystem infers the voltage from these constraints.
    Constraints in platform data are nice.

    So the way forward in my simple opinion is to get the core dmaengine
    to be aware of the applicable constraints and hand out DMA channels
    or NACK channel requests if these constraints cannot be satisfied.

    So when you write:

    > Whereas doing a reverse mapping: for each (potential)
    > DMA user reference a list of channels, that it can use - would be really
    > clumsy.

    I basically disagree. I think the knowledge of available channels
    and their characteristics should be known to the dmaengine
    core, and the core shall select what channel to use.

    Else I fear we end up with a lot of logic distributed all over the
    place with no consolidation in sight, it will just grow everywhere
    with each new DMA controller.

    However it may need to have a different form given what Russell
    says: many drivers tend to have a number of arbitrable channels
    and the constraints is really about which event line (burst/single
    request line) to mux in for that one channel. So the platform
    data may need to take a form that better reflects this, which in
    turn necessitates that the dmaengine core and channel request
    interface be refactored to be aware of this kind of DMAC slaves.

    It requires a bit of upfront code but I think this is the way forward.
    Besides, Russell says he's already working on refactoring one
    part of the problem (virtual channels / request lines) if I understand
    him correctly.

    Linus Walleij

     \ /
      Last update: 2012-03-07 10:49    [W:0.022 / U:10.840 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site