18 Jul, 2008

1 commit


09 Jul, 2008

4 commits

  • 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: Maciej Sosnowski
    Signed-off-by: Haavard Skinnemoen
    Signed-off-by: Dan Williams

    Haavard Skinnemoen
     
  • In some cases client code may need the dma-driver to skip the unmap of source
    and/or destination buffers. Setting these flags indicates to the driver to
    skip the unmap step. In this regard async_xor is currently broken in that it
    allows the destination buffer to be unmapped while an operation is still in
    progress, i.e. when the number of sources exceeds the hardware channel's
    maximum (fixed in a subsequent patch).

    Acked-by: Saeed Bishara
    Acked-by: Maciej Sosnowski
    Acked-by: Haavard Skinnemoen
    Signed-off-by: Dan Williams

    Dan Williams
     
  • A DMA controller capable of doing slave transfers may need to know a
    few things about the slave when preparing the channel. We don't want
    to add this information to struct dma_channel since the channel hasn't
    yet been bound to a client at this point.

    Instead, pass a reference to the client requesting the channel to the
    driver's device_alloc_chan_resources hook so that it can pick the
    necessary information from the dma_client struct by itself.

    [dan.j.williams@intel.com: fixed up fsldma and mv_xor]
    Acked-by: Maciej Sosnowski
    Signed-off-by: Haavard Skinnemoen
    Signed-off-by: Dan Williams

    Haavard Skinnemoen
     
  • Haavard's dma-slave interface would like to test for exclusive access to a
    channel. The standard channel refcounting is not sufficient in that it
    tracks more than just client references, it is also inaccurate as reference
    counts are percpu until the channel is removed.

    This change also enables a future fix to deallocate resources when a client
    declines to use a capable channel.

    Acked-by: Haavard Skinnemoen
    Signed-off-by: Dan Williams

    Dan Williams
     

22 Apr, 2008

1 commit


18 Apr, 2008

3 commits

  • 'ack' is currently a simple integer that flags whether or not a client is done
    touching fields in the given descriptor. It is effectively just a single bit
    of information. Converting this to a flags parameter allows the other bits to
    be put to use to control completion actions, like dma-unmap, and capture
    results, like xor-zero-sum == 0.

    Changes are one of:
    1/ convert all open-coded ->ack manipulations to use async_tx_ack
    and async_tx_test_ack.
    2/ set the ack bit at prep time where possible
    3/ make drivers store the flags at prep time
    4/ add flags to the device_prep_dma_interrupt prototype

    Acked-by: Maciej Sosnowski
    Signed-off-by: Dan Williams

    Dan Williams
     
  • DMA drivers no longer need to be notified of dependency submission
    events as async_tx_run_dependencies and async_tx_channel_switch will
    handle the scheduling and execution of dependent operations.

    [sfr@canb.auug.org.au: extend this for fsldma]
    Acked-by: Shannon Nelson
    Signed-off-by: Dan Williams

    Dan Williams
     
  • Shrink struct dma_async_tx_descriptor and introduce
    async_tx_channel_switch to properly inject a channel switch interrupt in
    the descriptor stream. This simplifies the locking model as drivers no
    longer need to handle dma_async_tx_descriptor.lock.

    Acked-by: Shannon Nelson
    Signed-off-by: Dan Williams

    Dan Williams
     

31 Mar, 2008

1 commit


05 Mar, 2008

1 commit


07 Feb, 2008

2 commits

  • Pass a full set of flags to drivers' per-operation 'prep' routines.
    Currently the only flag passed is DMA_PREP_INTERRUPT. The expectation is
    that arch-specific async_tx_find_channel() implementations can exploit this
    capability to find the best channel for an operation.

    Signed-off-by: Dan Williams
    Acked-by: Shannon Nelson
    Reviewed-by: Haavard Skinnemoen

    Dan Williams
     
  • The tx_set_src and tx_set_dest methods were originally implemented to allow
    an array of addresses to be passed down from async_xor to the dmaengine
    driver while minimizing stack overhead. Removing these methods allows
    drivers to have all transaction parameters available at 'prep' time, saves
    two function pointers in struct dma_async_tx_descriptor, and reduces the
    number of indirect branches..

    A consequence of moving this data to the 'prep' routine is that
    multi-source routines like async_xor need temporary storage to convert an
    array of linear addresses into an array of dma addresses. In order to keep
    the same stack footprint of the previous implementation the input array is
    reused as storage for the dma addresses. This requires that
    sizeof(dma_addr_t) be less than or equal to sizeof(void *). As a
    consequence CONFIG_DMADEVICES now depends on !CONFIG_HIGHMEM64G. It also
    requires that drivers be able to make descriptor resources available when
    the 'prep' routine is polled.

    Signed-off-by: Dan Williams
    Acked-by: Shannon Nelson

    Dan Williams
     

