• Haavard Skinnemoen's avatar
    dmaengine: Add slave DMA interface · dc0ee643
    Haavard Skinnemoen authored
    This patch adds the necessary interfaces to the DMA Engine framework
    to use functionality found on most embedded DMA controllers: DMA from
    and to I/O registers with hardware handshaking.
    
    In this context, hardware hanshaking means that the peripheral that
    owns the I/O registers in question is able to tell the DMA controller
    when more data is available for reading, or when there is room for
    more data to be written. This usually happens internally on the chip,
    but these signals may also be exported outside the chip for things
    like IDE DMA, etc.
    
    A new struct dma_slave is introduced. This contains information that
    the DMA engine driver needs to set up slave transfers to and from a
    slave device. Most engines supporting DMA slave transfers will want to
    extend this structure with controller-specific parameters.  This
    additional information is usually passed from the platform/board code
    through the client driver.
    
    A "slave" pointer is added to the dma_client struct. This must point
    to a valid dma_slave structure iff the DMA_SLAVE capability is
    requested.  The DMA engine driver may use this information in its
    device_alloc_chan_resources hook to configure the DMA controller for
    slave transfers from and to the given slave device.
    
    A new operation for preparing slave DMA transfers is added to struct
    dma_device. This takes a scatterlist and returns a single descriptor
    representing the whole transfer.
    
    Another new operation for terminating all pending transfers is added as
    well. The latter is needed because there may be errors outside the scope
    of the DMA Engine framework that may require DMA operations to be
    terminated prematurely.
    
    DMA Engine drivers may extend the dma_device, dma_chan and/or
    dma_slave_descriptor structures to allow controller-specific
    operations. The client driver can detect such extensions by looking at
    the DMA Engine's struct device, or it can request a specific DMA
    Engine device by setting the dma_dev field in struct dma_slave.
    
    dmaslave interface changes since v4:
      * Fix checkpatch errors
      * Fix changelog (there are no slave descriptors anymore)
    
    dmaslave interface changes since v3:
      * Use dma_data_direction instead of a new enum
      * Submit slave transfers as scatterlists
      * Remove the DMA slave descriptor struct
    
    dmaslave interface changes since v2:
      * Add a dma_dev field to struct dma_slave. If set, the client can
        only be bound to the DMA controller that corresponds to this
        device.  This allows controller-specific extensions of the
        dma_slave structure; if the device matches, the controller may
        safely assume its extensions are present.
      * Move reg_width into struct dma_slave as there are currently no
        users that need to be able to set the width on a per-transfer
        basis.
    
    dmaslave interface changes since v1:
      * Drop the set_direction and set_width descriptor hooks. Pass the
        direction and width to the prep function instead.
      * Declare a dma_slave struct with fixed information about a slave,
        i.e. register addresses, handshake interfaces and such.
      * Add pointer to a dma_slave struct to dma_client. Can be NULL if
        the DMA_SLAVE capability isn't requested.
      * Drop the set_slave device hook since the alloc_chan_resources hook
        now has enough information to set up the channel for slave
        transfers.
    Acked-by: default avatarMaciej Sosnowski <maciej.sosnowski@intel.com>
    Signed-off-by: default avatarHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
    Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
    dc0ee643
dmaengine.c 17.7 KB