Eric Lee / smarc-ti-linux-kernel

18 Nov, 2011

1 commit

  • b14dab792   DMAEngine: Define interleaved transfer request api ... Browse Code »

    Define a new api that could be used for doing fancy data transfers
    like interleaved to contiguous copy and vice-versa.
    Traditional SG_list based transfers tend to be very inefficient in
    such cases as where the interleave and chunk are only a few bytes,
    which call for a very condensed api to convey pattern of the transfer.
    This api supports all 4 variants of scatter-gather and contiguous transfer.

    Of course, neither can this api help transfers that don't lend to DMA by
    nature, i.e, scattered tiny read/writes with no periodic pattern.

    Also since now we support SLAVE channels that might not provide
    device_prep_slave_sg callback but device_prep_interleaved_dma,
    remove the BUG_ON check.

    Signed-off-by: Jassi Brar
    Acked-by: Barry Song
    [renamed dmaxfer_template to dma_interleaved_template
    did fixup after the enum dma_transfer_merge]
    Signed-off-by: Vinod Koul

    Jassi Brar
     

27 Jul, 2011

1 commit

  • 5a42fb93e   Improve slave/cyclic DMA engine documentation ... Browse Code »

    Improve the documentation for the slave and cyclic DMA engine support
    reformatting it for easier reading, adding further APIs, splitting it
    into five steps, and including references to the documentation in
    dmaengine.h.

    Signed-off-by: Russell King
    [Fixed the index title to reflect new changes]
    Signed-off-by: Vinod Koul

    Russell King - ARM Linux
     

26 May, 2011

1 commit

06 Jan, 2009

1 commit

  • 28405d8d9   async_tx, dmaengine: document channel allocation and api rework ... Browse Code »

    "Wouldn't it be better if the dmaengine layer made sure it didn't pass
    the same channel several times to a client?

    I mean, you seem concerned that the memcpy() API should be transparent
    and easy to use, but the whole registration interface is just
    ridiculously complicated..."
    - Haavard

    The dmaengine and async_tx registration/allocation interface is indeed
    needlessly complicated. This redesign has the following goals:

    1/ Simplify reference counting: dma channels are not something one would
    expect to be hotplugged, it should be an exceptional event handled by
    drivers not something clients should be mandated to handle in a
    callback. The common case channel removal event is 'rmmod ',
    which for simplicity should be disallowed if the channel is in use.
    2/ Add an interface for requesting exclusive access to a channel
    suitable to device-to-memory users.
    3/ Convert all memory-to-memory users over to a common allocator, the goal
    here is to not have competing channel allocation schemes. The only
    competition should be between device-to-memory exclusive allocations and
    the memory-to-memory usage case where channels are shared between
    multiple "clients".

    Cc: Haavard Skinnemoen
    Cc: Neil Brown
    Cc: Jeff Garzik
    Reviewed-by: Andrew Morton
    Signed-off-by: Dan Williams

    Dan Williams