03 Feb, 2008

1 commit


25 Jan, 2008

1 commit


13 Jul, 2007

2 commits

  • The current implementation assumes that a channel will only be used by one
    client at a time. In order to enable channel sharing the dmaengine core is
    changed to a model where clients subscribe to channel-available-events.
    Instead of tracking how many channels a client wants and how many it has
    received the core just broadcasts the available channels and lets the
    clients optionally take a reference. The core learns about the clients'
    needs at dma_event_callback time.

    In support of multiple operation types, clients can specify a capability
    mask to only be notified of channels that satisfy a certain set of
    capabilities.

    Changelog:
    * removed DMA_TX_ARRAY_INIT, no longer needed
    * dma_client_chan_free -> dma_chan_release: switch to global reference
    counting only at device unregistration time, before it was also happening
    at client unregistration time
    * clients now return dma_state_client to dmaengine (ack, dup, nak)
    * checkpatch.pl fixes
    * fixup merge with git-ioat

    Cc: Chris Leech
    Signed-off-by: Shannon Nelson
    Signed-off-by: Dan Williams
    Acked-by: David S. Miller

    Dan Williams
     
  • The current dmaengine interface defines mutliple routines per operation,
    i.e. dma_async_memcpy_buf_to_buf, dma_async_memcpy_buf_to_page etc. Adding
    more operation types (xor, crc, etc) to this model would result in an
    unmanageable number of method permutations.

    Are we really going to add a set of hooks for each DMA engine
    whizbang feature?
    - Jeff Garzik

    The descriptor creation process is refactored using the new common
    dma_async_tx_descriptor structure. Instead of per driver
    do___to_ methods, drivers integrate
    dma_async_tx_descriptor into their private software descriptor and then
    define a 'prep' routine per operation. The prep routine allocates a
    descriptor and ensures that the tx_set_src, tx_set_dest, tx_submit routines
    are valid. Descriptor creation and submission becomes:

    struct dma_device *dev;
    struct dma_chan *chan;
    struct dma_async_tx_descriptor *tx;

    tx = dev->device_prep_dma_(chan, len, int_flag)
    tx->tx_set_src(dma_addr_t, tx, index /* for multi-source ops */)
    tx->tx_set_dest(dma_addr_t, tx, index)
    tx->tx_submit(tx)

    In addition to the refactoring, dma_async_tx_descriptor also lays the
    groundwork for definining cross-channel-operation dependencies, and a
    callback facility for asynchronous notification of operation completion.

    Changelog:
    * drop dma mapping methods, suggested by Chris Leech
    * fix ioat_dma_dependency_added, also caught by Andrew Morton
    * fix dma_sync_wait, change from Andrew Morton
    * uninline large functions, change from Andrew Morton
    * add tx->callback = NULL to dmaengine calls to interoperate with async_tx
    calls
    * hookup ioat_tx_submit
    * convert channel capabilities to a 'cpumask_t like' bitmap
    * removed DMA_TX_ARRAY_INIT, no longer needed
    * checkpatch.pl fixes
    * make set_src, set_dest, and tx_submit descriptor specific methods
    * fixup git-ioat merge
    * move group_list and phys to dma_async_tx_descriptor

    Cc: Jeff Garzik
    Cc: Chris Leech
    Signed-off-by: Shannon Nelson
    Signed-off-by: Dan Williams
    Acked-by: David S. Miller

    Dan Williams
     

04 Jul, 2006

1 commit


28 Jun, 2006

1 commit


18 Jun, 2006

2 commits