07 Sep, 2017

1 commit


28 Aug, 2017

1 commit

  • Some of the DMA controllers are capable of issuing the commands
    to peripheral by the DMA. These commands can be list of register
    reads/writes and its different from normal data reads/writes.
    This patch adds new flag DMA_PREP_CMD in DMA API which tells
    the driver that the data passed to DMA API is command data
    and DMA controller driver will form descriptor in the required
    format.

    This flag can be used by any DMA controller driver which requires
    the descriptor in different format for non-Data descriptors.

    Signed-off-by: Abhishek Sahu
    Signed-off-by: Vinod Koul

    Abhishek Sahu
     

22 Aug, 2017

1 commit


14 Nov, 2016

1 commit


08 Aug, 2016

1 commit


04 Jun, 2016

1 commit


16 Nov, 2015

1 commit

  • The DMAengine API has a long standing race condition that is inherent to
    the API itself. Calling dmaengine_terminate_all() is supposed to stop and
    abort any pending or active transfers that have previously been submitted.
    Unfortunately it is possible that this operation races against a currently
    running (or with some drivers also scheduled) completion callback.

    Since the API allows dmaengine_terminate_all() to be called from atomic
    context as well as from within a completion callback it is not possible to
    synchronize to the execution of the completion callback from within
    dmaengine_terminate_all() itself.

    This means that a user of the DMAengine API does not know when it is safe
    to free resources used in the completion callback, which can result in a
    use-after-free race condition.

    This patch addresses the issue by introducing an explicit synchronization
    primitive to the DMAengine API called dmaengine_synchronize().

    The existing dmaengine_terminate_all() is deprecated in favor of
    dmaengine_terminate_sync() and dmaengine_terminate_async(). The former
    aborts all pending and active transfers and synchronizes to the current
    context, meaning it will wait until all running completion callbacks have
    finished. This means it is only possible to call this function from
    non-atomic context. The later function does not synchronize, but can still
    be used in atomic context or from within a complete callback. It has to be
    followed up by dmaengine_synchronize() before a client can free the
    resources used in a completion callback.

    In addition to this the semantics of the device_terminate_all() callback
    are slightly relaxed by this patch. It is now OK for a driver to only
    schedule the termination of the active transfer, but does not necessarily
    have to wait until the DMA controller has completely stopped. The driver
    must ensure though that the controller has stopped and no longer accesses
    any memory when the device_synchronize() callback returns.

    This was in part done since most drivers do not pay attention to this
    anyway at the moment and to emphasize that this needs to be done when the
    device_synchronize() callback is implemented. But it also helps with
    implementing support for devices where stopping the controller can require
    operations that may sleep.

    Signed-off-by: Lars-Peter Clausen
    Signed-off-by: Vinod Koul

    Lars-Peter Clausen
     

17 Aug, 2015

2 commits


18 Jun, 2015

1 commit


22 Dec, 2014

2 commits


06 Nov, 2014

1 commit