1. 07 1月, 2009 2 次提交
    • D
      dmaengine: centralize channel allocation, introduce dma_find_channel · bec08513
      Dan Williams 提交于
      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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      
      
      bec08513
    • D
      dmaengine: up-level reference counting to the module level · 6f49a57a
      Dan Williams 提交于
      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: NAndrew Morton <akpm@linux-foundation.org>
      Acked-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      
      
      6f49a57a
  2. 06 1月, 2009 1 次提交
  3. 05 1月, 2009 16 次提交
  4. 04 1月, 2009 1 次提交
  5. 03 1月, 2009 20 次提交