1. 31 Jan, 2017 1 commit
  2. 30 Nov, 2016 1 commit
  3. 08 Aug, 2016 1 commit
  4. 12 Apr, 2016 1 commit
  5. 22 Feb, 2016 1 commit
  6. 09 Feb, 2016 1 commit
  7. 18 Dec, 2015 1 commit
    • Peter Ujfalusi's avatar
      dmaengine: core: Introduce new, universal API to request a channel · a8135d0d
      Peter Ujfalusi authored
      The two API function can cover most, if not all current APIs used to
      request a channel. With minimal effort dmaengine drivers, platforms and
      dmaengine user drivers can be converted to use the two function.
      struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);
      To request any channel matching with the requested capabilities, can be
      used to request channel for memcpy, memset, xor, etc where no hardware
      synchronization is needed.
      struct dma_chan *dma_request_chan(struct device *dev, const char *name);
      To request a slave channel. The dma_request_chan() will try to find the
      channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
      it will use a filter lookup table and retrieves the needed information from
      the dma_slave_map provided by the DMA drivers.
      This legacy mode needs changes in platform code, in dmaengine drivers and
      finally the dmaengine user drivers can be converted:
      For each dmaengine driver an array of DMA device, slave and the parameter
      for the filter function needs to be added:
      static const struct dma_slave_map da830_edma_map[] = {
      	{ "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
      	{ "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
      	{ "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) },
      	{ "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) },
      	{ "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) },
      	{ "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) },
      	{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
      	{ "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
      	{ "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
      	{ "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
      	{ "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
      	{ "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
      This information is going to be needed by the dmaengine driver, so
      modification to the platform_data is needed, and the driver map should be
      added to the pdata of the DMA driver:
      da8xx_edma0_pdata.slave_map = da830_edma_map;
      da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map);
      The DMA driver then needs to configure the needed device -> filter_fn
      mapping before it registers with dma_async_device_register() :
      ecc->dma_slave.filter_map.map = info->slave_map;
      ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
      ecc->dma_slave.filter_map.fn = edma_filter_fn;
      When neither DT or ACPI lookup is available the dma_request_chan() will
      try to match the requester's device name with the filter_map's list of
      device names, when a match found it will use the information from the
      dma_slave_map to get the channel with the dma_get_channel() internal
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
  8. 05 Dec, 2015 1 commit
  9. 16 Nov, 2015 2 commits
    • Robert Jarzmik's avatar
      dmaengine: enable DMA_CTRL_REUSE · 9eeacd3a
      Robert Jarzmik authored
      In the current state, the capability of transfer reuse can neither be
      set by a slave dmaengine driver, nor used by a client driver, because
      the capability is not available to dma_get_slave_caps().
      Fix this by adding a way to declare the capability.
      Fixes: 27242021 ("dmaengine: Add DMA_CTRL_REUSE")
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
    • Lars-Peter Clausen's avatar
      dmaengine: Add transfer termination synchronization support · b36f09c3
      Lars-Peter Clausen authored
      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: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
  10. 04 Oct, 2015 1 commit
  11. 20 Aug, 2015 1 commit
    • Geert Uytterhoeven's avatar
      dmaengine: Stricter legacy checking in dma_request_slave_channel_compat() · 7dfffb95
      Geert Uytterhoeven authored
      dma_request_slave_channel_compat() is meant for drivers that support
      both DT and legacy platform device based probing: if DT channel DMA
      setup fails, it will fall back to platform data based DMA channel setup,
      using hardcoded DMA channel IDs and a filter function.
      However, if the DTS doesn't provide a "dmas" property for the device,
      the fallback is also used. If the legacy filter function is not
      hardcoded in the DMA slave driver, but comes from platform data, it will
      be NULL. Then dma_request_slave_channel_compat() will succeed
      incorrectly, and return a DMA channel, as a NULL legacy filter function
      actually means "all channels are OK", not "do not match".
      Later, when trying to use that DMA channel, it will fail with:
          rcar-dmac e6700000.dma-controller: rcar_dmac_prep_slave_sg: bad parameter: len=1, id=-22
      To fix this, ensure that both the filter function and the DMA channel ID
      are not NULL before using the legacy fallback.
      Note that some DMA slave drivers can handle this failure, and will fall
      back to PIO.
      See also commit 056f6c87 ("dmaengine: shdma: Make dummy
      shdma_chan_filter() always return false"), which fixed the same issue
      for the case where shdma_chan_filter() is hardcoded in a DMA slave
      Suggested-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
  12. 17 Aug, 2015 2 commits
  13. 06 Aug, 2015 1 commit
  14. 05 Aug, 2015 1 commit
  15. 12 Jun, 2015 2 commits
  16. 18 May, 2015 1 commit
  17. 09 May, 2015 1 commit
    • Peter Ujfalusi's avatar
      dmaengine: of_dma: Support for DMA routers · 56f13c0d
      Peter Ujfalusi authored
      DMA routers are transparent devices used to mux DMA requests from
      peripherals to DMA controllers. They are used when the SoC integrates more
      devices with DMA requests then their controller can handle.
      DRA7x is one example of such SoC, where the sDMA can hanlde 128 DMA request
      lines, but in SoC level it has 205 DMA requests.
      The of_dma_router will be registered as of_dma_controller with special
      xlate function and additional parameters. The driver for the router is
      responsible to craft the dma_spec (in the of_dma_route_allocate callback)
      which can be used to requests a DMA channel from the real DMA controller.
      This way the router can be transparent for the system while remaining generic
      enough to be used in different environments.
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
  18. 16 Mar, 2015 1 commit
  19. 05 Mar, 2015 2 commits
  20. 04 Mar, 2015 1 commit
  21. 19 Jan, 2015 1 commit
  22. 18 Jan, 2015 1 commit
  23. 23 Dec, 2014 1 commit
  24. 22 Dec, 2014 6 commits
  25. 05 Dec, 2014 1 commit
  26. 15 Oct, 2014 2 commits
  27. 28 Sep, 2014 1 commit
  28. 23 Sep, 2014 1 commit
  29. 04 Aug, 2014 1 commit
  30. 25 Jul, 2014 1 commit