1. 09 2月, 2016 1 次提交
  2. 18 12月, 2015 3 次提交
    • P
      dmaengine: core: Introduce new, universal API to request a channel · a8135d0d
      Peter Ujfalusi 提交于
      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
      function.
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      a8135d0d
    • P
      dmaengine: core: Move and merge the code paths using private_candidate · 7bd903c5
      Peter Ujfalusi 提交于
      Channel matching with private_candidate() is used in two paths, the error
      checking is slightly different in them and they are duplicating code also.
      Move the code under find_candidate() to provide consistent execution and
      going to allow us to reuse this mode of channel lookup later.
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      7bd903c5
    • P
      dmaengine: core: Skip mask matching when it is not provided to private_candidate · 26b64256
      Peter Ujfalusi 提交于
      If mask is NULL skip the mask matching against the DMA device capabilities.
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      26b64256
  3. 16 11月, 2015 2 次提交
    • R
      dmaengine: enable DMA_CTRL_REUSE · 9eeacd3a
      Robert Jarzmik 提交于
      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: NRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      9eeacd3a
    • L
      dmaengine: Add transfer termination synchronization support · b36f09c3
      Lars-Peter Clausen 提交于
      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: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      b36f09c3
  4. 30 9月, 2015 1 次提交
    • P
      dmaengine: fix balance of privatecnt · 214fc4e4
      Peter Ujfalusi 提交于
      dma_release_channel() decrements privatecnt counter and almost all dma_get*
      function increments it with the exception of dma_get_slave_channel().
      In most cases this does not cause issue since normally the channel is not
      requested and released, but if a driver requests DMA channel via
      dma_get_slave_channel() and releases the channel the privatecnt will be
      unbalanced and this will prevent for example getting channel for memcpy.
      Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      214fc4e4
  5. 22 9月, 2015 1 次提交
  6. 18 8月, 2015 1 次提交
  7. 12 6月, 2015 2 次提交
  8. 02 6月, 2015 1 次提交
  9. 09 5月, 2015 1 次提交
    • P
      dmaengine: of_dma: Support for DMA routers · 56f13c0d
      Peter Ujfalusi 提交于
      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: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      56f13c0d
  10. 29 4月, 2015 1 次提交
  11. 12 4月, 2015 1 次提交
  12. 17 3月, 2015 1 次提交
  13. 06 3月, 2015 1 次提交
  14. 18 1月, 2015 1 次提交
  15. 22 12月, 2014 4 次提交
  16. 09 12月, 2014 1 次提交
  17. 28 9月, 2014 1 次提交
  18. 22 5月, 2014 1 次提交
  19. 12 2月, 2014 1 次提交
  20. 13 12月, 2013 2 次提交
    • D
      dmaengine: fix sleep in atomic · 8194ee27
      Dan Williams 提交于
       BUG: sleeping function called from invalid context at mm/mempool.c:203
       in_atomic(): 1, irqs_disabled(): 0, pid: 43502, name: linbug
       no locks held by linbug/43502.
       CPU: 7 PID: 43502 Comm: linbug Not tainted 3.13.0-rc1+ #15
       Hardware name:
        0000000000000010 ffff88005ebd1878 ffffffff8172d512 ffff8801752bc1c0
        ffff8801752bc1c0 ffff88005ebd1898 ffffffff8109d1f6 ffff88005f9a3c58
        ffff880177f0f080 ffff88005ebd1918 ffffffff81161f43 ffff88005ebd18f8
       Call Trace:
        [<ffffffff8172d512>] dump_stack+0x4e/0x68
        [<ffffffff8109d1f6>] __might_sleep+0xe6/0x120
        [<ffffffff81161f43>] mempool_alloc+0x93/0x170
        [<ffffffff810c0c34>] ? mark_held_locks+0x74/0x140
        [<ffffffff8118a826>] ? follow_page_mask+0x556/0x600
        [<ffffffff814107ae>] dmaengine_get_unmap_data+0x2e/0x60
        [<ffffffff81410f11>] dma_async_memcpy_pg_to_pg+0x41/0x1c0
        [<ffffffff814110e0>] dma_async_memcpy_buf_to_pg+0x50/0x60
        [<ffffffff81411bdc>] dma_memcpy_to_iovec+0xfc/0x190
        [<ffffffff816163af>] dma_skb_copy_datagram_iovec+0x6f/0x2b0
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      8194ee27
    • D
      dmaengine: fix enable for high order unmap pools · 3cc377b9
      Dan Williams 提交于
      The higher order mempools support raid operations, and we want to
      disable them when raid support is not enabled.  Making them conditional
      on ASYNC_TX_DMA is not sufficient as other users (specifically dmatest)
      will also issue raid operations.  Make raid drivers explicitly request
      that the core carry the higher order pools.
      Reported-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      3cc377b9
  21. 10 12月, 2013 2 次提交
    • S
      dma: add dma_get_any_slave_channel(), for use in of_xlate() · 8010dad5
      Stephen Warren 提交于
      mmp_pdma.c implements a custom of_xlate() function that is 95% identical
      to what Tegra will need. Create a function to implement the common part,
      so everyone doesn't just cut/paste the implementation.
      
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Vinod Koul <vinod.koul@intel.com>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: dmaengine@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      8010dad5
    • S
      dma: add channel request API that supports deferred probe · 0ad7c000
      Stephen Warren 提交于
      dma_request_slave_channel() simply returns NULL whenever DMA channel
      lookup fails. Lookup could fail for two distinct reasons:
      
      a) No DMA specification exists for the channel name.
         This includes situations where no DMA specifications exist at all, or
         other general lookup problems.
      
      b) A DMA specification does exist, yet the driver for that channel is not
         yet registered.
      
      Case (b) should trigger deferred probe in client drivers. However, since
      they have no way to differentiate the two situations, it cannot.
      
      Implement new function dma_request_slave_channel_reason(), which performs
      identically to dma_request_slave_channel(), except that it returns an
      error-pointer rather than NULL, which allows callers to detect when
      deferred probe should occur.
      
      Eventually, all drivers should be converted to this new API, the old API
      removed, and the new API renamed to the more desirable name. This patch
      doesn't convert the existing API and all drivers in one go, since some
      drivers call dma_request_slave_channel() then dma_request_channel() if
      that fails. That would require either modifying dma_request_channel() in
      the same way, or adding extra error-handling code to all affected
      drivers, and there are close to 100 drivers using the other API, rather
      than just the 15-20 or so that use dma_request_slave_channel(), which
      might be tenable in a single patch.
      
      acpi_dma_request_slave_chan_by_name() doesn't currently implement
      deferred probe. It should, but this will be addressed later.
      Acked-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      0ad7c000
  22. 15 11月, 2013 3 次提交
  23. 14 11月, 2013 2 次提交
  24. 25 10月, 2013 1 次提交
  25. 02 9月, 2013 1 次提交
  26. 23 8月, 2013 1 次提交
    • B
      dmaengine: make dma_channel_rebalance() NUMA aware · c4d27c4d
      Brice Goglin 提交于
      dma_channel_rebalance() currently distributes channels by processor ID.
      These IDs often change with the BIOS, and the order isn't related to
      the DMA channel list (related to PCI bus ids).
      * On my SuperMicro dual E5 machine, first socket has processor IDs [0-7]
        (and [16-23] for hyperthreads), second socket has [8-15]+[24-31]
        => channels are properly allocated to local CPUs.
      * On Dells R720 with same processors, first socket has even processor IDs,
        second socket has odd numbers
        => half the processors get channels on the remote socket, causing
           cross-NUMA traffic and lower DMA performance.
      
      Change nth_chan() to return the channel with min table_count and in the
      NUMA node of the given CPU, if any. If none, the (non-local) channel with
      min table_count is returned. nth_chan() is therefore renamed into min_chan()
      since we don't iterate until the nth channel anymore. In practice, the
      behavior is the same because first channels are taken first and are then
      ignored because they got an additional reference.
      
      The new code has a slightly higher complexity since we always scan the
      entire list of channels for finding the minimal table_count (instead
      of stopping after N chans), and because we check whether the CPU is in the
      DMA device locality mask. Overall we still have time complexity =
      number of chans x number of processors. This rebalance is rarely used,
      so this won't hurt.
      
      On the above SuperMicro machine, channels are still allocated the same.
      On the Dells, there are no locality issue anymore (MEMCPY channel X goes
      to processor X and to its hyperthread sibling).
      Signed-off-by: NBrice Goglin <Brice.Goglin@inria.fr>
      Signed-off-by: NDan Williams <djbw@fb.com>
      c4d27c4d
  27. 19 8月, 2013 1 次提交
  28. 13 8月, 2013 1 次提交
    • Z
      dmaengine: add interface of dma_get_slave_channel · 7bb587f4
      Zhangfei Gao 提交于
      Suggested by Arnd, add dma_get_slave_channel interface
      Dma host driver could get specific channel specificied by request line, rather than filter.
      
      host example:
      static struct dma_chan *xx_of_dma_simple_xlate(struct of_phandle_args *dma_spec,
      		struct of_dma *ofdma)
      {
      	struct xx_dma_dev *d = ofdma->of_dma_data;
      	unsigned int request = dma_spec->args[0];
      
      	if (request > d->dma_requests)
      		return NULL;
      
      	return dma_get_slave_channel(&(d->chans[request].vc.chan));
      }
      
      probe:
      of_dma_controller_register((&op->dev)->of_node, xx_of_dma_simple_xlate, d);
      Signed-off-by: NZhangfei Gao <zhangfei.gao@linaro.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      7bb587f4