1. 03 12月, 2010 1 次提交
  2. 08 10月, 2010 1 次提交
  3. 06 10月, 2010 1 次提交
    • S
      dmaengine: Add Freescale i.MX SDMA support · 1ec1e82f
      Sascha Hauer 提交于
      This patch adds support for the Freescale i.MX SDMA engine.
      
      The SDMA engine is a scatter/gather DMA engine which is implemented
      as a seperate coprocessor. SDMA needs its own firmware which is
      requested using the standard request_firmware mechanism. The firmware
      has different entry points for each peripheral type, so drivers
      have to pass the peripheral type to the DMA engine which in turn
      picks the correct firmware entry point from a table contained in
      the firmware image itself.
      The original Freescale code also supports support for transfering
      data to the internal SRAM which needs different entry points to
      the firmware. Support for this is currently not implemented. Also,
      support for the ASRC (asymmetric sample rate converter) is skipped.
      
      I took a very simple approach to implement dmaengine support. Only
      a single descriptor is statically assigned to a each channel. This
      means that transfers can't be queued up but only a single transfer
      is in progress. This simplifies implementation a lot and is sufficient
      for the usual device/memory transfers.
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      Reviewed-by: NLinus Walleij <linus.ml.walleij@gmail.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      1ec1e82f
  4. 30 9月, 2010 1 次提交
    • L
      dmaengine: driver for the ARM PL080/PL081 PrimeCells v5 · e8689e63
      Linus Walleij 提交于
      This creates a DMAengine driver for the ARM PL080/PL081 PrimeCells
      based on the implementation earlier submitted by Peter Pearse.
      This is working like a charm for memcpy and slave DMA to the PL011
      PrimeCell on the PB11MPCore.
      
      This DMA controller is used in mostly unmodified form in the ARM
      RealView and Versatile platforms, in the ST-Ericsson Nomadik, and
      in the ST SPEAr platform.
      
      It has been converted to use the header from the Samsung PL080
      derivate instead of its own defintions. The Samsungs have a custom
      driver in their mach-* folders though, atleast we can share the
      register definitions.
      
      Cc: Peter Pearse <peter.pearse@arm.com>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: Alessandro Rubini <rubini@unipv.it>
      Acked-by: NViresh Kumar <viresh.kumar@st.com>
      Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
      [GFP_KERNEL to GFP_NOWAIT in pl08x_prep_dma_memcpy]
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      e8689e63
  5. 05 8月, 2010 1 次提交
  6. 28 7月, 2010 1 次提交
    • V
      intel_mid: Add Mrst & Mfld DMA Drivers · b3c567e4
      Vinod Koul 提交于
      This patch add DMA drivers for DMA controllers in Langwell chipset
      of Intel(R) Moorestown platform and DMA controllers in Penwell of
      Intel(R) Medfield platfrom
      
      This patch adds support for Moorestown DMAC1 and DMAC2 controllers.
      It also add support for Medfiled GP DMA and DMAC1 controllers.
      These controllers supports memory to peripheral and peripheral to
      memory transfers. It support only single block transfers.
      
      This driver is based on Kernel DMA engine
      Anyone who wishes to use this controller should use DMA engine APIs
      
      This controller exposes DMA_SLAVE capabilities and notifies the client drivers
      of DMA transaction completion
      
      Config option required to be enabled CONFIG_INTEL_MID_DMAC=y
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      b3c567e4
  7. 24 5月, 2010 1 次提交
  8. 15 4月, 2010 1 次提交
  9. 26 3月, 2010 1 次提交
  10. 02 3月, 2010 2 次提交
  11. 12 12月, 2009 1 次提交
  12. 20 11月, 2009 1 次提交
  13. 09 9月, 2009 1 次提交
  14. 29 7月, 2009 1 次提交
  15. 23 7月, 2009 1 次提交
  16. 17 6月, 2009 1 次提交
  17. 20 1月, 2009 1 次提交
    • G
      i.MX31: Image Processing Unit DMA and IRQ drivers · 5296b56d
      Guennadi Liakhovetski 提交于
      i.MX3x SoCs contain an Image Processing Unit, consisting of a Control
      Module (CM), Display Interface (DI), Synchronous Display Controller (SDC),
      Asynchronous Display Controller (ADC), Image Converter (IC), Post-Filter
      (PF), Camera Sensor Interface (CSI), and an Image DMA Controller (IDMAC).
      CM contains, among other blocks, an Interrupt Generator (IG) and a Clock
      and Reset Control Unit (CRCU). This driver serves IDMAC and IG. They are
      supported over dmaengine and irq-chip APIs respectively.
      
      IDMAC is a specialised DMA controller, its DMA channels cannot be used for
      general-purpose operations, even though it might be possible to configure
      a memory-to-memory channel for memcpy operation. This driver will not work
      with generic dmaengine clients, clients, wishing to use it must use
      respective wrapper structures, they also must specify which channels they
      require, as channels are hard-wired to specific IPU functions.
      Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NGuennadi Liakhovetski <lg@denx.de>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      5296b56d
  18. 09 7月, 2008 3 次提交
    • H
      dmaengine: Driver for the Synopsys DesignWare DMA controller · 3bfb1d20
      Haavard Skinnemoen 提交于
      This adds a driver for the Synopsys DesignWare DMA controller (aka
      DMACA on AVR32 systems.) This DMA controller can be found integrated
      on the AT32AP7000 chip and is primarily meant for peripheral DMA
      transfer, but can also be used for memory-to-memory transfers.
      
      This patch is based on a driver from David Brownell which was based on
      an older version of the DMA Engine framework. It also implements the
      proposed extensions to the DMA Engine API for slave DMA operations.
      
      The dmatest client shows no problems, but there may still be room for
      improvement performance-wise. DMA slave transfer performance is
      definitely "good enough"; reading 100 MiB from an SD card running at ~20
      MHz yields ~7.2 MiB/s average transfer rate.
      
      Full documentation for this controller can be found in the Synopsys
      DW AHB DMAC Databook:
      
      http://www.synopsys.com/designware/docs/iip/DW_ahb_dmac/latest/doc/dw_ahb_dmac_db.pdf
      
      The controller has lots of implementation options, so it's usually a
      good idea to check the data sheet of the chip it's intergrated on as
      well. The AT32AP7000 data sheet can be found here:
      
      http://www.atmel.com/dyn/products/datasheets.asp?family_id=682
      
      
      Changes since v4:
        * Use client_count instead of dma_chan_is_in_use()
        * Add missing include
        * Unmap buffers unless client told us not to
      
      Changes since v3:
        * Update to latest DMA engine and DMA slave APIs
        * Embed the hw descriptor into the sw descriptor
        * Clean up and update MODULE_DESCRIPTION, copyright date, etc.
      
      Changes since v2:
        * Dequeue all pending transfers in terminate_all()
        * Rename dw_dmac.h -> dw_dmac_regs.h
        * Define and use controller-specific dma_slave data
        * Fix up a few outdated comments
        * Define hardware registers as structs (doesn't generate better
          code, unfortunately, but it looks nicer.)
        * Get number of channels from platform_data instead of hardcoding it
          based on CONFIG_WHATEVER_CPU.
        * Give slave clients exclusive access to the channel
      
      Acked-by: Maciej Sosnowski <maciej.sosnowski@intel.com>,
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      3bfb1d20
    • H
      dmatest: Simple DMA memcpy test client · 4a776f0a
      Haavard Skinnemoen 提交于
      This client tests DMA memcpy using various lengths and various offsets
      into the source and destination buffers. It will initialize both
      buffers with a repeatable pattern and verify that the DMA engine copies
      the requested region and nothing more. It will also verify that the
      bytes aren't swapped around, and that the source buffer isn't modified.
      
      The dmatest module can be configured to test a specific device, a
      specific channel. It can also test multiple channels at the same time,
      and it can start multiple threads competing for the same channel.
      
      Changes since v2:
        * Support testing multiple channels at the same time
        * Support testing with multiple threads competing for the same channel
        * Use counting test patterns in order to catch byte ordering issues
      
      Changes since v1:
        * Remove extra dashes around "help"
        * Remove "default n" from Kconfig
        * Turn TEST_BUF_SIZE into a module parameter
        * Return DMA_NAK instead of DMA_DUP
        * Print unhandled events
        * Support testing specific channels and devices
        * Move to the end of the Makefile
      Acked-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      4a776f0a
    • S
      dmaengine: DMA engine driver for Marvell XOR engine · ff7b0479
      Saeed Bishara 提交于
      The XOR engine found in Marvell's SoCs and system controllers
      provides XOR and DMA operation, iSCSI CRC32C calculation, memory
      initialization, and memory ECC error cleanup operation support.
      
      This driver implements the DMA engine API and supports the following
      capabilities:
      - memcpy
      - xor
      - memset
      
      The XOR engine can be used by DMA engine clients implemented in the
      kernel, one of those clients is the RAID module.  In that case, I
      observed 20% improvement in the raid5 write throughput, and 40%
      decrease in the CPU utilization when doing array construction, those
      results obtained on an 5182 running at 500Mhz.
      
      When enabling the NET DMA client, the performance decreased, so
      meanwhile it is recommended to keep this client off.
      Signed-off-by: NSaeed Bishara <saeed@marvell.com>
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      Acked-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      ff7b0479
  19. 05 3月, 2008 1 次提交
  20. 17 10月, 2007 3 次提交
  21. 13 7月, 2007 1 次提交
    • D
      dmaengine: driver for the iop32x, iop33x, and iop13xx raid engines · c2110923
      Dan Williams 提交于
      The Intel(R) IOP series of i/o processors integrate an Xscale core with
      raid acceleration engines.  The capabilities per platform are:
      
      iop219:
       (2) copy engines
      iop321:
       (2) copy engines
       (1) xor and block fill engine
      iop33x:
       (2) copy and crc32c engines
       (1) xor, xor zero sum, pq, pq zero sum, and block fill engine
      iop34x (iop13xx):
       (2) copy, crc32c, xor, xor zero sum, and block fill engines
       (1) copy, crc32c, xor, xor zero sum, pq, pq zero sum, and block fill engine
      
      The driver supports the features of the async_tx api:
      * asynchronous notification of operation completion
      * implicit (interupt triggered) handling of inter-channel transaction
        dependencies
      
      The driver adapts to the platform it is running by two methods.
      1/ #include <asm/arch/adma.h> which defines the hardware specific
         iop_chan_* and iop_desc_* routines as a series of static inline
         functions
      2/ The private platform data attached to the platform_device defines the
         capabilities of the channels
      
      20070626: Callbacks are run in a tasklet.  Given the recent discussion on
      LKML about killing tasklets in favor of workqueues I did a quick conversion
      of the driver.  Raid5 resync performance dropped from 50MB/s to 30MB/s, so
      the tasklet implementation remains until a generic softirq interface is
      available.
      
      Changelog:
      * fixed a slot allocation bug in do_iop13xx_adma_xor that caused too few
      slots to be requested eventually leading to data corruption
      * enabled the slot allocation routine to attempt to free slots before
      returning -ENOMEM
      * switched the cleanup routine to solely use the software chain and the
      status register to determine if a descriptor is complete.  This is
      necessary to support other IOP engines that do not have status writeback
      capability
      * make the driver iop generic
      * modified the allocation routines to understand allocating a group of
      slots for a single operation
      * added a null xor initialization operation for the xor only channel on
      iop3xx
      * support xor operations on buffers larger than the hardware maximum
      * split the do_* routines into separate prep, src/dest set, submit stages
      * added async_tx support (dependent operations initiation at cleanup time)
      * simplified group handling
      * added interrupt support (callbacks via tasklets)
      * brought the pending depth inline with ioat (i.e. 4 descriptors)
      * drop dma mapping methods, suggested by Chris Leech
      * don't use inline in C files, Adrian Bunk
      * remove static tasklet declarations
      * make iop_adma_alloc_slots easier to read and remove chances for a
        corrupted descriptor chain
      * fix locking bug in iop_adma_alloc_chan_resources, Benjamin Herrenschmidt
      * convert capabilities over to dma_cap_mask_t
      * fixup sparse warnings
      * add descriptor flush before iop_chan_enable
      * checkpatch.pl fixes
      * gpl v2 only correction
      * move set_src, set_dest, submit to async_tx methods
      * move group_list and phys to async_tx
      
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      c2110923
  22. 18 6月, 2006 3 次提交