1. 06 Jan, 2009 4 commits
    • Dan Williams's avatar
      dmaengine: centralize channel allocation, introduce dma_find_channel · bec08513
      Dan Williams authored
      Allowing multiple clients to each define their own channel allocation
      scheme quickly leads to a pathological situation.  For memory-to-memory
      offload all clients can share a central allocator.
      
      This simply moves the existing async_tx allocator to dmaengine with
      minimal fixups:
      * async_tx.c:get_chan_ref_by_cap --> dmaengine.c:nth_chan
      * async_tx.c:async_tx_rebalance --> dmaengine.c:dma_channel_rebalance
      * split out common code from async_tx.c:__async_tx_find_channel -->
        dma_find_channel
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      
      
      bec08513
    • Dan Williams's avatar
      dmaengine: up-level reference counting to the module level · 6f49a57a
      Dan Williams authored
      Simply, if a client wants any dmaengine channel then prevent all dmaengine
      modules from being removed.  Once the clients are done re-enable module
      removal.
      
      Why?, beyond reducing complication:
      1/ Tracking reference counts per-transaction in an efficient manner, as
         is currently done, requires a complicated scheme to avoid cache-line
         bouncing effects.
      2/ Per-transaction ref-counting gives the false impression that a
         dma-driver can be gracefully removed ahead of its user (net, md, or
         dma-slave)
      3/ None of the in-tree dma-drivers talk to hot pluggable hardware, but
         if such an engine were built one day we still would not need to notify
         clients of remove events.  The driver can simply return NULL to a
         ->prep() request, something that is much easier for a client to handle.
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Acked-by: default avatarMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      
      
      6f49a57a
    • Dan Williams's avatar
      dmaengine: remove dependency on async_tx · 07f2211e
      Dan Williams authored
      async_tx.ko is a consumer of dma channels.  A circular dependency arises
      if modules in drivers/dma rely on common code in async_tx.ko.  It
      prevents either module from being unloaded.
      
      Move dma_wait_for_async_tx and async_tx_run_dependencies to dmaeninge.o
      where they should have been from the beginning.
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      
      07f2211e
    • Dan Williams's avatar
      async_tx, dmaengine: document channel allocation and api rework · 28405d8d
      Dan Williams authored
      "Wouldn't it be better if the dmaengine layer made sure it didn't pass
      the same channel several times to a client?
      
      I mean, you seem concerned that the memcpy() API should be transparent
      and easy to use, but the whole registration interface is just
      ridiculously complicated..."
      	- Haavard
      
      The dmaengine and async_tx registration/allocation interface is indeed
      needlessly complicated.  This redesign has the following goals:
      
      1/ Simplify reference counting: dma channels are not something one would
         expect to be hotplugged, it should be an exceptional event handled by
         drivers not something clients should be mandated to handle in a
         callback.  The common case channel removal event is 'rmmod <dma driver>',
         which for simplicity should be disallowed if the channel is in use.
      2/ Add an interface for requesting exclusive access to a channel
         suitable to device-to-memory users.
      3/ Convert all memory-to-memory users over to a common allocator, the goal
         here is to not have competing channel allocation schemes.  The only
         competition should be between device-to-memory exclusive allocations and
         the memory-to-memory usage case where channels are shared between
         multiple "clients".
      
      Cc: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Jeff Garzik <jeff@garzik.org>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      
      28405d8d
  2. 05 Jan, 2009 1 commit
  3. 04 Jan, 2009 23 commits
  4. 03 Jan, 2009 12 commits